Qué es un data lakehouse y cómo funciona

Un data lakehouse es una arquitectura que busca combinar la flexibilidad y escala de un data lake con capacidades de gestión propias de un data warehouse, como tablas, transacciones, esquema, SQL y gobierno.

No es simplemente un lago con otro nombre. Su valor depende de una capa de tablas confiable, metadatos, control de concurrencia, rendimiento y procesos que convierten archivos crudos en productos consumibles.

Problema que intenta resolver

Un lake almacena grandes volúmenes de datos estructurados y no estructurados a bajo costo, pero los archivos por sí solos dificultan actualizaciones, consistencia y consultas BI. Un warehouse ofrece tablas gobernadas y rendimiento SQL, aunque puede requerir copiar datos y limitar formatos.

El lakehouse intenta mantener datos en almacenamiento abierto o desacoplado y añadir funciones de base analítica sobre ellos.

Componentes

Fuentes
  → almacenamiento de objetos
  → formato de tabla con transacciones
  → catálogo y gobierno
  → motores SQL/Spark/ML
  → BI, ciencia de datos y aplicaciones

Las implementaciones varían. Evalúa capacidades reales, no solo la etiqueta comercial.

Tablas y ACID

Una capa de tabla registra qué archivos forman una versión, permite cambios de esquema y coordina escrituras. Las propiedades ACID reducen lecturas parciales y facilitan operaciones como merge, update o delete según la tecnología.

ACID en tablas no vuelve atómico todo el pipeline. Una carga entre varios sistemas sigue necesitando diseño de publicación, checkpoints y reconciliación.

Arquitectura medallion

Un patrón frecuente organiza:

• Bronze: datos crudos o casi crudos.
• Silver: datos validados, normalizados y deduplicados.
• Gold: modelos de negocio y agregados.

Las capas son responsabilidades, no carpetas decorativas. Cada una debe definir entradas, reglas, retención, calidad y consumidores. No todas las organizaciones necesitan exactamente tres.

Lakehouse vs data lake

Aspecto	Data lake	Lakehouse
Archivos diversos	Sí	Sí
Tablas transaccionales	Limitadas por diseño	Parte central
SQL para BI	Depende de motores	Integración prevista
Gobierno	Debe añadirse	Componente esperado
Actualizaciones	Complejas en archivos	Gestionadas por tabla

Lakehouse vs data warehouse

El warehouse sigue siendo excelente para datos estructurados, cargas empresariales y rendimiento SQL predecible. El lakehouse es atractivo cuando conviven ingeniería, ciencia de datos, archivos y análisis sobre una plataforma común.

La comparación de data lake vs data warehouse ayuda a ubicar los extremos. Una arquitectura puede usar ambos sin duplicar cada dato.

Rendimiento

Guardar Parquet no garantiza consultas rápidas. Considera:

• tamaño de archivos;
• particionamiento;
• compactación;
• estadísticas;
• clustering u orden;
• pruning;
• caché;
• concurrencia;
• motor utilizado.

Demasiados archivos pequeños aumentan metadatos y planificación. Particionar por una columna de alta cardinalidad puede crear miles de directorios. Mide con consultas representativas.

Gobierno y catálogo

Necesitas:

• nombres y propietarios;
• permisos sobre archivos y tablas;
• clasificación sensible;
• linaje;
• retención;
• contratos de esquema;
• calidad y frescura;
• auditoría.

Una única capa física no crea una única definición de cliente. El gobierno semántico sigue siendo trabajo organizativo.

Casos de uso

• BI y ciencia de datos sobre conjuntos compartidos.
• Ingestión de eventos y archivos.
• Historial a gran escala.
• Features y entrenamiento.
• Datos semi-estructurados.
• Exploración con promoción hacia capas gobernadas.

Cuándo no es la primera opción

• Dataset pequeño y puramente relacional.
• Equipo sin capacidad de operar archivos y metadatos.
• Requisito transaccional operativo de baja latencia.
• Plataforma añadida solo por tendencia.
• Ausencia de propietarios y gobierno.

Migración

1. Selecciona un caso medible.
2. Define formatos y catálogo.
3. Crea una ruta de ingestión.
4. Establece controles Bronze-Silver-Gold.
5. Prueba concurrencia y recuperación.
6. Valida BI y ML.
7. Compara costo total.
8. Retira copias antiguas cuando sea seguro.

El proceso ETL o ELT debe diseñarse según dónde convenga transformar.

Errores frecuentes

• Llamar lakehouse a un conjunto de archivos sin catálogo.
• Copiar todo sin casos de uso.
• Ignorar archivos pequeños.
• Sobreparticionar.
• Conceder acceso directo al almacenamiento sin gobierno.
• Mezclar capas sin contratos.
• Prometer un único motor para cualquier carga.
• No probar recuperación y concurrencia.

El éxito se mide por tiempo de entrega, confiabilidad, costo y reutilización, no por la cantidad de terabytes trasladados.

Preguntas frecuentes

¿Qué es un data lakehouse?
Es una arquitectura que combina almacenamiento flexible de lake con tablas, transacciones, esquema y consumo analítico.

¿Reemplaza al data warehouse?
No siempre. Ambos pueden coexistir; la elección depende de cargas, gobierno, rendimiento, equipo y costo.

¿Qué es la arquitectura medallion?
Un patrón de capas Bronze, Silver y Gold para separar datos crudos, validados y orientados al negocio.

¿Un lakehouse admite SQL?
Las plataformas lakehouse suelen ofrecer motores o endpoints SQL sobre tablas, con capacidades que varían.

¿Qué formatos utiliza?
Frecuentemente almacenamiento columnar y formatos de tabla abiertos o administrados, pero la implementación concreta depende de la plataforma.

¿Cuál es el principal riesgo?
Crear otro lago desordenado si no existen catálogo, calidad, propietarios, seguridad y operación de metadatos.