ETL vs ELT: diagramas de pipelines, ventajas e inconvenientes y cuándo usar cada uno

Finanzas pide los ingresos por código de descuento de los últimos dos años. En una empresa, eso es un pequeño cambio de SQL y una reconstrucción, porque todas las filas de pedidos cargadas siguen en una tabla en bruto. En otra, el job nocturno nunca guardó la columna de descuento, así que alguien modifica el job y vuelve a extraer dos años de historial de producción.

La diferencia está en dónde se ejecuta la transformación. ETL (extract, transform, load) da forma a los datos en un motor aparte antes de que lleguen al almacén. ELT (extract, load, transform) copia los datos en bruto al almacén y les da forma allí con SQL. Esa decisión fija tu factura de cómputo, lo frescos que están los datos, lo fácil que es cambiar la lógica y dónde acaban los datos personales.

Este artículo recorre ambos pipelines, los compara, muestra dónde ETL sigue ganando y el híbrido habitual, y termina con un diagrama en paralelo.

Cómo funciona un pipeline ETL

En ETL, un motor de transformación se sitúa entre las fuentes y el almacén. Una ejecución nocturna:

1. Extrae las filas nuevas y modificadas, con una consulta sobre una columna updated_at o desde un flujo de change data capture.
2. Transforma esas filas en el motor: limpia valores, elimina duplicados, une datos de referencia, enmascara datos personales y reorganiza el resultado en tablas de hechos y de dimensiones.
3. Carga el resultado en el almacén con inserciones o merges.

El motor puede ser Informatica, SQL Server Integration Services (SSIS), un job de Spark o un script de Python. Las extracciones en bruto suelen quedarse en un área de staging que el job vacía tras una ejecución correcta, así que el almacén no puede responder una pregunta que el job no previó.

Cómo funciona un pipeline ELT

En ELT, el almacén hace el trabajo de transformación:

1. Extracción y carga. Un loader como Fivetran o Airbyte copia las tablas de origen a un esquema raw casi sin cambios y añade columnas de metadatos como _fivetran_synced o _airbyte_extracted_at que registran cuándo se sincronizó cada fila.
2. Transformación. Modelos SQL, normalmente gestionados con dbt, leen las tablas en bruto y construyen tablas limpias y unidas en otros esquemas.
3. Servicio. Las herramientas de BI consultan las tablas finales, que suelen llamarse marts.

ELT se extendió con los almacenes en la nube que separan almacenamiento y cómputo, como BigQuery y Snowflake: conservar copias en bruto es barato y la capacidad de transformación escala con el almacén. Como cada fila cargada se conserva, puedes corregir un modelo, añadir una columna o definir una métrica nueva y reconstruir desde el historial sin tocar el origen.

ETL vs ELT: comparación

Los calendarios importan más que el acrónimo: la sincronización por defecto de Fivetran se ejecuta cada seis horas, lo que es menos fresco que un job ETL cada hora.

Cuándo ETL sigue ganando

• Los datos personales no deben llegar en bruto. Si las direcciones de correo o los números de tarjeta en claro nunca deben llegar al almacén, enmascáralos antes de la carga. Las políticas de enmascarado del almacén no cambian lo que se guarda: el Dynamic Data Masking de Snowflake, una función de la edición Enterprise, enmascara los valores en texto plano en el momento de la consulta.
• El destino no puede transformar. Un almacén heredado de capacidad fija, un índice de búsqueda o un volcado de archivos de un socio esperan datos terminados.
• Un enriquecimiento que SQL maneja mal, como llamadas a API por fila, geocodificación, análisis de PDF o scoring con modelos, suele encajar mejor en Python o Spark.
• Streaming con latencia estricta. Apache Flink o Kafka Streams transforman los eventos segundos después de que ocurren; el diagrama de arquitectura de Kafka muestra de dónde leen.
• Un volumen que no quieres conservar. 10 000 sensores con una lectura por segundo producen 864 millones de filas al día (10 000 × 86 400). Calcular promedios de un minuto antes de la carga lo reduce a 14,4 millones (10 000 × 1 440), 60 veces menos.

El híbrido habitual

En la práctica, muchos pipelines ELT incluyen una pequeña transformación antes de la carga, a veces llamada EtLT. Transforma en tránsito solo lo que nunca debe llegar en bruto; haz todo lo demás en el almacén, donde está versionado, probado y es fácil de reconstruir.

Para los datos personales, el column hashing de Fivetran aplica hash a una columna durante la sincronización con SHA-256 y una sal por destino, de modo que los correos con hash siguen sirviendo para unir; el data blocking elimina una columna por completo. Los mappings de Airbyte pueden aplicar hash o cifrar campos por stream. Sea cual sea la herramienta, prefiere un hash con sal: un SHA-256 simple de un correo puede compararse con una lista de direcciones conocidas. Dos salvedades más: el hash cubre las sincronizaciones futuras, así que el historial requiere una resincronización, y un hash con sal es seudónimo, no anónimo. Según el RGPD, los datos seudonimizados siguen siendo datos personales (considerando 26). Este artículo no es asesoramiento legal; lee el texto oficial con tu equipo de privacidad y mantén un mapa de datos de por dónde fluyen los datos personales.

ELT con modelos SQL por capas

La guía de estructura de proyecto de dbt describe tres capas que sirven con cualquier herramienta SQL:

Los lakehouses usan la misma idea con los nombres bronze, silver y gold; consulta el diagrama de arquitectura medallion.

dbt incluye cuatro tests de datos genéricos, unique, not_null, accepted_values y relationships, y cualquier consulta que devuelva filas con errores puede convertirse en un test. Las comprobaciones de frescura detectan un loader que se detuvo en silencio. Una sola definición de source declara ambas cosas:

sources:
  - name: shop
    schema: raw_shop
    config:
      loaded_at_field: _fivetran_synced
      freshness:
        warn_after: {count: 12, period: hour}
        error_after: {count: 24, period: hour}
    tables:
      - name: orders
        columns:
          - name: id
            data_tests:
              - unique
              - not_null

dbt source freshness (o dbt freshness en dbt v2) avisa cuando el valor más reciente de _fivetran_synced tiene más de 12 horas y da error pasadas 24.

Orquestación y calidad de datos

Un orquestador ejecuta los pasos en orden. En Airflow, un DAG (tareas con dependencias y un calendario) lanza la sincronización del loader, espera a que termine y luego ejecuta dbt. La integración de Dagster con dbt convierte cada modelo de dbt en un asset, una tabla que debería existir, de modo que un mart puede depender directamente de la tabla que escribe una sincronización de Fivetran.

En cualquier caso, dbt build mantiene los datos erróneos fuera de los dashboards: ejecuta modelos, tests, snapshots y seeds en orden de DAG, y un test fallido omite todo lo que viene después. Añade comprobaciones de frescura y una alerta al equipo responsable, y tanto los datos erróneos como los antiguos aparecerán antes de que lo note un stakeholder.

Reverse ETL, que Airbyte llama data activation, va en sentido contrario: copia datos modelados del almacén a herramientas como un CRM o un servicio de soporte. En el momento de escribir esto (noviembre de 2026), Hightouch lo ofrece como producto independiente, y Fivetran (que adquirió Census) y Airbyte lo incluyen junto con la ingesta.

El diagrama ETL vs ELT

Cómo leerlo:

• Dos carriles, mismos extremos: la misma base de datos de pedidos Postgres y los mismos dashboards de BI. Solo cambia el medio.
• El ámbar marca la transformación: un motor aparte antes del almacén en ETL, el cuadro de modelos dbt dentro del almacén en ELT.
• Los marcos del almacén muestran lo que se guarda. El de ETL solo contiene fct_orders; el de ELT contiene raw.orders tal como se cargó, los modelos y marts.fct_orders.
• La arista morada es el híbrido: el loader aplica hash a los datos personales antes de que las filas lleguen.
• El bloque Markdown enumera el orden de ejecución de ELT, los umbrales de frescura y qué esquema lee la BI.

Cómo dibujar con claridad diagramas ETL y ELT

• Pon la transformación donde se ejecuta. Dibujar la transformación de ELT fuera del almacén oculta su principal coste y su principal riesgo.
• Dibuja el almacén como un límite. Raw, staging y marts dentro de un mismo marco son esquemas de un solo sistema, no bases de datos separadas.
• Etiqueta las aristas con lo que se mueve (filas en bruto, filas con hash, tablas construidas) y con el calendario cuando importe.
• Marca dónde se enmascaran los datos personales y dónde siguen existiendo en claro.
• Muestra capas, no cada modelo. Basta una tabla de ejemplo por capa; el linaje pertenece a la documentación que genera dbt.
• Separa el flujo de control. Dibuja los disparadores del orquestador como aristas discontinuas para que nadie los confunda con datos.

El diagrama de arquitectura de pipeline de datos muestra un pipeline completo con CDC, Kafka y un almacén.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos nodos Marco del pack Básico, uno encima del otro, para los carriles ETL y ELT, y un Marco anidado para el almacén en cada carril, en la misma posición horizontal.
3. En el carril ETL, añade un nodo Postgres del pack Datos, una Caja de Básico para el motor de transformación, un nodo Almacén de datos del pack Datos para fct_orders dentro del marco del almacén, y una Caja de Básico para la BI. Etiqueta las aristas: raw rows, cleaned and conformed rows, SQL queries.
4. En el carril ELT, añade un nodo Postgres y una Caja de Básico para el loader. Dentro del marco del almacén, añade nodos Almacén de datos para raw.orders y marts.fct_orders, con una Caja de Básico para los modelos dbt entre ellos. Termina con una Caja de Básico para la BI y etiqueta las aristas igual.
5. Colorea de ámbar las dos cajas de transformación y de morado la arista de salida del loader. Añade notas de Texto de Básico bajo los nodos que necesiten explicación y una breve leyenda de colores.
6. Añade un bloque Markdown del pack Básico con el orden de ejecución y los umbrales de frescura.

Si el pipeline ya existe como diagrama de flujo de Mermaid, pégalo en la herramienta de Mermaid a diagrama editable para obtener un primer borrador. El ejemplo usa 15 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Cuál es la diferencia entre ETL y ELT? Dónde se ejecuta la transformación. ETL transforma los datos en un motor aparte y carga solo el resultado. ELT carga primero los datos en bruto en el almacén y los transforma allí con SQL, de modo que la copia en bruto sigue disponible para reconstrucciones.

¿Está obsoleto ETL? No. ELT es la opción habitual por defecto en los almacenes en la nube, pero ETL sigue encajando cuando los datos personales deben enmascararse antes de llegar, cuando el destino no puede transformar, y para enriquecimientos pesados o streaming de baja latencia.

¿Es dbt una herramienta ETL? dbt cubre la T de ELT. Ejecuta modelos SQL y tests dentro de tu almacén, pero no extrae ni carga datos; eso lo hace un loader como Fivetran o Airbyte.

¿Es ELT más barato que ETL? Depende del volumen y de los hábitos. ELT elimina el motor aparte, pero factura cada ejecución de modelo como cómputo del almacén y almacena copias en bruto. Los modelos incrementales mantienen los costes bajos; las reconstrucciones completas cada hora de tablas grandes, no.

¿Qué es reverse ETL? Copiar datos modelados del almacén a herramientas operativas como un CRM. Debe leer de los marts, ejecutarse según un calendario y recibir los mismos tests y la misma responsabilidad que cualquier otro pipeline.

Empieza gratis — un puesto, sin tarjeta de crédito.