Etapa 4 del mapa: transformar. El crudo del bronce (módulo 4) no sirve a nadie tal cual — tipos inconsistentes, duplicados, fuentes por unir, reglas de negocio por aplicar. La pregunta de este módulo es doble: dónde transformar (la historia ETL→ELT) y cómo hacerlo sin que el resultado sea una maraña de scripts que nadie se atreve a tocar (la respuesta tiene nombre: dbt).

La tesis del módulo

ELT ganó porque el motor más potente que tienes es el del almacén: carga el crudo primero y transforma adentro, con SQL — y dbt existe porque ese SQL, sin disciplina, degenera en scripts frágiles: modelos con dependencias explícitas, tests que corren en cada build, documentación y linaje generados del propio código. La transformación es software; dbt es lo que la obliga a comportarse como tal.

De ETL a ELT: el orden de las letras importa

ETL (Extract, Transform, Load): el orden clásico — transformar antes de cargar, en un servidor intermedio. Nació cuando el almacén era caro y limitado: solo entraba lo procesado.
ELT (Extract, Load, Transform): el orden moderno — cargar el crudo primero (Load al bronce: el principio sagrado del módulo 2 ya te lo hizo elegir), transformar dentro con el motor del almacén/lakehouse.

Por qué ganó ELT: el motor analítico (BigQuery, Snowflake, Spark/Trino sobre Iceberg) es el hardware más potente del stack — transformar ahí evita mover datos dos veces y aprovecha una máquina que ya pagas; el crudo queda guardado (re-transformable cuando el bug aparezca); y la transformación se escribe en SQL, el idioma que analistas e ingenieros comparten — bajando la barrera de quién puede contribuir. ETL sobrevive donde debe: transformaciones que no pueden esperar a la carga (el enmascaramiento de PII antes de persistir — módulo 9) o fuentes que exigen procesamiento en vuelo. Regla de casa: ELT por defecto; ET(L) solo con una razón nombrable.

   ETL vs ELT — DÓNDE VIVE LA TRANSFORMACIÓN

  ETL (clásico)
  fuente ──► servidor intermedio ──► almacén
             transforma aquí        recibe solo
             (el crudo se pierde)    lo procesado

  ELT (moderno)
  fuente ──► almacén / lakehouse
             bronce: crudo intacto
                │ SQL con el motor del almacén
                ▼
             plata ──► oro

dbt: el SQL con modales de software

dbt (data build tool) es el estándar de la transformación ELT. Su idea central es humilde y transformadora: cada transformación es un modelo — un archivo .sql con un SELECT — y dbt se encarga de materializarlo como tabla o vista, en el orden correcto según sus dependencias:

-- models/staging/stg_correos.sql
-- staging: limpia y tipifica el bronce, 1 a 1 con la fuente
select
    id_correo,
    lower(trim(remitente))            as remitente,
    cast(recibido_en as timestamp)    as recibido_en,
    categoria_asignada,
    respondido_por_agente
from {{ source('bronce', 'correos_crudos') }}
where id_correo is not null

-- models/marts/metricas_triaje.sql
-- mart: la tabla oro que consume el negocio (y el módulo 8)
select
    date_trunc('day', recibido_en)    as dia,
    categoria_asignada,
    count(*)                          as correos,
    avg(case when respondido_por_agente then 1 else 0 end)
                                      as tasa_escalada
from {{ ref('stg_correos') }}
group by 1, 2

El {{ ref('stg_correos') }} es la pieza clave: declara la dependencia. De esas referencias dbt construye el DAG (el grafo dirigido de dependencias entre modelos), ejecuta en orden, reconstruye solo lo afectado — y dibuja el linaje del módulo 2 gratis: qué desciende de qué, quién se rompe si cambias esta tabla.

Lo que convierte esto en ingeniería y no en carpeta de queries:

Tests declarativos: en un YAML junto al modelo — not_null, unique, accepted_values, relaciones entre tablas — que corren en cada build y frenan el pipeline si fallan (el aperitivo del módulo 7):

# models/staging/stg_correos.yml
models:
  - name: stg_correos
    columns:
      - name: id_correo
        data_tests: [not_null, unique]   # dbt >= 1.8; antes `tests:`
      - name: categoria_asignada
        data_tests:
          - accepted_values:
              values: ['facturacion', 'soporte', 'ventas', 'otro']

Documentación y linaje generados: descripciones en el YAML + el DAG = un sitio navegable de qué es cada tabla y de dónde viene.
Git, revisión y ambientes: los modelos viven en un repo, se revisan como código, y se despliegan a dev/prod — el flujo del curso de Deploy, aplicado a SQL.
Materialización por decisión: vista (barata, siempre fresca) vs. tabla (rápida de leer) vs. incremental (procesa solo lo nuevo — la marca de agua del módulo 3, ahora dentro de la transformación, esencial cuando la historia es grande).

El patrón de capas: staging → intermediate → marts

La convención dbt que mapea el medallón: staging (un modelo por fuente: limpiar, tipificar, renombrar — plata temprana, sin lógica de negocio), intermediate (las uniones y reglas de negocio reutilizables — plata madura), marts (las tablas finales por dominio de consumo — el oro: metricas_triaje, y en los módulos 8-10, dataset_entrenamiento y corpus_rag serán marts también). La disciplina que el patrón compra: la lógica de negocio vive en un lugar (intermediate), no repetida en cada consumidor — cuando la definición de “correo escalado” cambie, cambia en un modelo y el linaje te dice a quién avisar.

Ojo — los datasets de IA son marts: la tentación es tratar el dataset de entrenamiento o el corpus del RAG como “algo aparte” que un script arma. Son marts: modelos dbt con tests, linaje y versión, construidos de las mismas capas plata que el BI. El dataset con not_null en el label, accepted_values en las categorías y linaje hasta el bronce es la mitad de la reproducibilidad que MLOps pide — conseguida con la misma herramienta del resto del pipeline.

Errores comunes

Transformar fuera del almacén por costumbre ETL. Mover datos a un servidor intermedio para hacerles SQL que el almacén haría mejor: doble movimiento, motor desaprovechado. ELT salvo razón nombrable.
SQL sin ref(). Modelos que se nombran por string mágico rompen el DAG: dbt no sabe el orden ni el linaje. Toda dependencia pasa por ref()/source() — es la regla número uno del tooling.
Modelos sin tests. El SQL que corre sin validar es el bug silencioso propagándose a oro. Mínimo vital en todo modelo: unicidad y no-nulos de la clave, valores aceptados de las categorías.
Lógica de negocio en staging (o en los marts). Staging limpia, no interpreta; los marts consumen, no definen. La regla de negocio duplicada en tres marts es la inconsistencia de reportes de la próxima reunión.
Todo materializado como tabla completa. Reconstruir la historia entera en cada corrida escala hasta que no. Incremental para los modelos grandes, con su clave y su estrategia — y el backfill del módulo 2 como comando de rutina.
El dataset de IA fuera del framework. El script suelto que arma el entrenamiento, sin tests ni linaje, es exactamente el eslabón sin disciplina en el flujo que más la necesita. Marts, como todo lo demás.

La frase para llevarse

“Carga primero, transforma adentro, y trata cada transformación como software: modelos con ref(), tests que frenan el build, linaje dibujado del propio código. Y la regla que une este curso con la IA: tus datasets de entrenamiento y tus corpus de RAG son marts — con la misma disciplina que el resto, porque son los que menos la perdonan.”

Qué viene

Módulo 6: orquestación. Los modelos saben su orden interno, pero alguien tiene que dirigir la obra completa: la ingesta a las 2:00, dbt cuando termine, la calidad después, el refresco del índice al final — con reintentos, alertas y backfills. Airflow, Dagster y Prefect: qué hace un orquestador, en qué se diferencian de verdad, y el giro de Dagster que le habla directo a la IA — orquestar assets (los datos que existen) en vez de tareas (los pasos que corren).

Data Engineering — Módulo 5: transformación — ELT y dbt