Data lakes vs. data lakehouses: cuál usar y cuándo

Cualquier empresa que pasa de manejar unos cuantos gigabytes en un ERP a ingerir logs de aplicación, eventos de clickstream, exports de CRM y archivos de terceros se topa tarde o temprano con el mismo muro: el data warehouse tradicional no fue diseñado para esto. Está optimizado para datos estructurados y modelados de antemano, y cada nueva fuente exige un ciclo completo de diseño de esquema antes de poder cargar un solo registro. Cuando el volumen crece rápido y los formatos varían (JSON, Parquet, CSV, imágenes, texto libre), ese ciclo se convierte en el cuello de botella que frena a todo el equipo de datos. El problema real no es "dónde guardamos los datos", sino cómo evitamos que guardarlos todo se convierta en un desorden inservible más adelante. Ahí es donde entran en juego los data lakes y, más recientemente, los data lakehouses.

Qué es un data lake

Un data lake es un repositorio centralizado que almacena datos en su formato original, sin exigir que se estructuren o modelen antes de la ingesta. La idea central es simple: guarda primero, decide el uso después. Esto se logra apoyándose en almacenamiento de objetos barato y elástico (blob storage o sistemas de ficheros distribuidos), donde cualquier tipo de dato —estructurado, semiestructurado o no estructurado— convive en el mismo repositorio.

El objetivo de un lake no es servir un reporte concreto, sino poner a disposición de la organización el universo completo de datos disponibles, para que distintos equipos (analistas, científicos de datos, ingenieros de ML) puedan explorarlos y explotarlos según su propia necesidad, sin depender de que TI diseñe una tabla para cada caso de uso. Por eso suele organizarse en zonas con distinto nivel de curación: una zona cruda con los datos tal cual llegan, una zona limpia/estandarizada, y una zona curada lista para consumo, cada una con distintos niveles de acceso y gobernanza.

Dónde se rompe la promesa del lake

El almacenamiento de objetos que sostiene a un data lake fue diseñado para escribir y leer archivos grandes de forma eficiente, no para operar como una base de datos. Esa diferencia de diseño genera tres problemas concretos que aparecen apenas el lake empieza a usarse en serio:

• No hay transacciones. Sin garantías tipo ACID, dos procesos que escriben y leen la misma carpeta al mismo tiempo pueden pisarse entre sí. Combinar procesamiento batch con streaming sobre los mismos datos es, en la práctica, casi imposible de hacer con seguridad.
• El esquema no se controla. Como no hay una capa que valide qué estructura tienen los datos, nada impide que un cambio en el origen (una columna que desaparece, un tipo que cambia) rompa silenciosamente los procesos aguas abajo.
• Las operaciones básicas de una base de datos son costosas. Borrar un registro puntual, aplicar un upsert o hacer un merge implica reescribir archivos completos, porque el almacenamiento de objetos no soporta modificaciones parciales.

El resultado, cuando estos problemas no se gestionan, tiene nombre propio en la jerga de datos: data swamp, un lake sin gobernanza donde nadie confía en lo que hay adentro. La consecuencia práctica es que muchas empresas terminaron manteniendo el lake para datos crudos y un warehouse aparte para todo lo que necesitaba confiabilidad, duplicando pipelines, costos y latencia entre ambos sistemas.

Qué añade un lakehouse

Un lakehouse no es una tecnología nueva de almacenamiento, es una capa de gestión transaccional que se coloca encima del mismo almacenamiento de objetos barato de un lake. Formatos de tabla abiertos como Delta Lake, Apache Iceberg o Apache Hudi mantienen un registro de metadatos que indica exactamente qué archivos componen cada versión de una tabla, y es esa capa la que habilita todo lo demás:

• Transacciones ACID sobre el propio almacenamiento de objetos, de modo que múltiples pipelines pueden leer y escribir de forma concurrente sin corromper los datos.
• Forzado y evolución de esquema, para que un cambio inesperado en el origen no rompa las tablas silenciosamente, y para que ese cambio pueda incorporarse de forma controlada.
• Batch y streaming unificados sobre el mismo conjunto de tablas, sin necesidad de mantener dos copias de los datos ni dos arquitecturas separadas.
• Consultas SQL y BI directamente sobre el lake, eliminando la necesidad de mover datos a un warehouse aparte solo para que un analista pueda consultarlos con baja latencia.

Un lakehouse no reemplaza al data lake: le agrega la disciplina transaccional que un warehouse siempre tuvo, sin renunciar a la flexibilidad y el costo de un almacenamiento de objetos abierto.

La organización en capas: de crudo a confiable

La forma más común de organizar un lakehouse hoy es la llamada arquitectura medallion, que no es más que una convención de nombres para ir mejorando progresivamente la calidad de los datos a medida que avanzan por el pipeline:

• Bronze (raw): los datos aterrizan tal cual llegan del origen, sin transformar. El objetivo en esta capa es que la ingesta nunca falle: si algo llega con un formato inesperado, se guarda igual y se recupera después, en vez de detener todo el pipeline.
• Silver (cleaned/conformed): se aplican deduplicación, control de nulos, resolución de datos que llegan tarde o desordenados y validación de calidad. En esta capa todavía no hay lógica de negocio: es una versión limpia y confiable, pero fiel al origen.
• Gold (curated): se aplica modelado dimensional (esquemas estrella o copo de nieve) y, opcionalmente, un modelo semántico para las herramientas de BI. Es la capa que consumen analistas de negocio y dashboards de producción.

Vale aclarar algo que se pierde con frecuencia: bronze/silver/gold es un patrón de diseño, no una arquitectura obligatoria ni un estándar. Cada organización ajusta el número de capas y sus reglas según su volumen, su regulación y su madurez de datos.

Cuándo usarlo en la práctica

Un data lake plano sigue siendo suficiente cuando el caso de uso no exige consistencia transaccional fuerte. En concreto, funciona bien si:

1. Los datos son mayoritariamente de solo lectura o append, sin necesidad de actualizar o borrar registros individuales (por ejemplo, archivos de logs o eventos históricos para entrenar modelos).
2. Hay un solo pipeline o un número reducido de consumidores escribiendo a la vez, sin concurrencia real que exponga la falta de transacciones.
3. El objetivo principal es exploración y análisis ad hoc de datos crudos, no servir reportes de producción con SLA de frescura o exactitud.
4. El presupuesto y el equipo son pequeños, y añadir una capa transaccional (Delta, Iceberg, Hudi) representa más complejidad operativa de la que el proyecto puede sostener por ahora.

Vale la pena invertir en un lakehouse cuando aparece cualquiera de estas señales:

1. Necesitas aplicar borrados o actualizaciones selectivas sobre datos ya almacenados —por ejemplo, para cumplir con solicitudes de eliminación de datos personales o para procesar CDC (change data capture) desde bases transaccionales.
2. Varios procesos leen y escriben las mismas tablas de forma concurrente, y ya has tenido (o anticipas) problemas de datos corruptos o inconsistentes por esa concurrencia.
3. Quieres que BI, ciencia de datos y machine learning trabajen sobre la misma copia de los datos, en vez de mantener duplicados sincronizados entre un lake y un warehouse.
4. El esquema de tus fuentes cambia con cierta frecuencia y necesitas que esos cambios se controlen y evolucionen sin romper silenciosamente los pipelines aguas abajo.

La decisión no es binaria para siempre: la mayoría de los equipos empiezan con un lake simple y adoptan las garantías de un lakehouse a medida que la concurrencia, la necesidad de actualizar datos o la exigencia de gobernanza lo justifican. Lo que hay que evitar es adoptar la complejidad transaccional antes de necesitarla, o posponerla hasta que el lake ya se volvió un swamp que nadie quiere tocar.