ETL vs ELT: diferencias, ejemplos y cómo elegir arquitectura
ETL y ELT describen el orden de tres operaciones: extraer, transformar y cargar. La diferencia parece pequeña, pero afecta a dónde se ejecuta la lógica, qué datos aterrizan en el destino y cómo se escalan los procesos.
ETL: transformar antes de cargar
En ETL los datos se extraen, se transforman en una capa intermedia y después se cargan en el destino. Puede ser adecuado cuando el sistema receptor debe recibir datos ya limpios, existen restricciones fuertes o la transformación previa reduce mucho el volumen.
ELT: cargar y transformar dentro del destino
En ELT los datos se cargan primero en una plataforma capaz de procesarlos y se transforman allí. Los warehouses y lakehouses cloud han popularizado este patrón porque separan almacenamiento y cómputo y permiten reutilizar el dato bruto para varios modelos.
| Criterio | ETL | ELT |
|---|---|---|
| Lugar de transformación | Antes del destino | Dentro del destino |
| Dato bruto en destino | No necesariamente | Habitualmente sí |
| Escalado | Depende del motor intermedio | Aprovecha capacidad del warehouse/lakehouse |
| Gobierno | Filtrado temprano | Exige controlar zonas raw y permisos |
Cómo elegir
- Privacidad: ¿puede el dato bruto aterrizar en el destino?
- Coste: ¿dónde resulta más barato transformar?
- Latencia: ¿necesitas datos casi en tiempo real?
- Reutilización: ¿varios equipos necesitarán el dato bruto?
- Operación: ¿qué stack sabe mantener el equipo?
Ejemplo sencillo
Una empresa recibe ventas de un ERP y campañas de una API. Con ETL podría normalizar ambas fuentes antes de cargarlas. Con ELT podría cargar tablas raw en un warehouse, versionar transformaciones SQL y construir modelos limpios después. Ninguno es universalmente superior.
La arquitectura debe minimizar pérdida de trazabilidad y facilitar pruebas. Conserva metadatos, controla esquemas y trata los errores como parte normal del pipeline.
Ejemplo de arquitectura ELT moderna
Un conector carga datos de CRM y facturación en tablas raw de un warehouse. Las transformaciones SQL crean capas staging, intermediate y marts. Las pruebas comprueban claves, nulos y relaciones. BI consulta solo los marts. Esta separación conserva trazabilidad y permite rehacer modelos sin volver a extraer la fuente.
Cuándo ETL sigue siendo preferible
Si por privacidad ciertos campos no pueden aterrizar en el destino, la transformación previa puede anonimizar o filtrar. También puede ser útil cuando el sistema destino tiene poca capacidad de cómputo o cuando existe una herramienta de integración estable que ya resuelve la lógica.
Errores de diseño
- Cargar datos sensibles “por si acaso”.
- No conservar metadatos de origen y fecha de ingesta.
- Mezclar extracción y lógica de negocio sin capas claras.
- No hacer pipelines idempotentes.
- Ignorar cambios de esquema.
Observabilidad mínima
Registra inicio y fin, filas leídas y escritas, errores, duración y versión del código. Configura alertas por ausencia de datos, cambios bruscos de volumen o fallos de calidad. Un pipeline que falla silenciosamente es más peligroso que uno que se detiene.
¿ETL y ELT pueden convivir?
Sí. Es normal filtrar o normalizar parte del dato antes de cargar y hacer transformaciones analíticas dentro del warehouse. Las siglas describen patrones, no una religión arquitectónica.
Si quieres conocer otros artículos parecidos a ETL vs ELT: diferencias, ejemplos y cómo elegir arquitectura puedes visitar la categoría Data Engineering.