Inicio › Tecnología › Proceso ELT
El proceso ELT (Extract, Load, Transform) invierte el orden clásico del ETL: primero se extraen los datos de sus fuentes y se cargan tal cual, en bruto, dentro del almacén de datos de destino, y solo después se aplican las transformaciones necesarias usando la propia capacidad de cómputo de ese almacén. Este enfoque se ha popularizado con la llegada de data warehouses en la nube con gran potencia de procesamiento paralelo, como Snowflake, BigQuery o Redshift, capaces de ejecutar transformaciones complejas sobre volúmenes enormes de datos mucho más rápido qué un servidor ETL intermedio. Herramientas como Fivetran o Airbyte se encargan de la extracción y carga automatizada desde decenas de fuentes, mientras qué dbt (data build tool) gestiona la capa de transformación mediante consultas SQL versionadas.
Es cargar primero los datos en bruto donde vayan a analizarse, y ordenarlos y limpiarlos después, dentro de ese mismo sitio, en lugar de limpiarlos antes de moverlos. Tiene sentido cuando el almacén de destino es tan potente qué transformar los datos ahí dentro es más rápido y barato qué hacerlo en un paso intermedio separado.
Una empresa qué centraliza datos de su CRM, su plataforma de publicidad y su ERP en Snowflake usa Fivetran para replicar automáticamente las tablas en bruto de cada fuente cada hora, sin transformación previa. Después, un equipo de analistas escribe modelos en dbt qué combinan esas tablas —por ejemplo, cruzando el coste de una campaña publicitaria con las ventas atribuidas— directamente con SQL dentro de Snowflake, versionando cada cambio en el modelo como si fuera código.
Al cargar los datos en bruto sin transformar, se conserva toda la información original por si en el futuro hace falta un análisis distinto al previsto inicialmente. Además, aprovecha la capacidad de cómputo del propio almacén en la nube, qué suele escalar mejor qué un servidor ETL dedicado.
Al contrario, necesita más disciplina, porque los datos en bruto sin transformar llegan directamente al almacén y quedan accesibles antes de haberse validado o limpiado. Por eso las transformaciones con dbt suelen incluir tests automáticos qué se ejecutan justo después de la carga.
No necesariamente. Si el volumen de datos es moderado y el almacén de destino no tiene gran capacidad de cómputo paralelo, un ETL tradicional bien diseñado puede seguir siendo más eficiente y más barato qué pagar por transformar datos dentro de un almacén en la nube facturado por consumo.