ETL vs ELT en 2026: Guía Completa de Arquitectura de Pipelines de Datos

La arquitectura de pipelines de datos representa uno de los pilares fundamentales del data engineering moderno, y la decisión entre ETL vs ELT define cómo las organizaciones procesan, transforman y almacenan su información crítica. En 2026, con el auge de los data warehouses en la nube y herramientas como dbt, esta elección arquitectónica tiene implicaciones directas en costos, escalabilidad y velocidad de desarrollo.

Fundamentos de la arquitectura ETL tradicional

El patrón Extract-Transform-Load surgió en una era donde el almacenamiento era costoso y el poder de cómputo de los data warehouses era limitado. La lógica detrás de ETL era simple: transformar los datos en servidores intermedios antes de cargarlos al warehouse, reduciendo así el volumen de datos almacenados y evitando sobrecargar sistemas con capacidad limitada.

En un pipeline ETL clásico, los datos pasan por tres etapas secuenciales bien definidas. Primero, la extracción conecta con sistemas fuente como bases de datos transaccionales, APIs o archivos. Luego, la transformación aplica reglas de negocio, limpieza y agregaciones en un servidor de procesamiento dedicado. Finalmente, la carga escribe los datos ya transformados en el warehouse de destino.

# etl_pipeline.py
import pandas as pd
from sqlalchemy import create_engine

def extract(source_url: str) -> pd.DataFrame:
    """Extract raw data from source system."""
    return pd.read_csv(source_url)

def transform(df: pd.DataFrame) -> pd.DataFrame:
    """Clean and reshape data before loading."""
    # Remove rows with missing revenue
    df = df.dropna(subset=["revenue"])
    # Normalize currency to USD
    df["revenue_usd"] = df.apply(
        lambda row: row["revenue"] * get_exchange_rate(row["currency"]),
        axis=1
    )
    # Aggregate to daily granularity
    return df.groupby("date").agg({"revenue_usd": "sum"}).reset_index()

def load(df: pd.DataFrame, engine) -> None:
    """Write transformed data to the warehouse."""
    df.to_sql("daily_revenue", engine, if_exists="append", index=False)

# Pipeline execution: Extract -> Transform -> Load
engine = create_engine("postgresql://warehouse:5432/analytics")
raw = extract("s3://data-lake/sales/2026-04-13.csv")
cleaned = transform(raw)
load(cleaned, engine)

Este enfoque presenta ventajas claras en ciertos escenarios. Los datos llegan al warehouse ya limpios y estructurados, reduciendo el espacio de almacenamiento necesario. Además, la transformación ocurre en servidores que pueden escalar independientemente del warehouse, evitando competir por recursos con las consultas analíticas.

Sin embargo, ETL tradicional introduce complejidad operacional significativa. Cada cambio en las reglas de negocio requiere modificar código de transformación, re-ejecutar pipelines históricos y coordinar despliegues entre múltiples sistemas.

La revolución ELT y el poder del warehouse moderno

El paradigma ELT invierte el orden de las operaciones, aprovechando la capacidad de cómputo masivamente paralelo de los data warehouses en la nube como Snowflake, BigQuery y Databricks. En lugar de transformar datos en servidores intermedios, ELT carga los datos crudos directamente al warehouse y ejecuta las transformaciones usando SQL.

Esta arquitectura ganó tracción con el surgimiento de herramientas como dbt (data build tool), que permite definir transformaciones como modelos SQL versionados, testeables y documentados. Los data engineers escriben la lógica de negocio en SQL, y dbt se encarga de orquestar las dependencias y materializar los resultados.

-- models/daily_revenue.sql (dbt model)
-- Transforms raw sales data inside the warehouse

WITH raw_sales AS (
    SELECT
        sale_date,
        revenue,
        currency,
        exchange_rate
    FROM {{ source('raw', 'sales_events') }}
    WHERE revenue IS NOT NULL
),

normalized AS (
    SELECT
        sale_date,
        revenue * exchange_rate AS revenue_usd
    FROM raw_sales
)

SELECT
    sale_date,
    SUM(revenue_usd) AS total_revenue_usd,
    COUNT(*) AS transaction_count
FROM normalized
GROUP BY sale_date

La configuración de un proyecto dbt sigue convenciones que facilitan la organización del código y la gestión de ambientes. Los modelos se estructuran en capas que van desde staging (mapeos directos de las fuentes) hasta marts (tablas finales para consumo de BI).

# dbt_project.yml - Modern ELT project configuration
name: analytics_pipeline
version: "1.0.0"

models:
  analytics_pipeline:
    staging:             # 1:1 mappings from raw sources
      +materialized: view
      +schema: staging
    intermediate:        # Business logic, joins, calculations
      +materialized: ephemeral
    marts:               # Final tables consumed by BI tools
      +materialized: table
      +schema: analytics

Las ventajas de ELT se manifiestan especialmente en agilidad y flexibilidad. Los datos crudos permanecen disponibles, permitiendo crear nuevas transformaciones sin necesidad de re-extraer de los sistemas fuente. Los analistas pueden explorar datos históricos y los data engineers pueden iterar rápidamente sobre modelos de transformación.

Comparativa arquitectónica: dimensiones clave

La selección entre ETL y ELT depende de múltiples factores que varían según el contexto organizacional, los requisitos de compliance y la infraestructura existente.

| Dimensión | ETL | ELT | |-----------|-----|-----| | Ubicación de transformación | Servidor intermedio (Spark, Python) | Dentro del warehouse (SQL) | | Almacenamiento de datos crudos | No se persisten | Se conservan en capa raw | | Flexibilidad ante cambios | Requiere re-extracción | Reprocesa desde datos crudos | | Habilidades requeridas | Python, Scala, ingeniería de datos | SQL, modelado dimensional | | Compliance PII | Transformación antes de almacenar | Requiere controles adicionales | | Latencia típica | Minutos a horas | Segundos a minutos | | Escalabilidad | Limitada por infraestructura propia | Elástica en la nube |

El factor compliance merece atención especial. En pipelines ETL, la información sensible puede transformarse o eliminarse antes de llegar al warehouse, simplificando el cumplimiento de regulaciones como GDPR. En arquitecturas ELT puras, los datos crudos con PII residen en el warehouse, requiriendo políticas de acceso granulares y potencialmente encriptación a nivel de columna.

Análisis de costos: infraestructura tradicional versus nube

El modelo de costos difiere sustancialmente entre ambas arquitecturas. ETL tradicional requiere infraestructura dedicada para el procesamiento de transformaciones, mientras que ELT traslada ese cómputo al warehouse donde se paga por uso.

| Componente | ETL (EC2 + RDS) | ELT (Fivetran + Snowflake + dbt) | |------------|-----------------|----------------------------------| | Extracción | Scripts propios en EC2 | Fivetran (conectores managed) | | Cómputo de transformación | Cluster Spark o servidores dedicados | Créditos de warehouse | | Almacenamiento | RDS + S3 | Storage de Snowflake | | Orquestación | Airflow self-hosted | dbt Cloud o Airflow managed | | Costo mensual estimado (10TB) | $3,000 - $8,000 USD | $2,500 - $6,000 USD | | Escalabilidad | Vertical, planificada | Horizontal, automática | | Mantenimiento | Equipo DevOps requerido | Mínimo, servicios managed |

Los costos de ELT pueden escalar rápidamente si las consultas no se optimizan. Warehouses como Snowflake cobran por tiempo de cómputo, y transformaciones ineficientes o materializaciones excesivas pueden generar facturas inesperadas. Sin embargo, la reducción en overhead operacional y la velocidad de desarrollo generalmente compensan estos riesgos cuando se implementan buenas prácticas.

El patrón híbrido ETLT: lo mejor de ambos mundos

En la práctica, muchas organizaciones adoptan un enfoque híbrido denominado ETLT (Extract, Transform, Load, Transform). Este patrón aplica transformaciones ligeras durante la extracción, principalmente para compliance y reducción de volumen, mientras que las transformaciones de lógica de negocio ocurren dentro del warehouse.

# hybrid_pipeline.py
# Light ETL at extraction + heavy ELT in warehouse

def extract_and_mask(source: str) -> pd.DataFrame:
    """Extract with minimal transformation: PII masking only."""
    df = pd.read_json(source)
    # Mask email addresses before loading
    df["email"] = df["email"].apply(lambda e: hash_pii(e))
    # Remove raw IP addresses
    df.drop(columns=["ip_address"], inplace=True)
    return df

def load_raw(df: pd.DataFrame, warehouse) -> None:
    """Load masked but otherwise raw data to warehouse."""
    df.to_sql("raw_user_events", warehouse, if_exists="append", index=False)

# Heavy transformations happen in dbt inside the warehouse
# See: models/marts/user_engagement.sql

Calidad de datos y testing en pipelines modernos

Independientemente del patrón elegido, la calidad de datos requiere validaciones sistemáticas. En arquitecturas ELT con dbt, los tests se definen declarativamente junto a los modelos, ejecutándose automáticamente en cada pipeline run.

# models/staging/stg_orders.yml
version: 2

models:
  - name: stg_orders
    description: "Cleaned orders from raw source"
    columns:
      - name: order_id
        tests:
          - unique           # No duplicate orders
          - not_null         # Every row has an ID
      - name: order_total
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0   # No negative totals
              max_value: 100000
      - name: customer_id
        tests:
          - not_null
          - relationships:   # Foreign key integrity
              to: ref('stg_customers')
              field: customer_id

Los tests de integridad referencial, unicidad y rangos válidos detectan problemas antes de que los datos incorrectos lleguen a dashboards y modelos de machine learning. En pipelines ETL tradicionales, estas validaciones requieren código adicional y orquestación explícita, mientras que dbt las integra como ciudadanos de primera clase.

Criterios de decisión para arquitecturas de datos

La selección entre ETL, ELT o un enfoque híbrido debe considerar el contexto específico de cada organización. Los siguientes criterios guían esta decisión:

Elegir ETL cuando:

• Los requisitos de compliance exigen que datos sensibles nunca lleguen al warehouse
• La infraestructura on-premise existente tiene capacidad disponible
• El volumen de datos es estable y predecible
• El equipo tiene experiencia en Spark, Python o herramientas de integración tradicionales

Elegir ELT cuando:

• La organización utiliza un data warehouse en la nube como plataforma central
• Se requiere flexibilidad para crear nuevas transformaciones sobre datos históricos
• El equipo de datos tiene fortalezas en SQL y modelado dimensional
• La velocidad de iteración es prioritaria sobre el control granular

Elegir ETLT cuando:

• Existen requisitos regulatorios que demandan transformación previa de PII
• Se desea mantener la flexibilidad de ELT con controles de compliance
• El volumen de datos crudos excede lo razonable para almacenar completo

Conclusión y recomendaciones prácticas

La arquitectura de pipelines de datos en 2026 favorece claramente los enfoques ELT y ETLT para la mayoría de los casos de uso, impulsados por el costo decreciente del almacenamiento en la nube y el poder de cómputo de los warehouses modernos.

• ETL tradicional mantiene relevancia en escenarios de compliance estricto y cuando existe infraestructura legacy que procesar
• ELT puro maximiza la agilidad y aprovecha el poder de herramientas como dbt para transformaciones declarativas y testeables
• ETLT híbrido ofrece el balance óptimo para organizaciones que requieren compliance sin sacrificar flexibilidad
• La calidad de datos debe ser una prioridad independientemente del patrón, con tests automatizados integrados en el pipeline
• Los costos de warehouse requieren monitoreo activo en arquitecturas ELT para evitar sorpresas en la facturación

La tendencia hacia ELT continuará acelerándose a medida que los warehouses incorporen capacidades de procesamiento más avanzadas y las herramientas de transformación maduren. Sin embargo, el conocimiento de ETL tradicional sigue siendo valioso para integrar sistemas legacy y manejar casos edge donde la transformación previa es obligatoria.