En iniciativas del tipo Data Warehousing & Business Intelligence (DW/BI) y Data Science, un término que aparece con frecuencia es ETL o herramientas 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, 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.
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.
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,
Deben:
¿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 Lituus realizamos.
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.
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.
Y para terminar el último pecado,
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.
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 Data Warehousing 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. Además te invitamos a seguirnos en Linkedin, Twitter, Facebook, Instagram y Youtube. Mientras en el Blog liberamos contenido más extenso, en las RRSS publicamos semanalmente tips relacionados con Data Warehouse, BI, Data Science y Visualización de Datos que es justamente lo que más nos apasiona hacer en Lituus.
[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
