ELT (Extract, Load, Transform)

Definición

ELT son las siglas de Extract, Load, Transform — extraer, cargar, transformar. Es el patrón de pipeline de datos donde los datos brutos se extraen de los sistemas fuente (bases de datos transaccionales, APIs, plataformas SaaS, archivos), se cargan directamente en el almacén de datos de destino en su formato original, y se transforman dentro del almacén mediante SQL. El orden de las operaciones es lo que distingue a ELT de su predecesor ETL: en ELT, la transformación ocurre al final y dentro del almacén, no antes de la carga.

ELT se convirtió en el patrón dominante para cargas de trabajo analíticas a partir de la segunda mitad de la década de 2010, cuando los almacenes de datos en la nube — Snowflake, Google BigQuery, Amazon Redshift, Databricks — hicieron que ejecutar transformaciones SQL a escala dentro del almacén fuera significativamente más económico y más rápido que hacerlo en entornos de staging externos. La combinación de almacenes columnar en la nube con herramientas de transformación como dbt creó el ecosistema moderno de datos que la mayoría de los equipos de datos usan hoy.

Cómo se implementa

Un pipeline ELT completo se compone de cuatro capas funcionales que trabajan en secuencia. La primera capa es la extracción y carga: herramientas como Fivetran, Airbyte o Stitch se conectan a los sistemas fuente y replican los datos brutos en el almacén de forma incremental o por lote, sin aplicar transformaciones. La segunda capa es el almacén de datos: Snowflake, BigQuery, Redshift o Databricks reciben y almacenan los datos brutos en schemas de staging.

La tercera capa es la transformación: dbt (data build tool) lee los datos brutos del schema de staging y ejecuta modelos SQL que limpian, unen, agregan y modelan los datos en tablas analíticas dimensionales — hechos, dimensiones, métricas — dentro del mismo almacén. La cuarta capa es la orquestación: Airflow, Dagster o el propio dbt Cloud programan y coordinan la ejecución de los pipelines, gestionan dependencias entre modelos y envían alertas cuando un pipeline falla.

Ejemplo práctico

Considere una empresa de software B2B con sede en Ciudad de México que factura $2.8 millones de pesos MXN mensuales a través de Stripe y gestiona sus clientes en HubSpot. El equipo necesita calcular el MRR por segmento de cliente, el churn por cohorte de adquisición y el LTV por canal de marketing — métricas que requieren cruzar datos de Stripe, HubSpot y su base de datos de producto en PostgreSQL.

Con un pipeline ELT, Fivetran replica automáticamente las tablas de Stripe (subscriptions, charges, invoices), HubSpot (contacts, deals, companies) y PostgreSQL (events, users, feature_usage) en BigQuery cada hora. Los datos aterrizan en schemas de staging sin ninguna modificación. dbt toma esos datos brutos y ejecuta una serie de modelos SQL: primero limpia y estandariza las tablas fuente (stg_stripe_subscriptions, stg_hubspot_deals), luego construye modelos intermedios que cruzan las fuentes (int_customer_mrr) y finalmente produce tablas marts que el equipo de análisis consume directamente (mart_mrr_by_segment, mart_cohort_retention, mart_ltv_by_channel). Todo el código de transformación vive en un repositorio Git, con tests automáticos que detectan datos nulos, duplicados o valores fuera de rango antes de que las tablas marts se actualicen.

El resultado es que cualquier analista del equipo puede consultar mart_mrr_by_segment en BigQuery y obtener el MRR actualizado por segmento sin necesidad de entender la complejidad de las tablas fuente de Stripe o HubSpot. Si el equipo necesita recalcular el MRR histórico con una nueva definición de segmento de cliente, puede modificar el modelo dbt y reprocesar todos los datos históricos desde los datos brutos preservados en staging — algo imposible en un pipeline ETL que hubiera descartado los datos brutos tras la transformación inicial.

Análisis en profundidad

La razón por la que ELT desplazó a ETL no fue únicamente tecnológica — fue también económica y organizacional. En el modelo ETL tradicional, la lógica de transformación vivía en herramientas especializadas de integración de datos (Informatica, Talend, SSIS) que requerían conocimiento propietario, licencias costosas y equipos de ingeniería dedicados. Cada cambio en la lógica de negocio — una nueva definición de "cliente activo", un criterio de segmentación actualizado — requería tickets a ingeniería, ciclos de desarrollo, y pruebas en entornos de staging. El tiempo entre que un analista identificaba una necesidad de datos y tenía acceso a los datos transformados era frecuentemente de semanas. ELT, combinado con dbt, transfirió la propiedad de las transformaciones al equipo que más las necesitaba: los analistas.

El concepto de "datos brutos preservados" es más importante de lo que parece en el momento de diseñar el pipeline. En un modelo ETL donde los datos se transforman antes de cargarse, si la lógica de transformación original contenía un error o si la definición de una métrica cambia, es frecuentemente imposible reconstruir el historial correcto — los datos brutos ya no existen en el sistema. En ELT, los datos brutos siempre están disponibles en el schema de staging. Esto significa que cuando la empresa decide cambiar la definición de "suscriptor activo" de "al menos una sesión en 30 días" a "al menos una sesión en 14 días", el equipo puede reprocesar toda la historia desde los datos de eventos originales y reconstruir métricas como el churn de cohortes con la nueva definición, sin pérdida de precisión histórica. Esta capacidad de reprocesamiento es una propiedad estructural del patrón ELT, no una característica adicional.

dbt se convirtió en el estándar de facto para la capa de transformación porque resolvió los tres problemas principales que hacían difícil mantener transformaciones SQL en producción: reproducibilidad, testing y documentación. Sin dbt, los analistas escribían queries SQL en notebooks o vistas de base de datos sin control de versiones, sin tests automáticos y sin documentación estructurada. Un cambio en una vista intermediaria podía romper silenciosamente diez dashboards sin que nadie lo detectara hasta que alguien notara un número incorrecto en un reporte. dbt introdujo el concepto de "ingeniería de analytics": tratar las transformaciones SQL con las mismas prácticas de ingeniería de software que se aplican al código de producción — control de versiones con Git, testing con frameworks de prueba, documentación co-ubicada con el código, y linaje de datos automático que muestra qué tablas dependen de qué otras tablas.

La elección del almacén de datos tiene implicaciones significativas sobre el costo del pipeline ELT, y no todas las opciones son equivalentes para todos los casos de uso. Snowflake factura por cómputo (virtual warehouses) y almacenamiento de forma separada, lo que permite escalar el cómputo de transformación sin afectar el almacenamiento y es particularmente eficiente para cargas de trabajo intermitentes. BigQuery usa un modelo de facturación por bytes procesados (on-demand) o por slot reservados, lo que lo hace muy económico para equipos pequeños con queries bien optimizadas pero puede generar sorpresas de costo si los modelos dbt procesan tablas muy grandes sin particionado ni clustering adecuados. Para equipos en LATAM que trabajan con datos de clientes en pesos MXN o COP, tanto Snowflake como BigQuery tienen regiones de datos en Estados Unidos y Brasil, lo que es relevante para decisiones de residencia de datos bajo regulaciones locales.

La orquestación es frecuentemente la parte más subestimada del stack ELT. Los pipelines de datos en producción fallan: las APIs de las fuentes tienen downtime, los schemas cambian sin aviso, las credenciales expiran, los jobs de dbt superan los límites de tiempo. Sin un sistema de orquestación que detecte fallos, reintente automáticamente, gestione las dependencias entre jobs y envíe alertas al equipo correcto, los pipelines ELT se degradan silenciosamente hasta que alguien nota que los datos en el dashboard tienen tres días de antigüedad. Airflow sigue siendo el orquestador más usado por volumen de instalaciones, pero su curva de aprendizaje es pronunciada. Dagster ha ganado tracción significativa porque su modelo de activos de datos se alinea bien con el modelo de modelos de dbt, y Prefect ofrece una experiencia de usuario más accesible para equipos sin ingeniería de datos dedicada.

Errores frecuentes

• ✗

  Transformar datos antes de cargarlos en el almacén por costumbre de ETL. Muchos equipos que migran de ETL a ELT mantienen transformaciones en la capa de extracción por inercia — limpiando, normalizando o filtrando datos en Fivetran o en scripts de Python antes de que lleguen al almacén. Esto elimina la ventaja clave de ELT: la preservación de datos brutos para reprocesamiento. Si la transformación tiene un error o si la lógica de negocio cambia, no hay forma de reconstruir el historial desde los datos originales. La regla en ELT es cargar datos brutos sin modificar y hacer todas las transformaciones en dbt dentro del almacén.

• ✗

  No configurar particionado y clustering en las tablas del almacén desde el inicio. Los modelos dbt que procesan tablas grandes sin particionado por fecha o clustering por columnas de alta cardinalidad pueden generar costos de cómputo desproporcionados en BigQuery o Snowflake. Un modelo dbt que hace un full table scan de una tabla de eventos con 500 millones de filas en cada ejecución puede costar más mensualmente que la suscripción completa a una herramienta de BI. El particionado y clustering deben configurarse al crear las tablas de staging, no como una optimización posterior.

• ✗

  Omitir los tests de dbt en producción porque "ralentizan el pipeline". Los tests de dbt — not_null, unique, accepted_values, relationships — son la única barrera de calidad entre los datos brutos y los dashboards que el equipo usa para tomar decisiones. Cuando los tests se desactivan para acelerar el pipeline, los datos con problemas de calidad (NULLs donde debería haber IDs, duplicados por replicación doble, valores fuera de rango) llegan silenciosamente a las tablas marts y contaminan las métricas. Un pipeline rápido con datos incorrectos es más dañino que un pipeline lento con datos confiables.

Cómo lo rastrea Fairview

Fairview se conecta directamente a los almacenes de datos donde aterrizan los pipelines ELT — Snowflake, BigQuery, Redshift, Databricks — y lee las tablas marts que dbt produce para construir el Operating Dashboard sin requerir una capa de transformación adicional. Si el equipo ya tiene modelos dbt con métricas de MRR, churn, LTV o pipeline de ventas, Fairview puede leer esas tablas y combinarlas con datos de otras fuentes conectadas para producir inteligencia de operación consolidada. Para equipos que no tienen un stack ELT completo, Fairview ofrece conectores nativos a las fuentes más comunes — Stripe, Chargebee, HubSpot, Salesforce — que replican y modelan los datos de operación sin necesidad de mantener un pipeline ELT separado.

Preguntas frecuentes