ETL vs ELT: cómo llegan los datos a tus dashboards

ETL y ELT son dos formas de mover datos desde los sistemas origen hasta un lugar donde puedas analizarlos. En ETL (Extract, Transform, Load: extraer, transformar, cargar) los datos se limpian y se transforman antes de cargarlos al warehouse; en ELT (Extract, Load, Transform) primero se cargan los datos crudos y se transforman dentro del warehouse, casi siempre con SQL. ELT se volvió el patrón habitual con los data warehouses en la nube, pero ETL sigue siendo la mejor opción en muchos casos.

Los tres pasos: extraer, transformar y cargar

Todo pipeline que alimenta un dashboard hace las mismas tres tareas, sin importar el orden.

• Extraer: leer los datos de las fuentes. Puede ser la base de un ERP o punto de venta, un CRM, una hoja de cálculo en SharePoint, un CSV descargado del portal de un cliente minorista o una API como Shopify o Google Ads.
• Transformar: dejar los datos listos para usar. Corregir tipos de datos, estandarizar nombres ("FL", "Fla.", "Florida"), quitar duplicados, unir tablas, calcular columnas y organizar todo en hechos y dimensiones.
• Cargar: escribir los datos en su destino, normalmente un data warehouse, un lakehouse o una base de datos a la que se conecta tu herramienta de BI.

La diferencia entre ETL y ELT es simplemente dónde y cuándo ocurre la transformación.

Cómo funciona ETL

En ETL, una herramienta o servidor aparte extrae los datos, los transforma con su propio motor y carga en el warehouse solo las tablas terminadas y limpias.

Fuentes → herramienta ETL (transforma) → Warehouse → Dashboard

Fue el enfoque estándar durante décadas, cuando el almacenamiento y la capacidad de cómputo del warehouse eran caros y limitados. Ejemplos clásicos son SQL Server Integration Services (SSIS), Informatica y Talend. Power Query, el motor de Excel y Power BI, también sigue el patrón ETL: extrae, transforma con su propio motor (o pliega pasos hacia la fuente) y carga el resultado en tu modelo.

Ventajas de ETL:

• Al warehouse solo llegan datos limpios y aprobados.
• Los campos sensibles se pueden enmascarar o eliminar antes de llegar al destino, lo que ayuda con requisitos de privacidad.
• Funciona bien con bases locales que tienen poca capacidad de cómputo.

Desventajas: la lógica de transformación vive en otra herramienta, a veces en un diseñador visual difícil de revisar o versionar. Si necesitas un campo que no cargaste, tienes que cambiar el pipeline y volver a cargar.

Cómo funciona ELT

En ELT copias los datos crudos al warehouse tal como vienen y luego los transformas ahí mismo con el cómputo del warehouse, normalmente con SQL.

Fuentes → Warehouse (crudo) → Transformación en SQL → Tablas limpias → Dashboard

Los warehouses en la nube como Snowflake, BigQuery, Databricks y Microsoft Fabric separan almacenamiento y cómputo y pueden escalar el procesamiento cuando hace falta, así que es práctico guardar los datos crudos y transformarlos ahí. Un stack ELT típico usa una herramienta de carga (por ejemplo Fivetran, Airbyte o Azure Data Factory) y una de transformación como dbt, que organiza modelos SQL, pruebas y documentación. Nuestra introducción a dbt lo explica a fondo.

Una transformación ELT sencilla podría verse así, convirtiendo una tabla cruda de pedidos en una tabla de staging limpia:

CREATE OR REPLACE VIEW staging.stg_orders AS
SELECT
    CAST(order_id AS INT)                   AS order_id,
    CAST(order_date AS DATE)                AS order_date,
    UPPER(TRIM(store_code))                 AS store_code,
    CAST(quantity AS INT)                   AS quantity,
    CAST(unit_price AS DECIMAL(10, 2))      AS unit_price,
    CAST(quantity AS INT)
      * CAST(unit_price AS DECIMAL(10, 2))  AS revenue
FROM raw.orders
WHERE order_id IS NOT NULL;

(CREATE OR REPLACE VIEW funciona en PostgreSQL, Snowflake, BigQuery y Databricks; en SQL Server usa CREATE OR ALTER VIEW).

Ventajas de ELT:

• Conservas los datos crudos, así que puedes rehacer o agregar transformaciones sin volver a extraer.
• Las transformaciones son SQL simple que los analistas pueden leer, probar y guardar en control de versiones.
• La carga es rápida y sencilla, porque no se hace nada pesado en el camino.

Desventajas: guardas más datos, los datos sensibles crudos llegan al warehouse (así que el control de acceso es clave) y las transformaciones mal escritas pueden subir los costos en plataformas que cobran por uso.

ETL vs ELT lado a lado

En la práctica, casi todos los equipos combinan ambos. Un pipeline puede hacer una limpieza ligera al extraer (estilo ETL), cargar a un lakehouse y hacer el modelado pesado con SQL (estilo ELT). Las etiquetas importan menos que saber dónde vive cada parte de la lógica. Microsoft Fabric es un buen ejemplo de esta mezcla: Dataflows Gen2 usa la conocida interfaz de Power Query para pasos estilo ETL, mientras que los warehouses y notebooks del mismo espacio de trabajo hacen transformaciones estilo ELT con SQL o Python.

¿Cuál conviene a un equipo pequeño?

Para un negocio pequeño o un analista que trabaja solo, la respuesta depende de dónde están los datos y cuántas fuentes hay.

1. Una o dos fuentes, pocos datos: Power Query en Excel o Power BI ya es una herramienta ETL. Limpia ahí los datos, modela en esquema estrella y programa la actualización. No necesitas warehouse.
2. Varias fuentes, datos en un servidor de la empresa: carga todo en SQL Server o PostgreSQL y crea vistas de reportes. Es un ELT ligero que muchos equipos usan por años.
3. Muchas fuentes SaaS, volumen creciente, varios analistas: considera un warehouse en la nube con una herramienta de carga administrada y dbt. Compara plataformas en nuestra guía Snowflake vs BigQuery vs Databricks vs Fabric y revisa la página de precios de cada proveedor, porque el costo depende mucho del uso.

Sea cual sea el enfoque, la meta final es la misma: tablas de hechos y dimensiones limpias con una granularidad bien definida. Si esos términos son nuevos para ti, lee primero fundamentos de data warehouse.

Errores comunes en los pipelines

• Sin monitoreo. Un pipeline que falla en silencio es peor que no tener pipeline. Configura alertas para cargas fallidas y para conteos de filas que bajen de forma inesperada.
• Recargas completas para siempre. Recargar todo cada noche está bien al principio; cuando crecen los datos, pasa a cargas incrementales basadas en una fecha o en una columna de control de cambios.
• Lógica sin documentar. Anota dónde ocurre cada transformación y por qué, para que el próximo analista pueda mantenerla.
• Ignorar la calidad de datos. Agrega validaciones de duplicados, nulos en columnas clave y valores inesperados justo después de cargar.
• Mezclar zonas horarias. Las fuentes suelen guardar horas en zonas distintas. Conviértelas a un solo estándar al transformar o los totales diarios no cuadrarán con los reportes de origen.

Próximos pasos

1. Dibuja tu flujo de datos actual: cada fuente, dónde se limpia y dónde se carga.
2. Identifica cualquier regla de negocio calculada en más de un lugar y unifícala.
3. Prueba escribir un paso de limpieza como vista SQL en lugar de un paso de Power Query y compara.

Mira: lecciones en video

▶

▶

Preguntas frecuentes