3 Pecados Capitales cometidos en los procesos ETL

En iniciativas del tipo Data Warehousing / Business Intelligence (DW/BI) y Data Science, un término que aparece con frecuencia es “ETL” o “Sistemas ETL”, el cual en adelante por facilidad, mencionaré indistintamente como ETL, los ETL o Procesos ETL. 

Durante los 90’, cuando se acuña el término ETL, este era utilizado para referirse a procesos técnicos que extraían datos de diversos sistemas, los transformaban, para posteriormente cargarlos a un Data Warehouse, de ahí la sigla en inglés Extract, Transform and Load. Desde aquella época que los ETL son considerados como una actividad “Back Room” la cual no tiene mucha visibilidad para los usuarios finales, como diría uno de nuestros clientes: “Son pegas subterráneas”.

Desde mi punto de vista, uno de los problemas que trajo esta sigla y su repetición "marketinera" es que simplifica en demasía todo lo que involucra. El 2004 ya se indicaba que los ETL fácilmente consumen el 70% de los recursos de un proyecto [1], el 2019 en AWS Cloud Experience Chile, este porcentaje subió a un 80% (ver sección Data Lakes). A pesar de ser una actividad de poca visibilidad, es claro que un sistema ETL puede hacer a un DW exitoso o un fracaso rotundo, y parte del éxito pasa por incorporar actividades concretas que no se mencionan en la sigla tan repetida: ETL. 

Un sistema ETL bien diseñado considera la extracción de datos de diversos sistemas, aplica criterios de calidad (Data Quality) y consistencia de datos, los unifica (conforma) para que puedan ser utilizados en conjunto y finalmente entrega los datos, en un formato usualmente dimensional, para que los desarrolladores/analistas BI puedan crear aplicaciones y los usuarios finales puedan tomar decisiones.

De la teoría ETL a la práctica ECCD

Pero Lenin, ¿Qué hace que un sistema ETL sea complejo? Un sistema ETL debe:

• Adaptarse a las Expectativas que los usuarios tienen sobre lo que los datos pueden hacer por ellos.
• Adaptarse a los Requerimientos Regulatorios, por ejemplo el 2002 fue la ley de Sarbanes-Oxley, el 2016 GPDR y el 2030 probablemente un par más.
• Adaptarse a los Requerimientos de Seguridad.
• Cubrir Requerimientos de Calidad de Datos, por ejemplo remover errores o corregir datos faltantes.
• Resolver el “anhelo de la Visión 360 del negocio” a través de fuertes integraciones de datos/sistemas.
• Ser óptimo en la entrega de los datos (Baja latencia) trabajando en ventanas de tiempos cada vez más restringidas.
• Almacenamiento y trazabilidad de los datos mediante un Linaje.

¿Algo más? Sí, Hardware, Software, Skills y licencias .

Por eso, desde mi punto de vista, la sigla ETL queda corta, aunque este tema me apasiona, el objetivo de esta entrada no es explicar cómo hacer buenos ETL, sino más bien mencionar algunos de los pecados capitales que más he visto en las consultorías que en Lituus Analytics realizamos.

Pecado Capital #1: No preservar la “historia” adecuadamente

Indicar a los usuarios que el DW / Data Lake almacena la historia de los últimos 10 años cuando todas las dimensiones son de tipo SCD1 (Slowly Changing Dimension) es decir la verdad a medias. Contar solo con dimensiones SCD1 implica que cada cambio de un atributo, por ejemplo el sueldo o el estado civil, es “reescrito o pisado”, es decir, solo se tiene la última versión del registro siempre y cuando el ETL no cometa el pecado capital #2. 

• ¿Qué hará cuando por Req. Regulatorio (ej. UAF) le soliciten el estado civil de sus clientes de hace 5 años?

Pecado Capital #2: Cargas Deltas

A la hora de realizar las extracciones, los desarrolladores ETL suelen hacer una carga inicial completa o “first” de los datos y posteriormente determinan que para no sobrecargar los sistemas origen, bastaría con extraer las novedades respecto al día que quedó desfasado. Esto es, configurar el proceso ETL para que seleccione todas las filas donde los campos de “fecha de creación” o “modificación” sea igual a sysdate -1, es decir, registros de ayer. 

• ¿Qué pasa si el ETL falla en la mitad de un día X? 
• ¿Qué pasa si el ETL no corre un día por corte de luz o porque el servidor justo se reinició? Si es un proceso que lleva meses corriendo bien, suelen no revisarlo y sin saberlo tendrá “perforaciones en los datos”

Y para terminar el último pecado...

Notas (Actualización al 2024):

1. Si el artículo es de tú interés, te recomiendo revisar la versión completa y refinada directo desde nuestro blog: ¿Qué son los ETL? 3 errores frecuentes cometidos.
2. Si crees que este contenido puede ser útil para otras personas no dudes en compartirlo. De igual forma te invitamos a seguirnos en Linkedin donde estaremos publicando nuevos artículos y videos relacionados con tecnologías, negocios y su impacto en las personas, que es justamente lo que más nos apasiona en Lituus Analytics .