ETL (Extract, Transform, Load)

Definición

ETL (Extract, Transform, Load) es el patrón de pipeline de datos en el que la información pasa por tres etapas secuenciales. En la fase de extracción (Extract), los datos se obtienen de los sistemas fuente — bases de datos transaccionales, APIs, archivos planos, sistemas ERP, plataformas SaaS. En la fase de transformación (Transform), los datos extraídos se procesan en un entorno de staging intermedio: se limpian, normalizan, enriquecen, agregan y reestructuran para ajustarse al esquema del sistema de destino. En la fase de carga (Load), los datos ya transformados se cargan en el warehouse o base de datos analítica de destino. La característica definitoria del ETL es que la transformación ocurre antes de la carga — los datos llegan al warehouse ya procesados.

Este patrón emergió en los años noventa cuando los warehouses on-premise eran caros de operar y el almacenamiento era costoso. Transformar los datos antes de cargarlos al warehouse significaba que solo los datos necesarios y ya procesados ocupaban espacio en el sistema más costoso. El entorno de staging — generalmente un servidor de procesamiento separado — ejecutaba la lógica de transformación usando herramientas especializadas como Informatica PowerCenter, IBM DataStage o Microsoft SSIS. Estos procesos batch se ejecutaban típicamente durante la noche, cuando la carga de los sistemas transaccionales era menor.

Cómo se implementa

Un pipeline ETL moderno atraviesa las siguientes etapas técnicas. La extracción puede ser full (extracción completa de la tabla fuente en cada ejecución) o incremental (solo los registros nuevos o modificados desde la última ejecución, típicamente mediante CDC, timestamps o watermarks). La extracción incremental es más eficiente pero requiere que la fuente tenga una columna de timestamp o un mecanismo de detección de cambios confiable.

La orquestación del pipeline — cuándo y en qué orden se ejecutan las etapas, cómo se manejan los fallos, cómo se reintenta una ejecución parcial — es tan importante como la lógica de transformación. En entornos modernos, la orquestación se gestiona con Apache Airflow, Dagster o Prefect, que permiten definir los pipelines como código (DAGs), monitorear las ejecuciones y configurar alertas ante fallos.

Ejemplo práctico

Considere una empresa de manufactura en Monterrey con un ERP on-premise (SAP) que gestiona órdenes de producción, inventario y costos. El equipo de finanzas necesita un reporte diario de costo por SKU y margen bruto por línea de producto, consolidando datos del ERP con datos de ventas de su plataforma de e-commerce propia y datos de logística de un proveedor externo. Los tres sistemas tienen esquemas distintos, monedas distintas (pesos mexicanos y dólares) y frecuencias de actualización distintas.

El pipeline ETL extrae cada noche las órdenes de producción del ERP (conversión de moneda a MXN a la tasa del día), las ventas de la plataforma web (normalización de categorías de producto al catálogo maestro del ERP), y los costos logísticos del proveedor externo (archivo CSV enviado por SFTP). En el entorno de staging, un proceso Python aplica las reglas de negocio: asignación de costos indirectos por SKU según el modelo de costeo definido por el Controller, validación de que la suma de costos por SKU no supera el 95% del precio de venta (flag de error para revisión manual), y generación de la tabla margen_diario_sku. Solo esta tabla procesada se carga al data warehouse de Amazon Redshift. El equipo de finanzas accede al reporte en Tableau a las 7:00 AM, con datos de cierre del día anterior. El proceso completo tarda 42 minutos en el servidor de staging y requeriría 3.5 horas si se ejecutara directamente en Redshift por las licencias de cómputo.

Este es un caso donde ETL es la elección correcta: la lógica de transformación es compleja y requiere Python (no solo SQL), el warehouse tiene restricciones de cómputo por costo de licencias, y los datos no necesitan frescura inferior a 24 horas. Si la empresa migrara a Snowflake o BigQuery con cómputo elástico y sin licencias por hora de cómputo, la evaluación cambiaría — pero para su infraestructura actual, ETL es la arquitectura más eficiente.

Análisis en profundidad

La historia del ETL es la historia de los constraints de infraestructura que lo hicieron necesario. En los años noventa, un terabyte de almacenamiento en disco costaba decenas de miles de dólares, y el cómputo analítico en un warehouse (Oracle, Teradata) se facturaba por CPU hora o por volumen de datos procesados. Cargar datos crudos al warehouse era una decisión de costo prohibitivo — transformar antes de cargar significaba cargar menos datos, lo que reducía el almacenamiento y el cómputo. El ETL también permitía a los equipos de tecnología centralizar y estandarizar la lógica de transformación en herramientas especializadas, separando la "suciedad" de los sistemas fuente del "orden" del warehouse analítico.

El desplazamiento de ETL por ELT en la segunda mitad de la década de 2010 fue el resultado de tres cambios simultáneos en la economía de la infraestructura de datos. El almacenamiento en la nube (S3, GCS, Azure Blob) hizo el costo por gigabyte marginal — guardar datos crudos dejó de tener un costo prohibitivo. Los warehouses en la nube (Snowflake, BigQuery, Redshift) adoptaron arquitecturas de cómputo elástico desacoplado del almacenamiento, haciendo el cómputo analítico masivamente escalable sin el costo fijo de una licencia de Teradata. Y dbt (data build tool), lanzado en 2016, democratizó las transformaciones SQL en el warehouse, permitiendo a analistas sin experiencia en ingeniería definir transformaciones como código versionado sin necesidad de infraestructura de staging separada. Estos tres cambios convergentes eliminaron las razones económicas que hacían ETL la elección racional.

Sin embargo, ETL mantiene ventajas estructurales en casos de uso específicos que ELT no resuelve bien. El procesamiento de streams en tiempo real — eventos de clickstream, transacciones financieras, telemetría de IoT — requiere transformación antes de la persistencia cuando la latencia importa. Apache Kafka con Kafka Streams o Apache Flink aplican transformaciones en tiempo real sobre el stream antes de escribir al sistema de destino; este es ETL en tiempo real, y no tiene un sustituto directo en el paradigma ELT. Del mismo modo, los requisitos de residencia de datos — regulaciones que impiden que datos de clientes de ciertos países salgan de la jurisdicción sin transformación — pueden requerir que la anonimización o pseudonimización ocurra antes de la carga al warehouse, si el warehouse está en una región distinta de la de los sistemas fuente.

La frontera entre ETL y ELT es más difusa en la práctica que en la teoría. Herramientas como Fivetran y Airbyte — que la industria clasifica como herramientas de ELT porque cargan datos crudos al warehouse — pueden aplicar transformaciones ligeras antes de la carga (normalización de tipos, filtrado de columnas sensibles, hashing de PII). En ese sentido, implementan un modelo híbrido que la industria a veces llama ETLT (Extract, Transform, Load, Transform) o simplemente un pipeline con transformaciones en múltiples etapas. La terminología importa menos que la pregunta de fondo: ¿dónde ocurre qué transformación, por qué razón, y quién es responsable de mantenerla?

La elección entre ETL y ELT tiene implicaciones organizacionales más allá de la arquitectura técnica. Los pipelines ETL tradicionales, construidos con herramientas como Informatica o SSIS, tienden a encapsular la lógica de negocio en artefactos binarios o interfaces gráficas difíciles de versionar, revisar y debuggear. ELT con dbt externaliza esa lógica en SQL versionado en git, con tests automatizados y documentación generada automáticamente. Esta diferencia en mantenibilidad y visibilidad es tan relevante como la diferencia en el momento de la transformación. Organizaciones con pipelines ETL legacy frecuentemente tienen knowledge silos profundos: solo la persona que construyó el pipeline sabe exactamente qué hace. Migrar a ELT con dbt no es solo un cambio técnico — es un cambio en cómo el conocimiento sobre los datos se documenta, versiona y comparte en la organización.

Errores frecuentes

• ✗

  Usar ETL por defecto sin evaluar si ELT es más adecuado. Muchos equipos de tecnología con experiencia histórica en Informatica, SSIS o herramientas similares reproducen el patrón ETL al migrar a la nube, cuando la arquitectura ELT con un warehouse moderno y dbt sería más eficiente, más mantenible y más barata. La pregunta correcta no es "¿cómo implementamos nuestro ETL en la nube?" sino "¿cuál es la arquitectura de pipeline más apropiada para nuestros casos de uso y nuestra infraestructura actual?"

• ✗

  Encapsular lógica de negocio crítica en herramientas ETL sin documentación ni versionado. Los pipelines ETL construidos en herramientas visuales (Informatica, SSIS, Talend) frecuentemente encapsulan reglas de negocio complejas — cómo se define un cliente activo, cómo se asignan los costos indirectos, qué registros se excluyen y por qué — en flujos gráficos sin documentación externa. Cuando el desarrollador original deja la organización, esa lógica se vuelve opaca e imposible de auditar. Toda lógica de negocio en pipelines ETL debe estar documentada explícitamente, idealmente en código fuente versionado en git.

• ✗

  No implementar manejo de errores ni reintentos en los pipelines ETL. Un pipeline ETL que falla silenciosamente — sin alertas, sin logs, sin mecanismo de reintento — produce un warehouse con datos desactualizados que los consumidores usan sin saber que están viendo números de hace tres días. Todo pipeline de producción debe tener alertas ante fallo, registro de auditoría de cada ejecución (inicio, fin, registros procesados, errores), y una estrategia definida de reintento para fallos transitorios versus fallos de lógica que requieren intervención manual.

Cómo lo rastrea Fairview

Fairview se conecta a los warehouses y fuentes de datos resultantes de los pipelines ETL o ELT de la organización, sin requerir que los equipos modifiquen su arquitectura de ingesta existente. Si los datos operativos — ingresos, costos, métricas de retención, pipeline de ventas — llegan al warehouse mediante ETL o mediante ELT, Fairview los consume desde el warehouse y construye sobre ellos las métricas de operating intelligence que los operadores necesitan. La plataforma monitorea la frescura de los datos recibidos y genera alertas cuando los datos del warehouse tienen más antigüedad de lo esperado — lo que puede indicar un fallo en el pipeline ETL upstream. De esta forma, Fairview actúa como una capa de observabilidad operativa que detecta cuando los pipelines de datos fallan antes de que los operadores tomen decisiones basadas en números desactualizados.

Preguntas frecuentes