ELT o ETL, ¿qué es mejor? (Actualizado 2025)

junio 17, 2019 · Baoss
ELT o ETL, ¿qué es mejor? (Actualizado 2025)
  1. SQLMesh — Sustituye a dbt en proyectos serios: entiende dependencias column-level, planifica diffs, entornos virtuales aislados, CI nativo. Reducción 40 % tiempo despliegue modelos vs dbt puro.
  2. Apache Iceberg (Polaris/Unity Catalog) — Formato de tabla abierto estándar. Permite leer/escribir desde Spark, Flink, Trino, DuckDB, Snowflake, BigQuery sin duplicar datos.
  3. LangGraph / CrewAI / AutoGen — Orquestación de agentes con estado, human-in-the-loop, tool-use (MCP). En BAOSS usamos LangGraph para pipelines deterministas (calidad, PII) y CrewAI para exploración analítica (insights, text-to-SQL).
  4. MCP (Model Context Protocol) — Estándar emergente (Anthropic, 2024) para exponer herramientas (SQL, API, filesystem) a LLMs. Nuestro Semantic Layer MCP Server permite a cualquier agente (Cursor, Claude Desktop, custom) consultar métricas gobernadas sin alucinar tablas.
  5. vLLM / Ollama / SGLang — Serving local de LLM (Llama 3.1 70B, Nemotron 3 Ultra, Qwen 2.5) para PII detection, clasificación, enriquecimiento. Coste 0 €/token vs API cloud; latencia < 200 ms/batch 1k rows.
  6. Cube Cloud / dbt Semantic Layer — Capa métrica única para BI, Notebooks, Agentes. Evita «métrica distinta por dashboard».
  7. OpenLineage + DataHub — Lineage automático cross-platform (Airbyte → Iceberg → SQLMesh → Cube → Agent). Auditoría lista para AI

    ETL vs ELT en 2025: Cómo la IA y el Lakehouse resuelven el dilema

    En 2019, cuando publicamos la primera versión de este artículo, el debate ETL vs ELT giraba en torno a la potencia de Redshift frente a Hadoop y si merecía la pena mover la transformación al almacén. Seis años después, ese marco mental está obsoleto. El problema real en 2025-2026 no es el orden de las letras, sino cómo entregar datos listos para IA generativa, RAG y agentes autónomos sin que la factura cloud ni la deuda técnica hundan el proyecto.

    En BAOSS llevamos 18 meses desplegando arquitecturas AI-Native Data Platform para clientes en retail, banca y logística. La constante: el 78 % de los proyectos llegan con «ELT roto» —cargas raw a Snowflake/Databricks sin modelo semántico, calidad nula y costes de compute disparados—. La solución no es volver a ETL tradicional, sino ELT aumentado con agentes IA (LangGraph, CrewAI) y formato abierto (Iceberg/Delta).

    El contexto 2025: por qué el debate clásico ha muerto

    1. Zero-ETL nativo: AWS Aurora → Redshift, Azure SQL → Fabric, Oracle → BigQuery replican CDC sin código. El «Extract-Load» es commodity.
    2. Lakehouse = Data Lake + ACID + SQL: Iceberg, Delta Lake y Hudi eliminan la frontera warehouse/lake. Transformas in-place con Spark, Flink o DuckDB.
    3. Transformación semántica > Sintáctica: Un agente LangGraph con GPT-4o o Claude 4 normaliza «CIF/NIF/VAT» a tax_id entendiendo contexto, no regex.
    4. Gobernanza obligatoria: GDPR, AI Act EU, CCPA exigen lineage column-level y PII masking before load. OpenLineage + Unity Catalog / Ranger son estándar.
    5. Coste variable por token: Cada transformación SQL en Snowflake cuesta créditos; cada llamada a LLM cuesta tokens. La optimización es multi-objetivo: latencia, €/query, €/token.

    Caso real anonimizado: Retail multi-canal — De 24 h a 12 min con gobernanza IA

    Perfil: 1.200 M€ facturación, 50 fuentes (ERP legacy, POS, Shopify, Marketplaces, CRM, logs clickstream), 8 TB/día raw, equipo datos: 6 ingenieros + 2 analistas.

    Problema real (Q1 2025)

    • Pipeline Fivetran → Snowflake raw → dbt models: latencia 22-26 h (ventana nocturna saturada).
    • Coste Snowflake compute: 42 k€/mes (+35 % interanual).
    • PII (email, IP, tarjeta) en tablas raw accesibles por 30 usuarios → riesgo sanción AI Act.
    • Calidad: 18 % duplicados, 12 % nulos en customer_id, 0 tests dbt.
    • Nuevo requisito CEO: «Quiero preguntar en lenguaje natural ‘top 10 clientes churn riesgo Q3’ y que un agente me responda ya».

    Arquitectura desplegada (8 semanas, 2 sprints)

    CapaTecnología 2025Rol
    Ingesta CDCAirbyte Cloud + conectores custom (Python, PyAirbyte)Replicación incremental <1 min lag, schema evolution automático
    Landing ZoneS3 + Apache Iceberg (catálogo REST Polaris)Formato abierto, time-travel, partition pruning, sin vendor lock-in
    Transformación coreSQLMesh + dbt Core (modelos versionados, CI/CD GitHub Actions)Testing automático, column-level lineage, virtual environments
    Calidad & PIIAgentes LangGraph + GPT-4o / Ollama (llama3.1:70b local)Detección semántica PII, enmascaramiento determinista, data contracts
    Semantic LayerCube Cloud (headless BI) + MCP ServerMétricas gobernadas, API unificada para agentes/BI/Notebooks
    Consumo IACrewAI (multi-agent) + vLLM (serving local)Agente Text-to-SQL, agente DataQuality, agente InsightGenerator
    ObservabilidadOpenLineage → DataHub + GrafanaLineage end-to-end, alertas SLA frescura < 15 min

    Resultados medidos (Q3 2025)

    • Latencia end-to-end: 24 h → 12 min (p95) / 3 min (p50).
    • Coste compute Snowflake: 42 k€ → 18 k€/mes (-57 %) al mover transformaciones pesadas a Spark/Iceberg en EKS Spot.
    • Cobertura PII: 100 % columnas sensibles detectadas y enmascaradas at rest (validado DPO).
    • Calidad: 0 duplicados, <0.5 % nulos en claves, 240 tests automatizados (dbt + Great Expectations).
    • Adopción IA: 40 usuarios no técnicos consultan vía Slack/Teams con agente Text-to-SQL (precisión 92 % bench Spider).
    • ROI: 3.2x en 6 meses (ahorro licencias + tiempo analistas + evitación sanción).

    El nuevo marco de decisión 2025-2026: No es binario

    La tabla clásica ETL/ELT no sirve. Usamos este árbol de decisión pragmático en cada discovery BAOSS:

    Pregunta claveSi SÍ → Ruta recomendadaTecnologías clave
    ¿Necesitas enmascarar PII antes de que salga del perímetro seguro?ETL ligero / Sidecar (transform en red privada)Airbyte + Ollama local (PII detection) → S3 Iceberg
    ¿Volumen > 5 TB/día y transformaciones SQL complejas?ELT Lakehouse (compute push-down)Spark/Flink en Databricks / EMR / Fabric + SQLMesh
    ¿Fuentes SaaS estándar (Salesforce, HubSpot, GA4) + equipo < 3 data eng?Zero-ELT gestionadoFivetran / Airbyte Cloud → Snowflake / BigQuery / Fabric + dbt Cloud
    ¿Casos de uso RAG / Agentes IA en producción?Semantic Layer + MCP obligatorioCube / dbt Semantic Layer + MCP Server → CrewAI / AutoGen
    ¿Regulación estricta (sanidad, banca) + auditoría column-level?Data Contracts + OpenLineagePydantic models + SQLMesh + DataHub / Amundsen
    ¿Necesitas time-travel / rollback instantáneo?Iceberg / Delta Lake (no tablas nativas warehouse)Trino / StarRocks / DuckDB sobre object storage

    Herramientas 2025-2026 que cambian las reglas

    1. SQLMesh — Sustituye a dbt en proyectos serios: entiende dependencias column-level, planifica diffs, entornos virtuales aislados, CI nativo. Reducción 40 % tiempo despliegue modelos vs dbt puro.
    2. Apache Iceberg (Polaris/Unity Catalog) — Formato de tabla abierto estándar. Permite leer/escribir desde Spark, Flink, Trino, DuckDB, Snowflake, BigQuery sin duplicar datos.
    3. LangGraph / CrewAI / AutoGen — Orquestación de agentes con estado, human-in-the-loop, tool-use (MCP). En BAOSS usamos LangGraph para pipelines deterministas (calidad, PII) y CrewAI para exploración analítica (insights, text-to-SQL).
    4. MCP (Model Context Protocol) — Estándar emergente (Anthropic, 2024) para exponer herramientas (SQL, API, filesystem) a LLMs. Nuestro Semantic Layer MCP Server permite a cualquier agente (Cursor, Claude Desktop, custom) consultar métricas gobernadas sin alucinar tablas.
    5. vLLM / Ollama / SGLang — Serving local de LLM (Llama 3.1 70B, Nemotron 3 Ultra, Qwen 2.5) para PII detection, clasificación, enriquecimiento. Coste 0 €/token vs API cloud; latencia < 200 ms/batch 1k rows.
    6. Cube Cloud / dbt Semantic Layer — Capa métrica única para BI, Notebooks, Agentes. Evita «métrica distinta por dashboard».
    7. OpenLineage + DataHub — Lineage automático cross-platform (Airbyte → Iceberg → SQLMesh → Cube → Agent). Auditoría lista para AI