Evolve · Decision Science

Arquitectura · 11 min lectura

Data Lakehouse vs Data Warehouse: cuál elegir y por qué Apache Iceberg cambió el juego

Un data warehouse optimiza consulta estructurada sobre datos curados, con un motor (BigQuery, Snowflake, Redshift) que también es dueño del storage. Un data lakehouse separa storage de cómputo: los datos viven en object storage abierto y varios motores pueden leerlos. Apache Iceberg estandariza esa capa abierta y permite, por primera vez, usar BigQuery, Snowflake o Databricks sobre el mismo dato físico sin duplicar ni migrar.

La diferencia real, sin marketing

Un warehouse tradicional es una caja cerrada: cargás datos, pagás storage y cómputo al mismo proveedor, consultás con su motor. Funciona excelente para BI; el costo es el lock-in. Un lakehouse mantiene los archivos (Parquet, ORC) en un object storage (S3, GCS, ADLS) y agrega una capa de metadata transaccional encima. Esa capa es Apache Iceberg.

Qué hace Iceberg específicamente

  • Mantiene snapshots y versiones (time travel) sobre archivos Parquet.
  • Soporta operaciones ACID: insert, update, delete, merge.
  • Evolución de esquema sin reescribir datos.
  • Particionamiento oculto que el motor optimiza sin que el usuario lo gestione.
  • Catálogo neutral leído por múltiples motores (BigLake, Snowflake, Databricks, Trino, Athena).

Por qué cambia el juego de la nube

Hasta Iceberg, elegir warehouse era elegir nube. Si llevabas tus datos a Snowflake, querer usar Vertex AI implicaba copiar todo. Con Iceberg, el dato vive una vez en GCS o S3, y cada motor lee in-place. Esto permite usar BigQuery para SQL ad-hoc, Databricks para entrenamiento de modelos, Snowflake para data sharing comercial, todo sobre el mismo storage. Sin ETL entre nubes, sin duplicación, sin lock-in.

Cuándo seguir con warehouse cerrado

Si tu volumen es chico, tu equipo es pequeño y solo consumís BI, un warehouse puro (Snowflake, BigQuery solo) es más simple y suficiente. La complejidad del lakehouse se justifica cuando hay datos a escala TB-PB, múltiples consumidores (BI, ML, IA generativa, productos), y voluntad estratégica de mantenerse vendor-neutral.

Open Data Foundation: el patrón Evolve

Evolve estandarizó el patrón en lo que llama Open Data Foundation: ingesta enterprise (Fivetran CDC) sobre Iceberg en object storage, con motores intercambiables por caso de uso. Es la base sobre la que construimos las arquitecturas de datos en Caja Los Andes y otros clientes, y la que habilita ejecutar agentes de IA sobre datos transaccionales reales con latencia operacional.

El criterio de decisión

Si el costo de migrar entre nubes te asusta, si querés probar Databricks sin abandonar BigQuery, si el board exige IA generativa sobre los mismos datos que alimentan el BI: vas a lakehouse con Iceberg. Si todo lo que querés es un dashboard sobre tu CRM, vas a warehouse puro y dormís tranquilo. No hay respuesta única; hay criterio.