¿Cómo abordar una misión ETL?

Algunos consejos generales de ETL

1. Considere organizarlo por destino (por ejemplo, todo el código para producir la dimensión Cliente vive en el mismo módulo, independientemente de la fuente). Esto a veces se conoce como ETL orientado al sujeto. Hace que encontrar cosas sea mucho más fácil y aumentará la capacidad de mantenimiento de su código.

2. Si la base de datos SQL2000 es un desastre, probablemente encontrará que los flujos de datos SSIS son una forma torpe de manejar los datos. Como regla general, las herramientas ETL escalan mal con la complejidad; algo así como la mitad de todos los proyectos de almacenamiento de datos en las empresas financieras se realizan con código de procedimiento almacenado como una decisión arquitectónica explícita, precisamente por esta razón. Si tiene que poner una gran cantidad de código en los procesos, considere poner todo del código en sprocs.
   
   Para un sistema que implica muchas depuraciones o transformaciones complejas, un enfoque 100 % sproc es mucho más fácil de mantener, ya que es la única forma viable de poner todas las transformaciones y la lógica empresarial en un solo lugar. Con sistemas mixtos de ETL/sproc, debe buscar en varios lugares para rastrear, solucionar problemas, depurar o cambiar toda la transformación.

3. El punto óptimo de las herramientas ETL está en los sistemas en los que tiene una mayor cantidad de fuentes de datos con transformaciones relativamente simples.

4. Haga que el código sea comprobable, de modo que pueda separar los componentes y probarlos de forma aislada. El código que solo se puede ejecutar desde la mitad de un flujo de datos complejo en una herramienta ETL es mucho más difícil de probar.

5. Haga que la extracción de datos sea tonta sin lógica empresarial y cópiela en un área de ensayo. Si tiene una lógica empresarial distribuida en las capas de extracción y transformación, tendrá transformaciones que no se pueden probar de forma aislada y que dificultarán el seguimiento de los errores. Si la transformación se está ejecutando desde un área de preparación, se reduce la dependencia estricta del sistema de origen, lo que nuevamente mejora la capacidad de prueba. Esta es una ventaja particular en las arquitecturas basadas en sproc, ya que permite una base de código casi completamente homogénea.

6. Cree un controlador de dimensiones genérico que cambie lentamente o use uno estándar si está disponible. Esto hace que sea más fácil realizar pruebas unitarias de esta funcionalidad. Si esto se puede probar de forma unitaria, la prueba del sistema no tiene que probar todos los casos de esquina, simplemente si los datos que se le presentan son correctos. Esto no es tan complejo como parece:el último que escribí tenía unas 600 o 700 líneas de código T-SQL. Lo mismo ocurre con las funciones de limpieza genéricas.

7. Carga incrementalmente si es posible.

8. Instrumente su código:pídale que realice entradas de registro, posiblemente grabando diagnósticos como cheques totales o conteos. Sin esto, la solución de problemas es casi imposible. Además, la verificación de afirmaciones es una buena manera de pensar en el manejo de errores para esto (¿cuentan las filas en un recuento de filas iguales en b, la relación A:B es realmente 1:1).

9. Utilice claves sintéticas. El uso de claves naturales de los sistemas de origen vincula su sistema a las fuentes de datos y dificulta la adición de fuentes adicionales. Las claves y las relaciones en el sistema siempre deben estar alineadas, sin valores nulos. Para errores, 'no registrados', haga entradas específicas de 'error' o 'no registrados' en la tabla de dimensiones y conéctelas.

10. Si crea un Almacén de datos operativos (el tema de muchas guerras religiosas), no recicle las claves ODS en los esquemas en estrella. Por supuesto, únase a las claves ODS para construir dimensiones, pero haga coincidir una clave natural. Esto le permite descartar y recrear arbitrariamente el ODS, posiblemente cambiando su estructura, sin alterar los esquemas de estrella. Tener esta capacidad es una verdadera victoria de mantenimiento, ya que puede cambiar la estructura del ODS o hacer una reimplementación por fuerza bruta del ODS en cualquier momento.

Los puntos 1-2 y 4-5 significan que puede construir un sistema donde todos del código para cualquier subsistema dado (por ejemplo, una sola dimensión o tabla de hechos) vive en un solo lugar en el sistema. Este tipo de arquitectura también es mejor para un gran número de fuentes de datos.

El punto 3 es un contrapunto al punto 2. Básicamente, la elección entre herramientas SQL y ETL es una función de la complejidad de la transformación y la cantidad de sistemas de origen. Cuanto más simples sean los datos y mayor el número de fuentes de datos, más sólido será el caso para un enfoque basado en herramientas. Cuanto más complejos sean los datos, más sólidos serán los argumentos para pasar a una arquitectura basada en procedimientos almacenados. Generalmente es mejor usar exclusiva o casi exclusivamente uno u otro pero no ambos.

El punto 6 hace que su sistema sea más fácil de probar. Probar SCD o cualquier funcionalidad basada en cambios es complicado, ya que debe poder presentar más de una versión de los datos de origen al sistema. Si traslada la funcionalidad de gestión de cambios al código de infraestructura, puede probarla de forma aislada con conjuntos de datos de prueba. Esta es una ventaja en las pruebas, ya que reduce la complejidad de los requisitos de prueba de su sistema.

El punto 7 es un consejo de rendimiento general que deberá tener en cuenta para grandes volúmenes de datos. Tenga en cuenta que es posible que solo necesite una carga incremental para algunas partes de un sistema; para tablas de referencia y dimensiones más pequeñas, es posible que no lo necesite.

El punto 8 está relacionado con cualquier proceso sin cabeza. Si las cosas se ponen feas durante la noche, querrás tener la oportunidad de ver qué salió mal al día siguiente. Si el código no registra correctamente lo que está sucediendo y detecta errores, será mucho más difícil solucionarlo.

El punto 9 le da vida propia al almacén de datos. Puede agregar y eliminar fácilmente sistemas de origen cuando el almacén tiene sus propias claves. Las claves de almacén también son necesarias para implementar dimensiones que cambian lentamente.

El punto 10 es una victoria de mantenimiento e implementación, ya que el ODS se puede reestructurar si necesita agregar nuevos sistemas o cambiar la cardinalidad de un registro. También significa que una dimensión se puede cargar desde más de un lugar en el ODS (piense:agregar ajustes contables manuales) sin depender de las claves del ODS.