Databricks Lakehouse: cuando el data lake por fin se une al warehouse

Durante una década, toda plataforma de datos seria funcionó con dos sistemas. Un data lake donde volcar todo en almacenamiento de objetos barato, y un data warehouse que servía las tablas limpias y modeladas que el negocio realmente consultaba. Dos copias de los datos, dos conjuntos de pipelines, dos facturas y una discusión permanente sobre cuál contenía la verdad.

El lakehouse es el intento de colapsar esa división en una sola. Databricks no inventó ni el almacenamiento ni el formato de fichero, pero empaquetó el patrón en algo que un equipo puede operar en producción. Tras varios de estos proyectos, esto es lo que es real y lo que es marketing.

Dos mundos, y por qué los equipos usaban ambos

Un data lake es almacenamiento de objetos —Azure Data Lake Storage Gen2, S3, GCS— con ficheros en bruto en cualquier formato. Es barato, escala hasta el infinito y es schema-on-read: decides la estructura al consultar, no al escribir. El precio es que un lake sin disciplina se convierte en un pantano. Sin transacciones, sin validación de esquema, sin forma sencilla de actualizar una sola fila.

Un warehouse es lo contrario. Tablas estructuradas, garantías ACID, SQL rápido, gobierno real. El precio es la rigidez y el coste: pagas por cargar los datos, pagas por almacenamiento propietario, y las cargas de machine learning que quieren ficheros en bruto no encajan en el modelo.

Usar ambos significa copiar datos entre ellos y reconciliar las copias eternamente. La pregunta del lakehouse es simple: ¿y si el lake pudiera comportarse como un warehouse sin una segunda copia?

Qué es realmente un lakehouse

El truco es un formato de tabla abierto por encima de los ficheros en el almacenamiento de objetos. En Databricks eso es Delta Lake: ficheros de datos Parquet más un log de transacciones. Ese log lo es todo. Te da:

• Transacciones ACID — las escrituras concurrentes ya no corrompen una tabla.
• Validación y evolución de esquema — los datos malos se rechazan, los cambios buenos se versionan.
• Time travel — consulta la tabla tal como estaba el martes pasado, o revierte una carga defectuosa.
• Upserts y borrados — MERGE funciona, lo cual importa para el borrado del RGPD y el change-data-capture.

Como los datos permanecen en Parquet abierto en tu propia cuenta de almacenamiento, una única copia lo sirve todo: cuadros de mando SQL, jobs de streaming y entrenamiento de ML leen las mismas tablas. Sin lock-in sobre los bytes, sin paso de exportación. Ese es el premio.

La arquitectura medallion

El lakehouse te da las primitivas; la arquitectura medallion es cómo las mantienes ordenadas. Los datos fluyen por tres niveles de calidad:

1. Bronce — ingesta en bruto, exactamente como llegó. Solo-append, auditable, jamás editado.
2. Plata — limpio, desduplicado, conformado. Unido y tipado, pero aún granular.
3. Oro — agregados a nivel de negocio y esquemas en estrella que consumen cuadros de mando e informes.

La disciplina importa más que la herramienta. El bronce es tu póliza de seguro: si una transformación de plata está mal, reprocesas desde bronce en lugar de volver a ingerir desde el origen. Sáltatelo y pierdes la capacidad de arreglar el histórico.

Unity Catalog: el gobierno que no puedes añadir después

Unity Catalog es la pieza que la mayoría subestima. Es una capa de gobierno única sobre todos los workspaces: control de acceso granular, enmascarado de columnas y filas y —lo que te salva en una auditoría— linaje automático. Puedes ver qué informe depende de qué tabla de oro, que depende de qué job de plata, hasta el fichero en bruto.

El gobierno no es algo que se retroadapta cuando ya tienes quinientas tablas y nadie sabe quién puede leer qué. Actívalo en la tabla uno. El coste de migrarlo después es brutal.

Rendimiento: Photon y el SQL warehouse

La vieja objeción a los lakes era la velocidad: consultar ficheros no podía competir con un warehouse afinado. Dos cosas cerraron la brecha. Photon es un motor de consultas vectorizado escrito en C++ que acelera cargas SQL y DataFrame sin cambiar tu código. Y los SQL warehouses de Databricks dan a los analistas un endpoint familiar: conectan una herramienta de BI y consultan tablas de oro, ajenos a que hay almacenamiento de objetos debajo.

El almacenamiento y el cómputo están separados, así que escalas los clústeres de consulta hacia arriba para un cierre de mes pesado y hacia abajo después sin tocar los datos. Esa elasticidad es donde la economía del cloud cae de verdad a tu favor: la misma disciplina que defiendo en plataformas de IA tranquilas.

Cuándo el lakehouse es la respuesta equivocada

No es una mejora universal. Sé honesto sobre la escala:

• Datos pequeños y puramente relacionales. Si todo cabe cómodo en Postgres y solo sirves BI, un warehouse gestionado es más simple y barato. Un lakehouse es maquinaria que no necesitas.
• Sin capacidad de ingeniería. Delta, los clústeres y el flujo medallion son superficie operativa real. Un equipo minúsculo se ahoga.
• Esquemas en estrella puros y estables, sin ML ni streaming. El lakehouse brilla cuando las cargas son mixtas. Si las tuyas nunca lo serán, la flexibilidad es peso muerto.

---

El lakehouse se gana su sitio cuando de verdad tienes ambos mundos —datos en bruto y en streaming alimentando ML y tablas limpias alimentando al negocio— y estás cansado de pagar dos veces por mantenerlos sincronizados. Empieza con Delta y los niveles medallion, activa Unity Catalog de inmediato y deja que Photon se preocupe de la velocidad. Lo siguiente en esta serie: cómo Microsoft juega la misma partida con Fabric, OneLake y Copilot Studio.