La arquitectura estándar para un sistema ETL se basa en extracciones periódicas por lotes de los datos de origen, que luego fluyen a través del sistema, resultando en una actualización por lotes de las tablas finales para el usuario. Sin embargo, cuando la naturaleza en tiempo real de la carga del almacén de datos se vuelve suficientemente urgente, el enfoque por lotes se descompone. La alternativa es un flujo de datos en streaming en el que los datos a nivel de registro fluyen continuamente desde el sistema de origen hasta las bases de datos y pantallas de los usuarios.
Cambiar de un flujo de datos por lotes a uno en streaming cambia todo. Aunque todavía debemos respaldar los pasos fundamentales del flujo de datos de extraer, limpiar, conformar y entregar, cada uno de estos pasos debe modificarse para el procesamiento registro por registro. Y especialmente con los flujos en streaming más rápidos, muchas de las suposiciones habituales sobre la llegada de datos e incluso la integridad referencial deben revisarse.
Dependencia de Tareas Horizontales versus Verticales
Un flujo de tareas organizado horizontalmente permite que cada carga final de la base de datos se ejecute de forma independiente hasta su conclusión. Esto suele significar que los pasos de extracción, limpieza, conformación y entrega no están sincronizados entre estos dos flujos de trabajo. Por otro lado, un flujo de tareas orientado verticalmente sincroniza dos o más flujos de trabajo separados para que las cargas finales de la base de datos ocurran simultáneamente.
Automatización del Programador
Una decisión arquitectónica relacionada es cuánto controlar tu sistema ETL global con tecnología de programación automatizada. En un extremo, todos los trabajos son iniciados por una persona que escribe en una línea de comandos o inicia un icono. En el otro extremo, una herramienta de programación maestra gestiona todos los trabajos, comprende si los trabajos se han ejecutado con éxito, espera a que se satisfagan diversos estados del sistema y maneja la comunicación con supervisores humanos, como alertas de emergencia e informes de estado del flujo de trabajo. La implementación de la automatización del programador puede mejorar significativamente la eficiencia y reducir los errores humanos, asegurando que los procesos se ejecuten en el momento adecuado y en el orden correcto.
Manejo de Excepciones
El manejo de excepciones debería ser un mecanismo uniforme en todo el sistema para informar todas las instancias de excepciones generadas por procesos ETL en una única base de datos. Este registro debería incluir el nombre del proceso, el momento de la excepción, su gravedad inicialmente diagnosticada, la acción posteriormente tomada y el estado final de resolución de la excepción. Cada trabajo necesita ser arquitectado para escribir estos registros de informes de excepción en la base de datos. Un sistema de manejo de excepciones bien diseñado puede ayudar a identificar y resolver rápidamente los problemas, minimizando el impacto en los usuarios finales y manteniendo la integridad de los datos.
Estas secciones abordan aspectos cruciales de la arquitectura ETL, desde la elección entre flujos de datos por lotes y en streaming, la organización de tareas, la automatización del programador hasta el manejo de excepciones. Cada una de estas decisiones arquitectónicas puede tener un impacto significativo en la eficacia, eficiencia y confiabilidad del sistema ETL en su conjunto.
Manejo de la Calidad
De manera similar, se debe decidir una respuesta común a los problemas de calidad que surjan durante el procesamiento de los datos. Además de activar un registro de informe de excepción, todos los problemas de calidad necesitan generar un registro de auditoría adjunto a la dimensión final o a los datos de hecho. Los datos corruptos o sospechosos deben ser tratados con un pequeño número de respuestas uniformes, como llenar los datos de texto faltantes con un signo de interrogación o suministrar estimadores menos sesgados de valores numéricos que existen pero fueron corrompidos antes de la entrega al almacén de datos.
Recuperación y Reinicio
Desde el inicio, necesitas construir tu sistema ETL en torno a la capacidad de recuperarte de la finalización anormal de un trabajo y reiniciar. Los trabajos ETL necesitan ser reentrantes, de lo contrario, impermeables a actualizaciones múltiples incorrectas. Por ejemplo, no se debe permitir que un trabajo que resta un resultado de ventas de una marca particular de una categoría de producto general se ejecute dos veces. Este tipo de pensamiento necesita subyacer en cada trabajo ETL porque tarde o temprano estos trabajos terminarán anormalmente o se ejecutarán por error más de una vez. De alguna manera, de alguna forma, debes evitar que esto suceda.
Metadatos
Los metadatos de las tablas del sistema DBMS y de las herramientas de diseño de esquemas son fáciles de capturar, pero probablemente componen el 25 por ciento de los metadatos que necesitas para entender y controlar tu sistema. Otro 25 por ciento de los metadatos es generado por el paso de limpieza. Pero el mayor desafío de metadatos para el equipo ETL es dónde y cómo almacenar la información del flujo de procesos. Una ventaja importante, aunque poco glamurosa, de las suites de herramientas ETL es que mantienen automáticamente estos metadatos de flujo de procesos. Si estás codificando a mano tu sistema ETL, necesitas implementar tu propio repositorio central de metadatos de flujo de procesos.
Seguridad
Anteriormente, describimos nuestra arquitectura recomendada para la seguridad basada en roles para los usuarios finales. La seguridad en el entorno ETL es menos granular que en el entorno del usuario final; sin embargo, un enfoque sistemático de la seguridad exige que salvaguardias físicas y administrativas rodeen cada tabla en línea y cada cinta de respaldo en el entorno ETL. Los conjuntos de datos más sensibles e importantes deben estar instrumentados con informes impresos del sistema operativo que enumeran cada acceso y cada comando realizado por todos los administradores contra estos conjuntos de datos.