Lakehouse: unificar el data lake y el warehouse | SUMāTO

Durante una década, los equipos de datos hemos vivido con una arquitectura partida en dos: por un lado el data lake, barato y flexible, donde aterriza todo —logs, archivos, eventos, semiestructurado—; por el otro, el data warehouse, ordenado y rápido para los tableros de negocio. Funciona, pero a costa de duplicar datos, mantener dos pilas tecnológicas y mover información de un lado a otro sin parar. En SUMāTO vemos cada vez más empresas en LATAM preguntándose si de verdad necesitan los dos. La respuesta que está madurando en 2022 tiene nombre: lakehouse.

En corto: El lakehouse es una arquitectura que pone capacidades de data warehouse —transacciones, esquemas, rendimiento de consulta— directamente sobre el almacenamiento barato y abierto de un data lake. La idea es tener un solo lugar donde convivan BI y machine learning, sin copiar los datos a un sistema aparte. No es magia: es la combinación de formatos de tabla abiertos y motores que los entienden.

El problema de tener lake y warehouse por separado

La arquitectura de dos niveles se volvió el estándar de facto: ingieres todo al lake en formatos como Parquet y luego cargas un subconjunto curado al warehouse para que el negocio consulte. Sobre el papel es elegante. En la práctica genera fricciones que se acumulan.

• Duplicación y costo: los mismos datos viven en dos lugares. Usted paga almacenamiento dos veces y, más caro aún, paga el esfuerzo de mantenerlos sincronizados.
• Datos rancios: entre que algo llega al lake y termina disponible en el warehouse pasan horas o días. Los tableros muestran una foto que ya envejeció.
• Pipelines frágiles: cada proceso de copia (ETL/ELT) es una pieza más que se rompe. Cuando falla, alguien recibe una llamada de madrugada.
• BI y ML divorciados: los analistas viven en el warehouse con SQL; los científicos de datos viven en el lake con Python y Spark. Trabajan sobre versiones distintas de la verdad.
• Gobernanza fragmentada: aplicar permisos, linaje y calidad de forma consistente en dos sistemas con modelos de seguridad diferentes es un dolor de cabeza permanente.

Qué es un lakehouse

Un lakehouse es una arquitectura de datos que añade una capa transaccional y de gestión de metadatos encima del almacenamiento de objetos del lake (por ejemplo, almacenamiento en la nube con archivos Parquet). Esa capa convierte un montón de archivos sueltos en algo que se comporta como tablas de base de datos: con esquema, con control de versiones y con transacciones confiables.

Dicho de otro modo: en lugar de mover los datos al warehouse para obtener sus garantías, usted lleva las garantías del warehouse a donde ya están los datos. Un solo repositorio, abierto, sirve tanto al tablero de la dirección como al modelo de propensión de compra.

Qué unifica el lakehouse

El valor del lakehouse no es un solo truco, sino la suma de tres cosas que históricamente vivían separadas.

• Formatos abiertos: los datos se guardan en formatos de tabla abiertos (como los que han ganado tracción estos años: Delta Lake, Apache Iceberg, Apache Hudi) sobre archivos columnares estándar. No quedan atrapados en el motor propietario de un warehouse; cualquier herramienta compatible puede leerlos.
• Transacciones ACID: la capa de tabla aporta atomicidad y consistencia. Varias escrituras y lecturas concurrentes no se pisan, y una carga a medias no deja la tabla corrupta. Esto es lo que faltaba en el lake clásico.
• BI y ML sobre un solo lugar: el mismo conjunto de tablas alimenta consultas SQL para tableros y, a la vez, el entrenamiento de modelos con Spark o Python. No hay dos copias ni dos verdades.

A esto se suman funciones que antes eran exclusivas del warehouse: aplicación de esquema (schema enforcement) y su evolución controlada, y el llamado time travel, que permite consultar el estado de una tabla en un momento anterior —oro puro para auditoría y para reproducir un experimento de ML.

Beneficios concretos

Cuando la arquitectura se simplifica, los beneficios bajan a tierra rápido.

• Una sola fuente de verdad: menos copias significa menos discrepancias entre lo que dice el tablero y lo que dice el modelo.
• Menos pipelines que mantener: al eliminar la etapa de copia lake-a-warehouse, hay menos código frágil y menos puntos de falla.
• Datos más frescos: el análisis trabaja sobre datos cercanos al momento en que se ingieren, no sobre una carga nocturna.
• Costos más controlados: el almacenamiento de objetos es barato y se separa del cómputo, que se enciende solo cuando se necesita.
• Gobernanza unificada: permisos, calidad y linaje se aplican una sola vez, sobre un solo conjunto de tablas.

Para una organización que está construyendo capacidades de analítica y quiere que esos mismos datos sostengan iniciativas de IA, evitar la bifurcación entre BI y ML es, quizá, el argumento más fuerte.

Cuándo adoptarlo (y cuándo no correr)

El lakehouse es una arquitectura emergente, no una bala de plata. Vale la pena considerarlo cuando:

• Usted ya tiene un data lake y siente el dolor de copiar datos al warehouse una y otra vez.
• Sus casos de uso de BI y de machine learning compiten por los mismos datos y hoy viven en mundos separados.
• El volumen y la variedad de datos (semiestructurados, eventos, archivos) hacen pesado al warehouse tradicional.
• Quiere evitar el bloqueo de proveedor y conservar los datos en formatos abiertos.

Conviene ir con cautela si su carga es modesta y un warehouse bien dimensionado ya la resuelve sin fricción, o si su equipo aún no tiene madurez operando almacenamiento de objetos y motores distribuidos. La migración no es trivial: implica replantear ingestión, gobernanza y herramientas de consumo. Lo sensato suele ser empezar por un dominio acotado y crecer desde ahí.

Preguntas frecuentes

¿El lakehouse reemplaza por completo al data warehouse?

Esa es la promesa de fondo, pero en 2022 la mayoría de las organizaciones convive con ambos durante la transición. El lakehouse aspira a cubrir los casos de uso del warehouse sin un sistema separado; llegar ahí es un camino, no un interruptor.

¿Necesito tirar mi data lake actual para tener un lakehouse?

No. Un lakehouse suele construirse sobre el almacenamiento que usted ya tiene, añadiendo una capa de tabla abierta encima de sus archivos. Es más evolución que reemplazo.

¿Qué diferencia al lakehouse de simplemente consultar el lake con SQL?

Consultar el lake directamente no le da transacciones confiables, control de esquema ni rendimiento consistente. La capa transaccional del lakehouse es justo lo que aporta esas garantías de warehouse sobre los archivos.

¿Sirve igual para BI que para machine learning?

Ese es el punto. Las mismas tablas alimentan consultas SQL para tableros y, sin copiar nada, el entrenamiento de modelos. Esa convergencia es la razón principal para mirarlo.

El primer paso

Antes de elegir un formato de tabla o un motor, el primer paso es honesto y aburrido: mapear dónde duele hoy su arquitectura de datos. ¿Cuántas veces se copian los mismos datos? ¿Qué tan frescos llegan a sus tableros? ¿BI y ML trabajan sobre la misma verdad? Con ese diagnóstico, decidir si el lakehouse aporta valor real deja de ser una moda y pasa a ser una decisión de ingeniería.

En SUMāTO acompañamos a organizaciones de LATAM a hacer ese diagnóstico y a diseñar la ruta —sin saltos al vacío. Si quiere conversar sobre su caso, escríbanos en sumatogroup.com/contacto.