Los datos ya entran (módulo 3); ahora, la casa. La etapa 3 del mapa tiene tres arquitecturas con nombre — lake, warehouse, lakehouse — y una historia que las explica mejor que cualquier definición: es la historia de cómo la industria aprendió a tener flexibilidad y garantías a la vez. Este módulo la cuenta en el orden correcto: primero el formato (que es donde vive la economía), después las casas.

La tesis del módulo

La revolución silenciosa fue el formato: los archivos columnar como Parquet hicieron que consultar terabytes en almacenamiento de objetos costara centavos, y los formatos de tabla abiertos (Iceberg, Delta) le sumaron lo que faltaba — transacciones, esquema y viaje en el tiempo — pariendo el lakehouse: la flexibilidad del lake con las garantías del warehouse, sobre el mismo storage barato. La decisión moderna rara vez es “¿lake o warehouse?”; es cuánta garantía necesita cada capa del medallón.

El formato primero: por qué columnar cambia todo

Un CSV o JSON guarda filas: para calcular el promedio de una columna, lees el archivo entero. Parquet guarda columnas: los valores de cada campo juntos, comprimidos por su naturaleza (fechas con fechas, montos con montos), con estadísticas por bloque (mín/máx) que permiten saltarse lo irrelevante. Las consecuencias, medibles en cualquier factura:

Propiedad	Fila (CSV/JSON)	Columnar (Parquet)
Leer 3 columnas de 50	Lees todo	Lees 3/50 del archivo
Compresión	Genérica, pobre	Por tipo: 5-10× mejor es normal
Filtro por rango (fechas)	Escanear todo	Saltar bloques por estadísticas
Costo de consulta analítica	Alto	Fracción — este es el punto

A esto se suma Arrow (el formato columnar en memoria que las herramientas usan para intercambiar datos sin re-serializar — el idioma común entre pandas, Spark, DuckDB y compañía) y la partición (organizar los archivos por carpetas de fecha/categoría — fecha=2026-09-06/ — para que las consultas toquen solo sus particiones). Regla de casa: la capa bronce puede ser el crudo tal cual llegó; de plata en adelante, todo es Parquet particionado.

Las tres casas

Data warehouse: la base analítica administrada (BigQuery, Snowflake, Redshift) — SQL sobre tablas con esquema, transacciones, permisos finos y rendimiento excelente. Su límite histórico: costo por almacenar todo, y rigidez para lo no tabular (los PDFs, audios y correos crudos que la IA consume no caben en una tabla).
Data lake: archivos en almacenamiento de objetos (S3/GCS/Blob — la serie cloud ya presentó las casas) — barato, ilimitado, cualquier formato. Su pecado histórico: sin transacciones ni esquema, el lake degeneraba en pantano (data swamp): archivos que nadie entiende, escrituras a medias que corrompen lecturas, cero garantías.
Lakehouse: el lake con un formato de tabla abierto encima — la síntesis que domina la década.

Iceberg y Delta: la capa que civilizó el lake

Un formato de tabla (table format) — Apache Iceberg y Delta Lake son los dos grandes (Apache Hudi es el tercero) — es una capa de metadatos sobre los archivos Parquet que convierte “una carpeta de archivos” en “una tabla de verdad”:

Transacciones ACID: la escritura se ve completa o no se ve — se acabaron las lecturas de cargas a medias.
Evolución de esquema: agregar o renombrar columnas sin reescribir terabytes.
Time travel: consultar la tabla como era en una fecha o versión — el regalo para IA: “el dataset exacto con el que entrenamos en julio” es una consulta, no una arqueología (la reproducibilidad que MLOps exige, resuelta en la capa de datos).
Motor-agnóstico: la misma tabla Iceberg la leen Spark, Trino, DuckDB y los warehouses modernos — el dato deja de estar casado con un motor.

El resultado práctico: el lakehouse es archivos baratos con modales de warehouse — y por eso la arquitectura por defecto para plataformas de IA, donde conviven el terabyte de correos crudos, las tablas curadas del negocio y los datasets versionados de entrenamiento.

   EL LAKEHOUSE CON SUS CAPAS MEDALLÓN

  almacenamiento de objetos (S3/GCS/Blob)
  ┌───────────────────────────────────────────┐
  │ BRONCE: crudo intacto (módulo 2)          │
  │  correos.json · pdfs/ · dumps/            │
  ├───────────────────────────────────────────┤
  │ PLATA: limpio y conformado                │
  │  tablas Iceberg/Delta en Parquet          │
  │  correos · clientes · cotizaciones        │
  ├───────────────────────────────────────────┤
  │ ORO: listo para consumir                  │
  │  metricas_triaje · dataset_entrenamiento  │
  │  · corpus_rag (módulos 8-10)              │
  └───────────────────────────────────────────┘
        ▲ transacciones · esquema · time travel
        └── el formato de tabla civiliza el lake

¿Y el warehouse clásico? Sigue siendo excelente — y convive: muchas plataformas sirven la capa oro también desde BigQuery/Snowflake para el BI (la fortaleza del warehouse), mientras el lakehouse guarda la historia completa y alimenta la IA. La frontera se difumina además porque los warehouses modernos ya leen Iceberg — la decisión se volvió menos religiosa y más de costos y equipo.

Ojo — el pantano no murió, solo se disfraza: el formato de tabla da garantías técnicas, no criterio. Un lakehouse sin dueños por tabla, sin la calidad del módulo 7 ni el catálogo del módulo 12 es un pantano con transacciones ACID. La arquitectura habilita el orden; el orden sigue siendo trabajo.

Errores comunes

CSV/JSON en las capas curadas. Pagar cada consulta 10× por no convertir a Parquet en plata es el impuesto silencioso más común de la analítica. Bronce como llegó; de ahí en adelante, columnar.
Sin particionar (o particionar de más). Sin partición, cada consulta escanea la historia entera; con partición por milisegundo, millones de archivos diminutos matan el rendimiento igual. Partición por la dimensión de filtro real — casi siempre fecha — con archivos de tamaño sano.
El lake sin formato de tabla. Carpetas de Parquet sin formato de tabla encima, en 2026, es renunciar gratis a transacciones, esquema y time travel. Iceberg o Delta desde plata; la elección entre ambos pesa menos que la decisión de usar uno.
Todo al warehouse por inercia. Los crudos no tabulares de IA (documentos, audio, correos) y los terabytes de historia fría no son su territorio; la factura lo recordará. Lakehouse para la historia y la IA; warehouse donde su fortaleza (BI, permisos finos) pague.
Ignorar el time travel para reproducibilidad. Entrenar sin poder reconstruir el dataset exacto es el pecado que mlops-02 documenta; con Iceberg/Delta la solución viene incluida — úsala: cada entrenamiento registra la versión de sus tablas.
Medallón como burocracia. Tres capas no son tres aduanas: son la separación entre lo irrecuperable (bronce), lo confiable (plata) y lo consumible (oro). Saltarse plata “por rapidez” mezcla limpieza con lógica de negocio y vuelve todo indepurable.

La frase para llevarse

“Primero el formato, después la casa: Parquet particionado hace barata la pregunta, Iceberg o Delta la hacen confiable — transacciones, esquema y viaje en el tiempo sobre archivos de centavos. El lakehouse es eso: un lake con modales de warehouse, y el pantano solo se evita con dueños y calidad, no con siglas.”

Qué viene

Módulo 5: transformación — ELT y dbt. Los datos viven ordenados; falta convertir crudo en útil con disciplina de ingeniería: por qué el mundo pasó de ETL a ELT (transformar dentro del almacén, con su motor), y cómo dbt convirtió el SQL de transformación en software de verdad — con dependencias, tests, documentación y el linaje que el módulo 12 cosechará.

Data Engineering — Módulo 4: lake, warehouse y lakehouse