De los warehouse a los lakehouse: El futuro de la arquitectura de datos

Los datos son el corazón de las organizaciones modernas. Desde los dashboards empresariales hasta los modelos de inteligencia artificial, son la base de cualquier iniciativa digital. Pero incluso hoy en día, la forma en que almacenamos, accedemos y procesamos los datos sigue siendo más complicada de lo que debería.

Este blog basado en el articulo de CIDR 2017 Lakehouse: A New Generation of Open Platforms that Unify
Data Warehousing and Advanced Analytics presenta el Lakehouse: una nueva y potente arquitectura de datos que está ganando adeptos en todos los sectores. Está diseñada para resolver las deficiencias de los sistemas actuales combinando las mejores características de los data warehouses y los data lakes de datos en una plataforma unificada.

Pero primero, rebobinemos un momento…

La era de los data warehouses

En los inicios del análisis de datos, las empresas invertían en data warehouses, sistemas centralizados diseñados para almacenar datos estructurados y ejecutar consultas analíticas complejas. Estos sistemas eran excelentes para las herramientas de inteligencia empresarial (BI), ya que permitían a las organizaciones crear informes y cuadros de mando a partir de datos relacionales perfectamente organizados.

Los data warehouses contaban con varios puntos fuertes importantes:

• Alto rendimiento de las consultas: Los almacenes se crearon para realizar análisis SQL rápidos. Sus motores de consulta están optimizados para escanear grandes volúmenes de datos estructurados de forma eficiente.

• Inserciones y actualizaciones eficientes: Aunque los almacenes están altamente optimizados para cargas de trabajo OLAP, estos sistemas utilizan motores de almacenamiento optimizados que permiten actualizaciones, inserciones e indexaciones rápidas y consistentes.

• Garantías ACID: Quizás lo más importante es que los almacenes admiten transacciones ACID, lo que significa que las operaciones de datos son Atómicas, Consistentes, Aisladas y Duraderas. Esto garantizaba la fiabilidad de los datos, incluso ante actualizaciones simultáneas o fallos del sistema.

A pesar de sus ventajas, los almacenes tenían serias limitaciones, sobre todo en cuanto a costes y flexibilidad. Una de las principales razones es que vinculaban la computación y el almacenamiento. Esto significaba que los almacenes asignaban por adelantado tanto la potencia de cálculo como la capacidad de almacenamiento, independientemente del uso real. Incluso si nadie ejecutaba consultas, el sistema seguía incurriendo en costes de recursos. Peor aún, si se quería ampliar o reducir el sistema, no se podía añadir más capacidad de cálculo o de almacenamiento de forma independiente, sino que había que hacer ambas cosas a la vez.

Algunos sistemas de data warehouse conocidos son Snowflake, Google BigQuery, Amazon Redshift y Teradata…

A medida que aumentaban los volúmenes de datos y se diversificaban los tipos de datos, se hicieron más evidentes las limitaciones de los almacenes de datos tradicionales, especialmente su elevado coste, sus rígidos requisitos de esquema y su escasa escalabilidad.

Esto condujo a la aparición de un nuevo paradigma: el Data Lake. Los data lakes se diseñaron para resolver muchos de los problemas asociados a los data warehouses, especialmente en cuanto a costes y escalabilidad.

• Separación de computación y almacenamiento: A diferencia de los almacenes tradicionales, los data lakes desvinculan la computación del almacenamiento. Pueden almacenar cantidades masivas de datos a bajo coste (a menudo en almacenamiento de objetos en la nube como Amazon S3, Azure Data Lake Storage o Google Cloud Storage) y sólo pagar por la computación cuando realmente ejecute consultas o trabajos de procesamiento.

• Escalabilidad masiva: Dado que la capa de almacenamiento es nativa de la nube y distribuida, los data lakes pueden escalar casi infinitamente. No tiene que preocuparse por aprovisionar servidores o quedarse sin espacio.

• Los data lakes permiten almacenar cualquier cosa: Esto hace que los data lakes se adapten mejor a las cargas de trabajo de ML emergentes, ya que pueden almacenar y procesar grandes volúmenes de datos estructurados, semiestructurados y no estructurados en formatos abiertos, lo que permite una extracción de características y una experimentación flexibles y a gran escala.

Sin embargo, los data lakes también tienen puntos débiles. En primer lugar, no incorporan optimización de consultas. Los data lakes almacenan los datos en archivos -a menudo en almacenes de objetos baratos- y dependen de motores externos como Apache Spark, Presto o Hive para procesarlos. Aunque estos motores pueden ser potentes, no tienen una visibilidad profunda de la disposición de los datos, lo que se traduce en un rendimiento de las consultas a menudo lento o impredecible. En segundo lugar, los data lakes carecen de funciones como las transacciones ACID, el control de versiones o la aplicación de esquemas. Esto significa que es fácil acabar con datos incoherentes o corruptos cuando varios trabajos leen y escriben simultáneamente. Sin controles estrictos, los esquemas incorrectos o en evolución pueden introducirse silenciosamente en el sistema, lo que dificulta el mantenimiento de canalizaciones fiables y aptas para la producción.

La mayoría de las organizaciones funcionan ahora con una arquitectura de datos de dos niveles: Los data lakes recopilan y almacenan todos los datos sin procesar, mientras que los data warehouse se utilizan para el análisis, una vez que los datos se extraen, se limpian y se transforman. Incluso con todas las herramientas y servicios nativos de la nube, las empresas todavía se encuentran con importantes impedimentos:

1. Fiabilidad y calidad de los datos

Cuando los datos se mueven entre varios sistemas (por ejemplo, lake → ETL → warehouse), aparecen errores e incoherencias. Un cambio de esquema aquí, un sutil desajuste de formato allá… y de repente sus informes no coinciden con sus datos de origen.

2. Datos obsoletos

Los datos de los warehouses suelen ir por detrás de los del data lake. Esto significa que su panel de control «en tiempo real» podría estar trabajando con datos de hace días. Para las empresas que dependen de información actualizada al minuto, como la detección de fraudes, la captación de clientes o la optimización de la cadena de suministro, esto supone un grave problema.

3. Las herramientas de aprendizaje automático como TensorFlow, PyTorch y XGBoost no están diseñadas para trabajar con warehouses.

Requieren un alto rendimiento y un acceso flexible a los datos, lo cual es difícil cuando los datos están encerrados en un motor SQL propietario. En su lugar, los científicos de datos a menudo se ven obligados a exportar los datos de nuevo a los archivos, creando más tuberías, más retrasos y más espacio para los errores.

4. Coste total elevado

Se paga por: Almacenamiento tanto en el lake como en el warehouse, herramientas ETL y pipelines, duplicación de datos y bloqueo de proveedores por formatos propietarios. Todo esto se acumula rápidamente.

Imagina un sistema que:

• Utiliza formatos abiertos como Parquet y ORC.

• Soporta cargas de trabajo de BI y de aprendizaje automático.

• Incorpora transacciones ACID, versionado de datos y optimizaciones de rendimiento.

• Elimina los procesos ETL redundantes.

• Ofrece una plataforma para gestionar datos estructurados, semiestructurados y no estructurados.

Eso es Lakehouse: la convergencia del data lake y el data warehouse en un único sistema unificado.

Entonces, ¿por qué el modelo Lakehouse sólo empieza a ser viable hoy en día?

Por tres grandes avances:

Capas de metadatos transaccionales

Los formatos de Lakehouse, Delta Lake, Apache Iceberg y Apache Hudi añaden funciones como las transacciones ACID y la aplicación de esquemas a los data lakes tradicionales. Estas capas actúan como el cerebro del sistema: gestionan las versiones de los archivos, el control de acceso, etc.

API preparadas para ML

Los frameworks modernos de ML ahora pueden leer de forma nativa desde formatos de archivo abiertos. Las nuevas API declarativas DataFrame permiten una optimización inteligente de las canalizaciones de datos, lo que permite tanto a los analistas como a los ingenieros de ML acceder a los mismos datos de alta calidad de forma eficiente.

Rendimiento

Los nuevos sistemas almacenan en caché los datos a los que se accede con más frecuencia, utilizan índices auxiliares y optimizan la disposición de los datos, todo ello sin cambiar el formato de archivo abierto.

¿Cuál es el resultado? Los data lakehouse pueden alcanzar ahora un rendimiento equiparable al de los data warehouse comerciales, manteniendo al mismo tiempo la flexibilidad, la apertura y la rentabilidad de los data lakes.

El data warehouse, pero está evolucionando. El modelo Lakehouse ofrece un camino prometedor, especialmente para las empresas que quieren hacer más con sus datos: más rápido, más inteligente y más barato. Si usted es un ingeniero de datos, un científico de datos o un líder de producto que busca preparar su pila para el futuro, merece la pena explorar Lakehouse.

En el próximo artículo, nos adentraremos en cómo funciona realmente un sistema Lakehouse bajo el capó y qué se necesita para construir uno.