Evolución de las arquitecturas de datos. De los almacenes de datos relacionales a los Data Lakehouses

Los datos son como una materia prima que necesita ser extraída, refinada y procesada para ser útil. En el caso de los datos, esto implica recopilarlos, almacenarlos y analizarlos para obtener conocimientos que puedan impulsar decisiones empresariales.

Su valor es inmenso. Las empresas que recopilan y analizan grandes volúmenes de datos pueden utilizarlos para mejorar sus productos y servicios, tomar mejores decisiones comerciales y obtener una ventaja competitiva.

Además, los datos pueden emplearse de muchas maneras. Por ejemplo, si se utilizan para entrenar algoritmos de aprendizaje automático, esos algoritmos pueden automatizar tareas, identificar patrones y hacer predicciones.

Se trata de un recurso poderoso con un efecto transformador en la sociedad. Así como el uso generalizado del petróleo impulsó el crecimiento de las industrias y permitió el desarrollo de nuevas tecnologías, los datos han dado lugar a avances en campos como la inteligencia artificial, el aprendizaje automático y la analítica predictiva.

Debido a todos estos factores, los datos también pueden ser una fuente de poder e influencia.

Por ejemplo, con big data se pueden generar informes y paneles que indiquen dónde están bajando las ventas, y tomar medidas “después del hecho” para mejorar esas ventas. También es posible usar el aprendizaje automático para predecir dónde disminuirán las ventas en el futuro y tomar medidas proactivas para evitar esa caída. A esto se le llama inteligencia empresarial (Business Intelligence, BI): el proceso de recopilar, analizar y utilizar datos para ayudar a las empresas a tomar decisiones más informadas.

En los útimos años se escucha bastante el término "transformación digital" en la industria de TI. Hace referencia a cómo las empresas integran tecnologías en todas sus áreas para generar un cambio fundamental en la forma en que extraen valor de los datos, operan y entregan valor a sus clientes. Esta transformación digital puede dividirse en cuatro etapas, conocidas como las fases de madurez de los datos empresariales:

Una base de datos relacional almacena datos de manera estructurada, con relaciones entre los elementos de datos definidas mediante claves. Los datos suelen organizarse en tablas, donde cada tabla se compone de filas y columnas. Cada fila representa una instancia específica de los datos, mientras que cada columna representa un atributo particular de esos datos.

Las bases de datos relacionales están diseñadas para manejar datos estructurados y proporcionan un marco para crear, modificar y consultar los datos utilizando un lenguaje estandarizado conocido como SQL (Structured Query Language). El modelo relacional fue propuesto por primera vez por Edgar F. Codd en 1970, y desde mediados de los años 70 se ha convertido en el modelo dominante para los sistemas de gestión de bases de datos. La mayoría de las aplicaciones operacionales necesitan almacenar datos de manera permanente, y una base de datos relacional es la herramienta preferida por una gran mayoría para esta tarea.

Los datos de las fuentes de datos operacionales se copian en un almacén de datos (data warehouse), lo que permite a los usuarios ejecutar consultas e informes contra el almacén de datos en lugar de hacerlo directamente sobre las fuentes de datos. De esta manera, no se sobrecarga los sistemas que albergan las fuentes originales, evitando la ralentización de las aplicaciones para los usuarios finales. Los almacenes de datos relacionales (RDWs) también centralizan datos de múltiples aplicaciones para mejorar la generación de informes.

Puedes pensar en un data lake como un sistema de archivos vitaminado, no muy diferente al sistema de archivos en tu computadora portátil. Un data lake es simplemente un almacenamiento; a diferencia de un almacén de datos relacional, no tiene un motor de cómputo asociado. Otra diferencia es que, mientras los RDWs utilizan almacenamiento relacional, los data lakes emplean almacenamiento de objetos, que no requiere que los datos estén estructurados en filas y columnas.

La tecnología de almacenamiento en data lakes comenzó con el Apache Hadoop Distributed File System (HDFS), una tecnología gratuita y de código abierto que estaba casi exclusivamente en instalaciones locales y que fue muy popular a principios de la década de 2010. HDFS es un sistema de almacenamiento distribuido escalable y tolerante a fallos diseñado para ejecutarse en hardware estándar. Es un componente central del ecosistema Apache Hadoop.

Los datos en un data lake se almacenan en su formato natural (o bruto), lo que significa que pueden ir desde el sistema fuente al data lake sin ser transformados a otro formato. Estos archivos pueden contener datos estructurados (como datos de bases de datos relacionales), semi-estructurados (como archivos CSV, registros, XML o JSON) o no estructurados (como correos electrónicos, documentos y PDFs). También pueden incluir datos binarios (como imágenes, audio y video).

Los data lakes surgieron como la solución a todos los problemas asociados con los almacenes de datos relacionales, como el alto costo, la escalabilidad limitada, el bajo rendimiento, la sobrecarga en la preparación de datos y el soporte limitado para tipos de datos complejos. Empresas que vendían Hadoop y data lakes, como Cloudera, Hortonworks y MapR, los promocionaron como si estuvieran llenos de unicornios y arcoíris que copiarían y limpiarían datos, haciéndolos disponibles para los usuarios finales con facilidad mágica. Aseguraban que los data lakes podrían reemplazar completamente a los almacenes de datos relacionales, adoptando un enfoque de "una tecnología para hacerlo todo".

El problema era que consultar los data lakes no era tan sencillo: requería habilidades bastante avanzadas. El personal de TI les decía a los usuarios finales: "Hemos copiado todos los datos que necesitas en este data lake. Solo abre un cuaderno de Jupyter y usa Hive y Python para construir tus informes con los archivos en estas carpetas."

Además, los data lakes no contaban con algunas de las características que la gente valoraba en los almacenes de datos, como el soporte de transacciones, la aplicación de esquemas y las trazas de auditoría. Esto llevó a que dos de los tres principales proveedores de data lakes, Hortonworks y MapR, cerraran sus puertas.

Pero el data lake no desapareció. En lugar de eso, su propósito se transformó en uno diferente, pero muy útil: la preparación y el almacenamiento temporal de datos.

Los data lakes no lograron reemplazar completamente a los almacenes de datos relacionales, pero sí ofrecen beneficios para la preparación y el almacenamiento temporal de datos. ¿Por qué no aprovechar las ventajas de ambos?

Alrededor de 2011, muchas empresas comenzaron a construir arquitecturas que combinaban data lakes con almacenes de datos relacionales, formando la arquitectura de datos que ahora llamamos el almacén de datos moderno (MDW, por sus siglas en inglés). Esta combinación permite aprovechar los beneficios de ambos enfoques:

Al integrar ambos, el almacén de datos moderno (MDW) combina la capacidad de los data lakes para manejar datos en su formato bruto y la robustez de los almacenes de datos relacionales para realizar análisis complejos y mantener la calidad y la integridad de los datos. Esto permite una solución más completa y flexible para el almacenamiento y análisis de datos.

Las fábricas de datos comenzaron a aparecer alrededor de 2016. La arquitectura de una fábrica de datos se puede considerar como una evolución de la arquitectura del almacén de datos moderno, con tecnología adicional para captar más datos, asegurar su integridad y hacerlos disponibles de manera más eficiente.

Una fábrica de datos integra y orquesta datos a través de múltiples entornos y plataformas, proporcionando una capa unificada de gestión de datos que abarca tanto datos estructurados como no estructurados. Esta arquitectura permite una mejor visibilidad, gobernanza y accesibilidad de los datos a lo largo de toda la organización, facilitando la integración de datos provenientes de diversas fuentes y la aplicación de políticas de seguridad y privacidad en un entorno cada vez más complejo.

El término data lakehouse es una combinación de data lake y data warehouse. Las arquitecturas de data lakehouse se hicieron populares alrededor de 2020, cuando la empresa Databricks comenzó a utilizar este término. El concepto de un lakehouse es eliminar el almacén de datos relacional y usar solo un repositorio, un data lake, en la arquitectura de datos. Todos los tipos de datos—estructurados, semi-estructurados y no estructurados—se ingieren en el data lake, y todas las consultas e informes se realizan directamente desde el data lake.

Pero si dijimos que los data lakes adoptaron este mismo enfoque cuando aparecieron por primera vez, ¡y fracasaron estrepitosamente! ¿Qué ha cambiado? La respuesta es una capa de software de almacenamiento transaccional llamada Delta Lake que se ejecuta sobre un data lake existente y hace que funcione de manera más parecida a una base de datos relacional. Las opciones de código abierto que compiten en esta capa incluyen Delta Lake, Apache Iceberg y Apache Hudi.

Las arquitecturas de almacén de datos moderno, fábrica de datos y data lakehouse implican la centralización de datos: copiar los datos operacionales en una ubicación centralizada propiedad de TI bajo una arquitectura que TI controla, donde TI luego crea los datos analíticos (lado izquierdo de la figura). Este enfoque centralizado presenta tres desafíos principales: propiedad de los datos, calidad de los datos y escalabilidad organizacional/técnica. El objetivo del data mesh es resolver estos desafíos.

En un data mesh, los datos se mantienen dentro de varios dominios dentro de una empresa, como fabricación, ventas y proveedores (lado derecho de la figura). Cada dominio cuenta con su propio equipo de TI que es responsable de sus datos, los limpia, crea los datos analíticos y los pone a disposición. Cada dominio también tiene su propia infraestructura de computación y almacenamiento. Esto resulta en una arquitectura descentralizada donde los datos, las personas y la infraestructura se expanden—cuantos más dominios tienes, más personas e infraestructura obtienes. El sistema puede manejar más datos, y TI deja de ser un cuello de botella.

Es importante entender que el data mesh es un concepto, no una tecnología. No existe un "data mesh en una caja" que puedas comprar.

A continuación, se presenta un resumen comparativo de las arquitecturas de datos mencionadas:

Una de las tareas más importantes en la implementación de un almacén de datos es la población inicial del almacén con datos de las fuentes de datos operacionales. La población inicial implica extraer, transformar y cargar (ETL) los datos desde las fuentes de datos operacionales al almacén de datos. No obstante, los procesos de ETL también están presentes en la operación continua del almacén de datos, ya que los datos deben actualizarse regularmente para mantener la información actualizada. La población inicial y la operación continua del almacén de datos son procesos críticos que requieren una planificación cuidadosa y una ejecución precisa. A continuación se describen los pasos típicos en el proceso de población de un almacén de datos:

Veamos este caso de uso: Unos analistas de una gran cadena de tiendas querían captar datos de Twitter para entender qué pensaban los clientes sobre sus tiendas. Sabían que los clientes podrían dudar en presentar quejas a los empleados de la tienda, pero estarían dispuestos a publicarlas en Twitter. Con la ingesta de datos de Twitter en un data lake y la evaluación del sentimiento de los comentarios de los clientes, categorizándolos como positivos, neutros o negativos, los analistas pudieron identificar problemas en las tiendas y tomar medidas correctivas. Al revisar los comentarios negativos, encontraron un número inusualmente alto de quejas sobre los probadores: eran demasiado pequeños, estaban demasiado llenos y no ofrecían suficiente privacidad. Como experimento, la empresa decidió remodelar los probadores en una tienda. Un mes después de la remodelación, los analistas encontraron un gran número de comentarios positivos sobre los probadores en esa tienda, junto con un aumento del 7% en las ventas. Esto llevó a la empresa a remodelar los probadores en todas sus tiendas, resultando en un aumento del 6% en las ventas a nivel nacional y millones de dólares adicionales en ganancias. ¡Todo gracias a un data lake!

Un data lake generalmente no impone una estructura específica a los datos que ingiere. De hecho, esta es una de sus características clave (ver Schema on write vs. schema on read en la sección Bases de datos relacionales). Esto es diferente de una base de datos tradicional o un almacén de datos, que requiere que los datos estén estructurados o modelados previamente. Sin embargo, para que los datos sean utilizables y evitar que el data lake se convierta en un “pantano de datos” (una colección desorganizada e inmanejable de datos), es importante aplicar algunas prácticas de organización y gobernanza. Esta sección presenta algunas buenas prácticas para empezar:

Estas prácticas ayudan a asegurar que el data lake se mantenga organizado y útil, evitando que se convierta en una acumulación desordenada de datos que sea difícil de gestionar y utilizar.

Un catálogo de datos es un repositorio centralizado, típicamente alojado en la nube, que almacena y organiza metadatos sobre todas las fuentes de datos, tablas, esquemas, columnas y otros activos de datos de una organización, como informes y dashboards, procesos ETL y scripts SQL. Funciona como una única fuente de verdad para que los usuarios descubran, comprendan y gestionen datos almacenados en bases de datos de aplicaciones, lagos de datos, almacenes de datos, data marts y cualquier otra forma de almacenamiento de datos.

Un catálogo de datos típicamente incluye la siguiente información sobre cada activo de datos:

Delta Lake es una capa de almacenamiento transaccional diseñada para ejecutarse sobre un data lake existente, aportando características avanzadas que normalmente se asocian con los almacenes de datos relacionales (RDW) al mundo de los data lakes. A diferencia de un RDW, Delta Lake no proporciona almacenamiento en sí; en cambio, mejora la funcionalidad del data lake subyacente al introducir características que optimizan la confiabilidad, seguridad y rendimiento de los datos.

Cada una de estas herramientas (Delta Lake, Apache Iceberg y Apache Hudi) ofrece ventajas únicas y puede ser elegida en función del caso de uso y requisitos. Juntas, representan una evolución significativa en la tecnología de data lakes, combinando la flexibilidad de los data lakes con las capacidades robustas tradicionalmente asociadas con los RDWs.

Delta Lake introduce una serie de características inspiradas en los almacenes de datos relacionales (RDW) para mejorar la funcionalidad y el manejo de datos en los data lakes. A continuación, se detallan algunas de las principales características que ofrece Delta Lake:

Estas características permiten que Delta Lake combine la flexibilidad de los data lakes con capacidades avanzadas de gestión de datos, ofreciendo una solución robusta para la manipulación y el análisis de grandes volúmenes de datos.

A pesar de las avanzadas características que Delta Lake añade a los data lakes, hay algunas áreas en las que los almacenes de datos relacionales (RDW) todavía pueden superar a Delta Lake. Aquí se detallan algunas de las principales diferencias:

Estas diferencias destacan que, aunque Delta Lake ofrece muchas ventajas en términos de flexibilidad y capacidad de manejo de datos, los RDWs aún mantienen ciertas ventajas en términos de rendimiento de consulta y características de seguridad avanzadas.