ETL frente a ELT: dónde se ejecuta la transformación y qué cambia con ello

Qué es

La página citada de Azure Architecture Center describe extract, transform, load (ETL) como un proceso de integración de datos que consolida datos de diversas fuentes en un almacén unificado, con la fase de transformación ejecutada por un motor especializado, a menudo a través de tablas de staging, siendo las operaciones típicas filtrar, ordenar, agregar, unir, limpiar, deduplicar y validar. Indica que extract, load, transform (ELT) se diferencia de ETL únicamente en dónde tiene lugar la transformación: en el pipeline de ELT, la transformación ocurre en el almacén de datos de destino, usando las capacidades de procesamiento propias de ese almacén en lugar de un motor independiente. La página señala que esto elimina el motor de transformación de la arquitectura, que escalar el almacén de destino también escala el pipeline, y que ELT solo funciona bien cuando el sistema de destino es lo bastante potente como para transformar los datos con eficiencia. Herramientas como dbt se sitúan en la T de ELT; su documentación la describe como la transformación de los datos en bruto del almacén en productos de datos fiables.

Por qué importa

El orden de las letras cambia cuatro aspectos prácticos. Dónde se factura el cómputo: ELT se paga con tiempo de consulta del almacén, ETL con un clúster o servicio independiente. Qué llega en bruto: ELT copia las tablas de origen tal como están, por lo que las decisiones de minimización de datos deben tomarse en la extracción o mediante el control de acceso en el almacén. Cómo funcionan las reejecuciones: una transformación ELT es una consulta sobre datos que todavía están ahí, por lo que una corrección significa volver a ejecutar SQL; una corrección ETL puede requerir volver a extraer de una fuente que entretanto ha cambiado. Quién puede cambiar la lógica: el SQL del almacén es legible por analistas; el código de un motor independiente pertenece a quien ejecute ese motor.

Cómo aplicarlo

• Elegir ELT cuando el destino es un almacén columnar o un lakehouse que ya maneja el volumen de datos, y las transformaciones pueden expresarse como SQL sobre tablas cargadas.
• Elegir ETL, o un paso de transformación previo a la carga, cuando la fuente contiene datos que nunca deben llegar al destino (secretos, campos excluidos por política), cuando el destino es una base de datos operativa pequeña, o cuando la transformación necesita código o bibliotecas que el destino no puede ejecutar.
• En cualquiera de los dos casos, mantener la extracción en bruto inmutable y separada de las salidas transformadas, de modo que una transformación pueda reproducirse a partir de la misma entrada.
• Registrar, para cada tabla de salida, qué instantánea de origen y qué versión de la transformación la produjeron.

Trampas

Cargar todo en bruto y posponer el modelado produce un almacén que solo puede consultar quien lo creó. La facturación de ELT escala con la frecuencia con la que los modelos se reconstruyen por completo; los modelos incrementales necesitan la disciplina de idempotencia descrita en el artículo relacionado. Los diseños mixtos, con parte de la limpieza antes de la carga y parte después, deben documentar cuál es cuál, o una regla de deduplicación termina aplicándose dos veces o ninguna.