En la parte anterior de esta serie, aprendimos que los Data Engineers construimos pipelines para automatizar el movimiento y procesamiento de datos de manera eficiente, escalable, y segura.
Lo que nos toca ver hoy son dos maneras (aunque no las únicas) para construir dichos sistemas. Te las presento: ETL y ELT, dos enfoques o patrones distintos —aunque complementarios— para mover datos desde su origen hasta su destino.
¿Qué son?
ETL y ELT son patrones de diseño de pipelines de datos, es decir, son una secuencia o forma estructurada de definir el flujo que siguen los datos, desde que se extraen, hasta que transforman y almacenan. Arranquemos con ETL, el que se suele utilizar con más frecuencia (aunque parece que la tendencia está empezando a ir más por ELT).
ETL — Extract, Transform, Load
ETL es el framework más antiguo y aún el más común para diseñar pipelines de datos, desgranando el flujo de datos en tres pasos secuenciales:
Extract - extracción de datos desde un sistema fuente (source system, término que conviene anotar), como lo puede ser una API, una base de datos, un archivo Excel generado por algún sistema de reportes, etc.
Transform - transformar los datos extraídos, ya sea mediante:
cambiar los tipos de datos (de número a texto)
su formato (como suele suceder con las fechas)
los nombres de los campos
aplicar lógica de negocio
eliminar elementos no deseados (como cuando te viene un precio con el signo $ y vos querés guardar números, no texto)
agregar metadatos (otro término importante) para enriquecer a los datos originales y darles contexto, etc.
o simplemente hacerlos coherentes para análisis posterior
Load - cargar los datos en una base de datos destino, un warehouse, otro archivo Excel o cualquier otro activo de datos que el usuario final de estos datos utilice
Este enfoque se usa mucho cuando:
Las transformaciones son pesadas y requieren motores externos (Python, Spark, etc.).
El destino no está preparado para hacer cómputo intensivo (por ejemplo, un Data Warehouse clásico).
Querés controlar toda la lógica de transformación fuera del sistema final.
ELT — Extract, Load, Transform
En los últimos años, con la aparición de data warehouses modernos (como Snowflake, BigQuery o Redshift), el orden de las letras cambió… y también la forma de trabajar.
En el enfoque ELT, primero se:
Extraen los datos desde la fuente,
Cargan tal cual (en crudo) en el warehouse,
Y Transforman directamente dentro del warehouse, usualmente con SQL.
La idea es aprovechar el poder de cómputo y la escalabilidad del warehouse para transformar los datos una vez cargados.
Este patrón es ideal cuando:
El warehouse es potente y soporta grandes volúmenes.
Las transformaciones están mayormente basadas en SQL.
Se quiere guardar el los datos en crudo (también llamado raw data o capa raw) sin modificar, para poder re-procesarlo o auditarlo después.
¿Cuál patrón utilizar?
Si te estás haciendo esta pregunta, dejame decirte que es perfectamente válida. ¿En qué casos cargo todo primero y luego transformo (ELT)? ¿O cuándo me conviene irme por el clásico de extraer, transformar y servir los datos al usuario final (ETL)? ¿O es que uno de los dos patrones es definitivamente mejor en general? Como me gusta decir…depende.
No existe bala de plata, no hay uno mejor que el otro per se, y es más, hasta puede suceder (y sucede) que un mismo proyecto requiera una combinación de ambos enfoques, y de hecho, en muchos proyectos se combinan ambos.
Por ejemplo:
Extraés datos crudos (E),
Los transformás con Spark (T),
Los cargás en un warehouse (L),
Y luego hacés transformaciones adicionales con SQL (T).
¿ETLT? Podríamos decir que sí 😄
Lo importante es que tu pipeline tenga claridad, trazabilidad y eficiencia, sin importar la etiqueta.
Conclusión
ETL → Extract → Transform → Load → los datos se limpian antes de almacenarse.
ELT → Extract → Load → Transform → los datos se cargan primero y se transforman dentro del warehouse.
Ninguno es “mejor”: todo depende del contexto, los recursos y los objetivos del proyecto.
Y sí, incluso puede haber pipelines que sean solo EL (sin transformación), cuando el destino ya está preparado para consumir los datos en bruto.
No existe una bala de plata que solucione y abarque todos los casos. ETL no es mejor que ELT per se, y lo inverso también es cierto. Todo depende de las necesidades del negocio, las fechas límite y las limitaciones técnicas/monetarias.
¿Ya conocías estos patrones de diseño? ¿Te pasó de estar trabajando en un ETL sin saber que lo era? En mi caso...SÍ, me pasó 😅
