El volumen masivo de información actual impulsó al Data Lake como pilar de la arquitectura de datos. Pero recolectar información sin estructura puede llevar al caos si no se aplican marcos de calidad y gobierno. Este artículo recorre la concepción original del Data Lake, los riesgos de una mala gestión, la revolución de los formatos de tabla abierta, la emergente capa de catálogos abiertos, el papel del Lakehouse como cimiento de la IA generativa, y por qué la industria avanza hacia modelos descentralizados [2], [10], [5], [12].
El concepto original: datos crudos y schema-on-read
El término Data Lake fue acuñado por James Dixon alrededor de 2010 como contraste frente al Data Mart tradicional [1]. Los Data Lakes modernos en la nube surgieron como alternativa a los repositorios centralizados, basándose en el almacenamiento de objetos (Amazon S3, Azure Data Lake Storage, Google Cloud Storage) para guardar inmensas cantidades de datos estructurados y no estructurados de forma económica [2], [3].
Esta arquitectura permite recolectar datos crudos y definir el esquema al momento de leerlos (schema-on-read), favoreciendo la agilidad bajo la premisa de que los datos crudos disponibles rápidamente son más valiosos que los modelos diseñados por adelantado [2].
El peligro de la mala gestión: el data swamp
Eliminar el esquema por adelantado brinda velocidad, pero eludir el modelado de datos trae consecuencias severas. La falta de rigor crea los llamados pantanos de datos (data swamps): acumulaciones de datos redundantes, incompatibles o erróneos [2].
De acuerdo con el estándar DMBOK, la disciplina exige integrar funciones de Gobierno de Datos y Gestión de Calidad para que los activos de información estén protegidos, sean útiles y confiables [4]. Lejos de perder vigencia, este requisito se ha vuelto crítico en la era de la IA: modelos entrenados o alimentados con datos de baja calidad propagan errores a escala — garbage in, hallucination out.
La evolución: formatos de tabla abierta y el Lakehouse
Para resolver las carencias del Data Lake crudo sin perder flexibilidad, la industria adoptó la arquitectura Data Lakehouse, formalizada por Armbrust et al. como una plataforma abierta que unifica el almacén analítico con las capacidades de un Data Lake [5], [7]. Su fundamento técnico son los formatos de tabla abierta (Open Table Formats, OTF).
Antes, el estándar para almacenar analítica masiva era Apache Parquet [2]. Pero los archivos Parquet son inmutables: no se pueden modificar sin reescribir todo el archivo. Los formatos de tabla abierta resuelven esto envolviendo los archivos de datos con una capa de metadatos y un registro de transacciones, que otorga a los lagos capacidades antes exclusivas de las bases de datos:
- Transacciones ACID: garantizan fiabilidad en operaciones de grandes volúmenes, evitando escrituras parciales [6].
- Evolución y aplicación de esquemas: el registro de transacciones rechaza los datos que no cumplen el formato, o permite agregar y cambiar tipos de columnas dinámicamente (schema evolution).
- Versionado y operaciones DML: permite fusionar, actualizar y viajar en el tiempo (time travel) para consultar o restaurar versiones anteriores de una tabla.
Los tres formatos y la "guerra de formatos"
Aunque Delta Lake (creado por Databricks) popularizó este enfoque, hoy conviven tres formatos de tabla abierta principales, y limitar el análisis a uno solo ofrece una visión incompleta del panorama [8], [9]:
| Aspecto | Delta Lake | Apache Iceberg | Apache Hudi |
|---|---|---|---|
| Origen | Databricks | Netflix / Apache | Uber / Apache |
| Fortaleza | Integración con Spark y el ecosistema Databricks | Interoperabilidad multi-motor y evolución de partición | Upserts, CDC y baja latencia |
| Caso de uso típico | Lakehouse sobre Spark | Estándar neutral entre motores | Ingesta incremental y streaming |
| Adopción | Amplia vía Databricks | Estándar de facto emergente | Nichos de ingesta en tiempo real |
El caso de Apache Iceberg merece atención especial: tras la adquisición de Tabular (los creadores de Iceberg) por parte de Databricks en 2024, y su adopción nativa por Snowflake, Google BigQuery y Amazon S3 Tables, se ha consolidado como el estándar neutral de interoperabilidad entre motores de cómputo [9].
Convergencia: no hay que elegir un ganador
Una tendencia clave matiza la "guerra de formatos": la interoperabilidad. Herramientas como Delta UniForm (Universal Format) y el proyecto Apache XTable (antes OneTable) permiten exponer una misma tabla física en varios formatos de metadatos simultáneamente, de modo que un motor pueda leerla como Iceberg y otro como Delta. El futuro no parece ser "un formato ganador", sino una capa de metadatos interoperable [9], [8].
Esta combinación elimina la necesidad de mantener silos separados —Data Lakes para crudos y Data Warehouses para analítica— y consolida el ecosistema en un Lakehouse unificado que soporta cargas por lotes (batch) y flujos continuos (streaming) [5], [7].
La nueva frontera: la capa de catálogos abiertos
Si la década pasada giró en torno al formato de los datos, la conversación de 2025–2026 se ha desplazado hacia el catálogo: la capa que gestiona qué tablas existen, quién puede acceder a ellas y cómo se gobiernan. El Iceberg REST Catalog se ha convertido en una interfaz estándar, y han surgido implementaciones abiertas como Apache Polaris (donado por Snowflake) y Unity Catalog (liberado como código abierto por Databricks en 2024).
Esta capa es hoy donde vive buena parte de la gobernanza técnica descrita por DMBOK: permisos de acceso, linaje (lineage), descubrimiento de datos (discovery) y auditoría [4]. Un Lakehouse sólido en 2026 se define tanto por su catálogo como por su formato de tabla.
El Lakehouse como cimiento de la IA
El contexto que define la industria de datos en 2026 es la IA generativa, y el Lakehouse se ha posicionado como su base de datos natural. Los datos no estructurados (texto, documentos, imágenes) que antes se descartaban son ahora el combustible de los patrones de Retrieval-Augmented Generation (RAG). Esto trajo nuevas exigencias a la arquitectura:
- Búsqueda vectorial (vector search) y gestión de embeddings integrados en el propio Lakehouse.
- Feature stores para servir características de forma consistente a modelos de machine learning.
- Trazabilidad y gobierno de los datos que alimentan a los modelos.
La disciplina de calidad y gobierno deja de ser una buena práctica opcional para volverse un requisito de fiabilidad de los sistemas de IA.
El desafío a escala: descentralización y contratos de datos
A pesar del poder tecnológico del Lakehouse, centralizar todos los datos y su gestión en un único equipo genera cuellos de botella insuperables [10], [12]. Tendencias como los microservicios, las APIs y la nube fragmentan los paisajes de información, haciendo de la descentralización un destino natural.
Para organizaciones a gran escala, Zhamak Dehghani propuso el Data Mesh (malla de datos), que invierte la propiedad centralizada hacia equipos de dominio de negocio, tratando a la información como un producto autoservicio y gobernado mediante metadatos unificados (federated computational governance) [11], [12]. Como enfoque complementario, el Data Fabric propone una capa de integración inteligente y automatizada sobre datos distribuidos [10].
El estado del arte práctico para hacer viable el "dato como producto" son los contratos de datos (data contracts): acuerdos explícitos y versionados entre productores y consumidores sobre el esquema, la semántica y las garantías de calidad de un conjunto de datos. Junto con el enfoque shift-left —desplazar la validación de calidad lo más cerca posible del origen— constituyen el mecanismo concreto que convierte la teoría del Data Mesh en una práctica operable [13].
Conclusión
El Data Lake dejó de ser un simple repositorio de archivos crudos. Evitar el colapso hacia un pantano de datos exige controles de calidad estrictos, la adopción de formatos de tabla abierta transaccionales (Delta, Iceberg, Hudi) y su creciente interoperabilidad, una capa de catálogos abiertos que centralice el gobierno, y el reconocimiento del Lakehouse como cimiento de las cargas de IA. Para grandes organizaciones, todo ello se complementa con la valentía de transicionar hacia arquitecturas descentralizadas orientadas al dominio y gobernadas mediante contratos de datos [2], [12], [5].
Referencias
- Dixon, James. Pentaho, Hadoop, and Data Lakes (entrada de blog que acuña el término "Data Lake"), 2010.
- Reis, Joe; Housley, Matt. Fundamentals of Data Engineering. O'Reilly, 2022.
- Kleppmann, Martin. Designing Data-Intensive Applications. O'Reilly, 2017.
- DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, 2ª ed. Technics Publications, 2017.
- Armbrust, M.; Ghodsi, A.; Xin, R.; Zaharia, M. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. CIDR, 2021.
- Armbrust, M. et al. Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. PVLDB, vol. 13, 2020.
- Inmon, B.; Levins, M.; Srivastava, R. Building the Data Lakehouse. Technics Publications, 2021.
- Lee, D.; Wentling, T.; Haines, S.; Babu, P. Delta Lake: The Definitive Guide. O'Reilly, 2024.
- Shiran, T.; Hughes, J.; Merced, A. Apache Iceberg: The Definitive Guide. O'Reilly, 2024.
- Strengholt, Piethein. Data Management at Scale, 2ª ed. O'Reilly, 2023.
- Dehghani, Zhamak. How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh. martinfowler.com, 2019.
- Dehghani, Zhamak. Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly, 2022.
- Jones, Andrew. Driving Data Quality with Data Contracts. Packt, 2023.