Data Lakehouse: principales características, ventajas e inconvenientes

Después de ya bastante tiempo escuchando hablar de lagos de datos, y de data warehouse, está comenzando a escucharse, cada vez con más fuerza, un tercer concepto relacionado con el almancenamiento de información: data lakehouse. Se refiere a un nuevo concepto para el almacenamiento y gestión de datos, que nace como arquitectura de gestión híbrida salida de la combinación de las características más destacadas del data lake y del data warehouse. Por su naturaleza, para poder comprender bien qué es, resulta necesario tener claros los conceptos de data lake y data warehouse.

Cuando hablamos de data lake, o lago de datos, hablamos de un repositorio centralizado encargado de almacenar grandes cantidades de datos en su formato original. Es decir, es un conjunto de datos desestructurados. Cuando hablamos de data warehouse, por otro lado, nos referimos a un almacen de datos estructurados y semiestructurados, procedentes de varias fuentes, y que se suelen utilizar para realizar análisis e informes.

Que es un data lakehouse

Un data lakehouse se encarga de combinar ambos tipos de almacenamiento, y de cubrir la brecha que queda entre ambos enfoques. Para ello combina la flexibilidad, la escala y el coste ajustado del data lake, con el rendimiento y las transacciones características de un data warehouse, caracterizadas por su durabilidad, aislamiento, consistencia y atomicidad. Al unir esto, que supone lo mejor de ambos conceptos, permite reunir las analíticas y la inteligencia de todo tipo de datos en una sola plataforma.

Las características que recoge un data lakehouse de un data lake permite que las empresas y organizaciones que utilizan esta arquitectura puedan almacenar grandes cantidades de datos sin necesidad de disponer un esquema estricto, o de admitir solo un formato o formatos determinados para ellos. Eso sí, a esto añade varias funciones que faltan en un lago de datos: gobernanza, organización y capacidades de rendimiento para analítica e informes.

A pesar de que esto acerca a los data lakehouse a los data warehouse, también tienen diferencias con ellos. Un data warehouse emplea procesos ELT (extracción, carga y transformación) o ETL (extracción, transformación y carga) para cargar datos estructurados en una infraestructura de base de datos relacional, y es compatible con analíticas de datos de empresa y aplicaciones de business intelligence. Eso sí, tiene sus límites: no es precisamente eficiente en la gestión de datos desestructurados y semiestructurados. Además, puede tener costes elevados a medida que vayan creciendo la cantidad de datos a almacenar, y las fuentes desde las que se toman.

Un data lakehouse soluciona también estos inconvenientes de los data warehouse, integrando la flexibilidad y la efectividad en cuanto a costes de los lagos de datos, con la gobernanza, organización y capacidad de rendimiento de los data warehouse. Soluciona por lo tanto los problemas de ambas arquitecturas, lo que convierte a esta arquitectura en atractiva para profesionales y especialistas que trabajan en áreas muy concretas.

Así, los científicos de datos pueden utilizarlo para trabajar en machine learning, Business Intelligence, analíticas de SQL y ciencia de datos. Por su parte, los analistas de negocio pueden aprovechar sus funciones y características para explorar y analizar varias fuentes de datos, y trabajar en distintas áreas de negocio.

Otros profesionales que le sacarán partido son los responsables de producto, los expertos en marketing, y los directivos en general. Todos pueden usarlo para la monitorización y control de distintas tendencias e indicadores.

Arquitectura de un data lakehouse

La arquitectura de un data lakehouse, según eWeek, está compuesta de cinco capas. La primera es la conocida como capa de ingestión. Su misión es recopilar los datos de varias fuentes y llevarlos o bien a la capa de almacenamiento o a un sistema de proceso de datos. Utiliza distintos protocolos para la conexión de fuentes internas y externas.

Entre ellas, sistemas de gestión de bases de datos, aplicaciones de software como servicio, bases de datos noSQL, redes sociales, aplicaciones de CRM, sensores de Internet de las Cosas y sistemas de archivos. La capa de ingestión puede encargarse de la extracción de datos de una sola vez, o hacerlo en varias, en función del tamaño del conjunto de datos a obtener y de la fuente en la que se encuentren.

La segunda capa de la arquitectura de un data lakehouse es la de almacenamiento, en la que acepta todo tipo de datos como objetos, en sistemas de almacenamiento de objetos. Por ejemplo, en S3 de AWS. Esta capa permite guardar datos estructurados, desestructurados y semiestructurados en formatos de archivo open source, como Apache Avro, Parquet u ORC (Optimized Row Columnar). Además de en la nube, también se puede implementar en local, utilizando un sistema de archivo distribuido, como HDFS de Hadoop.

En cuanto a la tercera capa de la arquitectura, la de metadatos, supone el origen de un data lakehouse. Por tanto, es una de sus capas más importantes. Contiene información sobre otros datos, y supone un catálogo unificado que incluye los metadatos de los objetos de un lago de datos.

Además, ofrece a quienes utilizan un data lakehouse con diversas funciones: transacciones ACID que aseguran la atomicidad, consistencia, aislamiento y durabilidad de los cambios en los datos; y opciones de cacheado de archivo que optimizan el acceso de datos manteniendo los archivos de acceso frecuente disponibles en memoria. También aporta indexado, que acelera las queries permitiendo la recuperación rápida de datos, y versionado de información, que permite guardar versiones concretas de los datos. Se trata de una capa que permite implemenar esquemas predefinidos para mejorar la gobernanza de datos.

Las dos últimas capas son la de API y la de consumo. La capa de API es también una de las más relevantes de un data lakehouse, ya que permite que ingenieros y científicos de datos, y analistas, accedan a los datos almacenados en la estructura, y los manipulen para tareas de analítica o informes, entre otros usos. La capa de consumo, la última de una arquitectura de data lakehouse, se usa para almacenar herramientas y aplicaciones con las que los usuarios acceden a los datos, haciendo queries, analizándolos y procesándolos.

Claves, ventajas e inconvenientes de un data lakehouse

Entre los puntos más destacados de la arquitectura de un data lakehouse, a tenor de lo que hemos visto, están los siguientes: compatibilidad con transacciones ACID para conseguir consistencia y fiabilidad de datos en un entorno distribuido; almacenamiento de datos eficiente en cuanto a costes para todo tipo de datos; soporte de datos estructurados, desestructurados y semiestructurados; y compatibilidad con formatos abiertos.

Esto lleva a que un data lakehouse tenga numerosas ventajas, que hacen que en diversos casos sea preferible utilizar este tipo de arquitectura frente a un data lake o a un data warehouse. Ofrece una plataforma de datos unificada y elimina los silos de datos. Además, es compatible con proceso en tiempo real. De esta manera se puede conseguir información de forma inmediata y con rapidez. También deja procesar información por lotes, para análisis a gran escala.

Mantener un data warehouse y un data lake puede resultar caro, pero con un data lakehouse, los equipos de gestión de datos solo tienen que desplegar y gestionar una plataforma para los datos. Se reducen por tanto los costes de gestionar, desplegar y mantener dos. También mejora la gobernanza de datos, ya que consolida recursos y fuentes de datos.

Así mejora el control sobre la seguridad, las métricas, el acceso basado en roles y todo tipo de funciones y aspectos de la gestión de información. Por último, también reduce la duplicación de datos, ya que no trabaja con dos sistemas de almacenamiento de datos, sino solo con uno. No habrá por tanto más de una copia de la información. Ofrece una sola fuente de datos que se puede compartir en distintas áreas de una empresa.

A la vista de todo esto, parece que un data lakehouse fuese a convertirse en la única arquitectura adecuada para el almacenamiento de datos en el mundo de la empresa y la investigación. Pero no siempre es así, porque también tiene sus inconvenientes. Además, es un concepto relativamente nuevo, y todavía se están explorando sus capacidades. Y por tanto, sus puntos flacos.

Para empezar, se trata de un sistema que resulta complejo desarrollar desde cero. Para crearlo hay que elegir una solución de data lakehouse lista para utilizar, con rendimiento variable en función de los tipos de query o del motor de proceso que utilice, o invertir tiempo y recursos en desarrollar y mantener una solución a medida.

Al tratarse de un nuevo concepto de gestión de datos, no es tampoco una solución completa para un data lake o un data warehouse convencional, sino una combinación de ambos. Además, no está desarrollado a prueba de fallos, y sobre todo de intrusos.

Los que decidan poner uno en marcha tendrán que ser proactivos en cuanto a su protección, y tomar medidas para gestionar los riesgos de seguridad asociados con el almacenamiento de datos y su complejidad. Eso por no hablar de que pueden aparecer problemas de calidad de datos y de arquitectura con el uso de este tipo de arquitectura. Por lo tanto, al estudiar qué arquitectura es más conveniente para el almacenamiento de datos de una empresa, conviene examinar todas las opciones disponibles con cautela.