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

¿Qué es un ETL?

Durante los 90’, cuando se acuña el término ETL, 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 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”.

Sin embargo, uno de los problemas que trajo esta sigla y su repetición “marketinera” es que simplifica en demasía todo lo que involucra.

¿Cuántos recursos de un proyecto utilizan los procesos ETL?

El 2004 ya se indicaba que los procesos de extracción, transformación y carga fácilmente consumen el 70% de los recursos de un proyecto ^{1 2} . El 2019 en AWS Cloud Experience Chile, se habló de 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 Data Warehouse exitoso o un fracaso rotundo, y parte del éxito pasa por incorporar actividades concretas que no se mencionan en la sigla tan repetida: ETL.

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

Un proceso 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 o analistas BI puedan crear aplicaciones, y los usuarios finales puedan tomar decisiones.

Pero Lenin,

¿Qué hace que un sistema ETL sea complejo?

Deben:

• Ajustarse a las Expectativas que los usuarios tienen sobre lo que los datos pueden hacer por ellos.
• Adaptarse a Requerimientos Regulatorios, por ejemplo el 2002 fue la ley de Sarbanes-Oxley, el 2016 GPDR y al 2030 probablemente un par más.
• Cumplir con 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 desarrollos ETL, sino más bien mencionar algunos de los pecados capitales que más he visto, en las consultorías que en Explodat realizamos.

Pecado capital #1: No preservar la historia adecuadamente

Indicar a los usuarios que el Data Warehouse o 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 un Requerimiento Regulatorio (ej. UAF) le solicite el estado civil de sus clientes de hace 5 años?

Pecado capital #2: Cargas Deltas ETL

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,

Pecado Capital #3: Falta de un monitoreo Audaz por carencia de metadatos 

Si bien a la fecha que escribo este artículo (2020), los software o ETL Tools (Informática ETL, Pentaho, Talend, etc) han mejorado en la incorporación de metadatos, aún no existe una integración End to End (Desde la BD hasta BI), incluso utilizando herramientas de un solo proveedor. Además, al menos en Chile, las empresas suelen tener herramientas de varios proveedores, por ejemplo: Base de datos SQL Server, Modelamiento con Erwin, ETL con Data Stage, BI con Tableau/Power BI.

Respecto a los procesos ETL, hay una carencia en cómo monitorean situaciones anómalas, esto debido al nulo o escaso registro de Metadatos (De Negocio, Técnicos y de Proceso de Ejecución). Confiar solo en una herramienta como Control M o CA es insuficiente.

• ¿Qué pasa si los procesos ETL demoran más de lo normal?
• ¿Hay un control estadístico de los procesos (SPC) respecto a la cantidad de filas que se procesan por cada Data Flow? ¿El número de filas recibidas desde el origen es razonable?
• ¿Cuál es el resultado de los Column Data Quality Screen?

Responder a estas preguntas es complicado sin un registro adecuado de los metadatos. Sin embargo, podemos lograrlo implementando un modelo de metadatos propio, el cual no tiene por qué ser complejo, sobre el cual se puedan aplicar controles (SPC). Aquí te explico cómo hacerlo.

Si te gusta temas de Business Intelligence y Datawarehousing estos artículos te puede interesar: Compras de empresas BI, Metodología Kimball.

Nota: Si crees que este contenido puede ser útil para otras personas no dudes en compartirlo. De igual forma te invitamos a seguirnos en Linkedin, Facebook y Youtube 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 Explodat.

Referencias

[1] The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data
[2] Building the Data Warehouse, Fourth Edition, William H. Inmon
[3] Evento AWS Cloud Experience Chile 2019 – Keynote: Parte 3 y Final