Arquitectura híbrida, conexión a lakehouses existentes y Managed Lakehouse nativo: cómo Irion EDM® lleva el paradigma lakehouse a la plataforma sin imponer migraciones ni formatos propietarios.
Del data warehouse al data lake: una historia conocida
Quienes trabajan con datos desde hace algunos años conocen bien esta historia: de los data warehouses a los data lakes, hasta llegar a las arquitecturas lakehouse. Cada paso respondió a problemas reales, aunque introdujo otros nuevos.
Merece la pena recorrer las principales etapas de este camino —un camino que para muchas empresas aún está en curso— porque entender de dónde venimos ayuda a comprender por qué la arquitectura lakehouse, y su integración dentro de Irion EDM®, representa hoy una respuesta madura a necesidades concretas de las empresas.
La era de los data warehouses: solidez a un alto precio
Los data warehouses dominaron la escena durante décadas, y con razón. Garantizaban todo lo que una organización esperaba de un sistema de datos: consistencia, transacciones fiables y una única source of truth.
El problema llegó con el crecimiento del volumen de datos. Los warehouses no escalaban fácilmente, sobre todo horizontalmente, y hacerlos escalar verticalmente requería a menudo intervenciones de infraestructura costosas. Pero también había un segundo problema: los datos se guardaban en formatos propietarios. Para acceder a ellos había que pasar por el mismo proveedor o duplicarlos en otro lugar, perdiendo de hecho la unicidad de la fuente. El vendor lock-in estaba a menudo incorporado en la propia arquitectura.
Los data lakes: libertad sin governance
La respuesta al warehouse fue el data lake: separar los datos de la lógica de consulta, usar formatos abiertos y distribuir el almacenamiento en sistemas escalables. Las primeras implementaciones, basadas en el ecosistema Hadoop y en sistemas de archivos distribuidos como HDFS, eran predominantemente on-premise; con la llegada del cloud, el modelo evolucionó hacia un almacenamiento económico y virtualmente ilimitado. Un avance importante también en términos de escalabilidad, gracias a la separación entre compute y storage, que en los sistemas warehouse tradicionales tendían a crecer juntos.
Parecía la solución definitiva. Pero no lo era.
El data lake sufría, y sigue sufriendo, un problema de semántica. Una “tabla” puede estar distribuida en cientos o miles de archivos, con una estructura y un significado a menudo conocidos solo por los procesos que los generaron. Solo quien escribió esos datos sabe cómo leerlos correctamente. En la práctica, muchos data lakes se han transformado en lo que en el sector se denomina, no sin ironía, data swamp: un depósito de datos no gobernados y difíciles de utilizar.
Del data lake al lakehouse: los open table formats y el concepto de catálogo
El siguiente paso fue intentar recuperar lo que se había perdido —governance, consistencia, semántica— sin renunciar a las ventajas de la escalabilidad cloud y de los formatos abiertos. De esta necesidad nació el concepto de lakehouse: una arquitectura que combina la flexibilidad y la eficiencia económica del almacenamiento cloud con algunas garantías típicas de las bases de datos tradicionales.
Un lakehouse es una arquitectura híbrida que combina los mejores elementos de un data lake y de un data warehouse: storage y compute están desacoplados y se basan en estándares abiertos, porque los datos residen en object storage en forma de archivos, pero pueden ser consultados por distintos motores de cálculo. Para el usuario final, el sistema se comporta como un data warehouse —soporte SQL, esquemas estructurados, garantías ACID—, mientras internamente mantiene la flexibilidad de un data lake.
Para hacer posible esta integración son necesarios dos componentes fundamentales, que reflejan precisamente la unión de ambos mundos: los open table formats y el metadata catalog. El lakehouse puede verse no solo como un nuevo enfoque arquitectónico, sino también como la integración de componentes específicos.
Los open table formats —entre los más conocidos, Delta Lake y Apache Iceberg— resuelven el problema de la semántica a nivel de tabla individual. La intuición de base era tan sencilla como potente: hacer que un conjunto de archivos físicos sea visible y consultable como si fuera una única tabla coherente. Estos formatos registran las operaciones de inserción, modificación y eliminación sin modificar directamente los archivos, que permanecen inmutables, gestionando las versiones mediante metadatos.
De este modo, las tablas resultan modificables a nivel lógico, y la capa de compute puede acceder de forma transparente a la versión correcta de los datos, manteniendo un histórico de las versiones.
Pero una base de datos no es una sola tabla. Es un conjunto de tablas, con relaciones y versiones. Y así volvió la necesidad de un componente adicional: no una base de datos en el sentido clásico del término, sino un catálogo, un registro central que indica a cualquier motor de consulta qué tablas existen, dónde se encuentran físicamente y a qué versión corresponden. Con esta información, el motor accede de forma consistente a los datos correctos, independientemente de cuántos archivos los compongan físicamente.
Catálogo más open table format: eso es el lakehouse. Una arquitectura que devuelve orden y gobernabilidad a los datos distribuidos, manteniendo la separación entre storage y compute y —algo fundamental— utilizando estándares abiertos accesibles para cualquier motor, sin duplicación ni pasos adicionales.
Cómo Irion integra la arquitectura lakehouse
La decisión de integrar la arquitectura lakehouse en Irion EDM no es solo una decisión tecnológica: es la aplicación concreta de una filosofía arquitectónica precisa, la separación entre compute y storage, típica de las arquitecturas cloud-native. Compute y storage operan en niveles independientes, escalables por separado, sin que el crecimiento de uno condicione al otro. Es este principio el que hace que la arquitectura lakehouse sea sostenible en el tiempo.
Irion la integra directamente en la plataforma de dos formas complementarias.
Para quienes ya cuentan con su propio lakehouse, Irion se conecta directamente a él, sin requerir migraciones ni imponer formatos propietarios.
Para las organizaciones que aún no disponen de un lakehouse, pone a disposición el Managed Lakehouse: una herramienta para persistir datos en un lakehouse directamente dentro de la plataforma. El Managed Lakehouse está diseñado para entornos Kubernetes , con una arquitectura cloud-native que incluye funcionalidades nativas de backup, monitorización, resiliencia y alta disponibilidad.
En ambos casos, el objetivo es el mismo: no se trata solo de añadir un almacenamiento analítico, sino de llevar esta arquitectura dentro de una plataforma ya orientada a la governance, la calidad y la gestión del dato.
Conexión a lakehouses existentes: cero migraciones, cero duplicaciones
Para las organizaciones que ya han construido su propio lakehouse, Irion se conecta directamente a la infraestructura existente. Sin migraciones, sin duplicaciones, sin imponer formatos propietarios.
Irion soporta la conexión a lakehouses basados en estándares abiertos y consolidados como Apache Iceberg y Delta Lake, catálogos interoperables como Unity Catalog, incluidos formatos emergentes compatibles con los ecosistemas open table, como DuckLake. Independientemente de la tecnología utilizada, si los datos están escritos sobre estándares abiertos o compatibles, Irion puede leerlos.
Esto permite adoptar la solución sin depender de un cloud provider específico y abre la puerta a estrategias híbridas: datos “calientes” en file systems de alto rendimiento, volúmenes históricos en blob storage de bajo coste. El ahorro del TCO puede ser considerable, sobre todo en organizaciones que gestionan datasets de gran tamaño con acceso predominantemente de lectura, y todo ello sin comprometer la accesibilidad, el rendimiento ni la governance del dato.
El Managed Lakehouse: construir un lakehouse directamente en Irion
Desde sus inicios, Irion ha integrado de forma nativa la capacidad de persistencia de los datos en el propio producto: una ventaja concreta que permite trabajar de forma más ágil y eliminar la dependencia de tecnologías externas. Hasta ahora, esta capa de almacenamiento se encargaba a DataShelf, una estructura propia desarrollada sobre SQL Server. A DataShelf se suma una segunda opción: un Managed Lakehouse, gestionado íntegramente por Irion, que abre las puertas a nuevos escenarios para quienes trabajan con grandes volúmenes de datos y favorece una mayor interoperabilidad con los ecosistemas de datos modernos.
El Managed Lakehouse se basa en estándares abiertos del mercado: esto significa que también es accesible desde herramientas de terceros y que se integra de forma nativa con las arquitecturas hub & spoke, lo que permite consultar datos que residen en un nodo independiente de Irion sin tener que trasladarlos físicamente (para obtener más información sobre la arquitectura, consulta el informe técnico Data Quality Hub).
Las ventajas de construir un lakehouse dentro de Irion son principalmente dos: la reducción del TCO y del vendor lock-in.
Habitualmente, las cargas analíticas —grandes volúmenes históricos, datasets de reporting o datos predominantemente de lectura— suelen residir en bases de datos relacionales comerciales como SQL Server, Oracle, DB2 o Teradata, con costes de licencia ligados también a la cantidad de datos gestionados. Trasladarlos a un lakehouse significa sacarlos de estos sistemas , reduciendo la necesidad de la base de datos relacional y, en consecuencia, el coste de licencia.
Además, como hemos dicho, toda la estructura del Managed Lakehouse de Irion se basa en estándares abiertos: los datos están en un formato conocido y accesible, los metadatos residen en una base de datos alcanzable mediante protocolos estándar y, por tanto, pueden ser leídos también por herramientas externas. Esto significa que los Managed Lakehouse pueden ser leídos también por motores de terceros compatibles con los estándares de mercado, sin pasar por las API.
Todas estas características reducen significativamente el vendor lock-in: los datos de Irion son legibles desde el exterior, incluso sin saber que están gestionados por Irion. Los datos permanecen accesibles en formatos abiertos e interoperables, independientemente de la plataforma que los gestione.
Consultas híbridas entre fuentes distintas
Ya sea que los datos se encuentren en el Managed Lakehouse de Irion o en un lakehouse externo, pueden leerse y consultarse allí donde residan. Pero hay más.
Irion permite ejecutar consultas híbridas : en una única consulta es posible combinar datos procedentes de cualquier lakehouse con datos procedentes de cualquier otra fuente ya censada en la plataforma. Una join entre una tabla del lakehouse y un dataset procedente de una conexión externa es posible y transparente para el usuario, sin procesos de copia ni pipelines de integración dedicadas, gracias a sofisticadas técnicas de pushdown que optimizan la ejecución directamente en la fuente.
Todo esto es posible gracias al Analytics Engine de Irion, un nuevo motor analítico columnar que opera en modalidad in-memory y/o on-disk, diseñado nativamente para cargas OLAP.
Conclusiones
Integrar el lakehouse en Irion EDM®. fue una elección precisa: llevar una arquitectura madura y moderna dentro de una plataforma ya orientada a la governance y la calidad del dato, sin imponer migraciones, añadir complejidad ni alterar lo que las organizaciones ya han construido.
Tanto en el caso de un Managed Lakehouse construido en Irion como en el caso de una conexión a infraestructuras existentes, el principio sigue siendo el mismo: los datos pertenecen a la organización, están en formatos abiertos y son accesibles desde cualquier motor compatible. La elección arquitectónica de hoy no cierra la puerta a las opciones tecnológicas de mañana.
De ello se derivan dos beneficios muy concretos: una reducción del TCO, trasladando las cargas analíticas fuera de las bases de datos relacionales comerciales, y una reducción del vendor lock-in en aquellos casos en los que se utilizan estándares abiertos, minimizando las dependencias de proveedores específicos.
El lakehouse es solo una de las etapas de un recorrido de evolución que Irion ha emprendido, cada vez más orientado al futuro.
Seguid acompañándonos: aún tenemos mucho que contar, y estamos deseando hacerlo en los próximos encuentros.Continuate a seguirci: abbiamo ancora molto da raccontare, e non vediamo l’ora di farlo nei prossimi appuntamenti.
