Data Lake y Lakehouse
Del almacén al lago
El almacén exige esquema y modelado antes de cargar, lo que frena guardar datos no estructurados o de origen incierto. El lago invierte la idea: se carga todo en crudo y se interpreta al leer, abaratando el almacenamiento y admitiendo cualquier formato.
El pantano
Sin gobierno, el lago acumula ficheros huérfanos, versiones duplicadas y columnas cuyo significado nadie recuerda. La flexibilidad de «esquema al leer» se paga con datos poco confiables si no hay metadatos ni calidad.
Formatos abiertos
Aquí entran formatos de archivo columnar como Parquet u ORC: autodescriptivos, comprimidos y leídos por casi cualquier motor. Almacenar en formato abierto y neutral evita el cautiverio de un único producto.
Capa de tabla
- Delta, Iceberg o Hudi añaden transacciones y control de versiones sobre ficheros.
- Habilitan actualizaciones seguras y lecturas consistentes donde antes solo había sobrescritura.
- Traen al lago garantías propias del almacén sin renunciar a su economía.
Lakehouse
El lakehouse une almacenamiento de lago barato con una capa de gestión de tablas que aporta ACID, schema evolution y gobernanza. Sobre él pueden operar tanto el ingeniero que modela como el científico que explora.
Quién usa qué
El almacén sigue brillando en informes disciplinados y gobernados; el lakehouse amplía el público a machine learning y análisis ad hoc, con los datos en un único sitio en lugar de copias paralelas.
Cuándo basta un lago
Si el caso es retención de datos brutos para cumplimiento o experimentación sin consumo estable, un lago gobernado con catálogo basta. La capa de tabla se justifica cuando múltiples motores escriben sobre lo mismo con garantías.
Errores frecuentes
- Tratar el lago como vertedero sin metadatos ni calidad y luego llamarlo pantano con sorpresa.
- Creer que el lakehouse elimina la necesidad de modelar: la capa de tabla da garantías, no respuestas.
- Guardar todo en el formato privativo de un producto y descubrir el cautiverio al querer migrar.
Ejemplo resuelto: decidir arquitectura para una red de sensores
Una empresa quiere explorar datos brutos de sensores y a la vez servir informes gobernados desde el mismo sitio. El razonamiento:
- Distinguir audiencias: exploración abierta que tolera crudo, e informes que exigen contratos estables.
- Descartar el lago puro, que no impide lecturas inconsistentes cuando varios motores escriben.
- Descartar el almacén clásico, caro para retener todo el histórico en bruto.
- Adoptar un lakehouse con formato abierto columnar y capa de tabla transaccional.
- Poner catálogo y controles de calidad en la entrada para que la flexibilidad no degenere en pantano.
¿Para qué sirve en la realidad?
Casi toda plataforma de datos actual decide esta arquitectura al crecer: telemetría, logs y eventos conviven con cuadros de mando regulados. El lakehouse evita mantener dos copias paralelas de la verdad y sus facturas.
La principal aportación de una capa de tabla como Delta o Iceberg sobre un lago de ficheros es:
Un data lake exige modelar y fijar el esquema antes de cargar los datos.
Lakehouse
Toca una tarjeta para ver la respuesta.
Ordena la evolución arquitectónica descrita:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
Data lakeOrigen, promesas y riesgos de los lagos de datos frente al almacén clásico.
Une cada concepto con su definición.
La síntesis lago-almacén
- Lago y lakehouse
- Almacén
- gobernado y caro
- gobernado y caro
- solo estructurado
- Almacén
- barato y crudo
- Delta o Iceberg
- informes y machine learning
Qué es un data lakehouseArquitectura, componentes y ventajas del lakehouse según Google Cloud.
Tu equipo de datos quiere explorar datos brutos de sensores y a la vez servir informes gobernados desde el mismo sitio. ¿Lago puro, almacén o lakehouse? Argumenta por garantías y formato abierto.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.