#data bricks

1. Introducción, historia de warehouses y problemáticas actuales:

Este paper pretende abrir el debate sobre las arquitecturas de data warehousing, e inicia diciendo que la arquitectura tal y como la conocemos hoy ira declinando en popularidad en los próximos años y será gradualmente reemplazada por otro patrón de arquitectura que conocemos como Lakehouse.

La primera generación de plataformas analíticas de datos eran bases de datos centralizadas, optimizadas para su uso en BI (Business Intelligence). Hace una década empezaron a tener 2 tipos de problemas:

El poder de cómputo y el almacenamiento estaban ligados entre sí, en un dispositivo on-premise (es decir, en una infraestructura local). A medida que los datasets se volvían más grandes y la cantidad de usuarios aumentaba, los costos se volvían demasiado grandes también.

No solo los datasets crecían, sino que también aparecieron nuevas formas de datos completamente no-estructuradas (video, audio, documentos de texto, etc.) que los data warehouses no podían almacenar ni consultar.

Para resolver estos problemas vino la segunda generación de plataformas analíticas, que empezaron a almacenar la data cruda (raw) en data lakes, sea esta estructurada o no. El bajo costo de almacenamiento, simplicidad para accederlos y formatos de archivos de código abiertos (por ej. Parquet) los hace ideales para esta tarea. Esto empezó con Apache Hadoop, usando su File System (HDFS) que permitía usar comodity hardware en entornos on-premise y luego fue gradualmente reemplazado por los data lakes en la nube, superiores por ofrecer todavía mejor precio, bajo costo de mantenimiento y geo replicación. El uso de data lakes permitió desacoplar el almacenamiento de los datos (en data lakes) del procesamiento de los mismos (Redshift, Synapse, Snowflake, etc.).

Lo mencionado anteriormente nos trae a los desafíos que presenta esta segunda generación, ya que la información tiene que pasar por un proceso de ETL hacia el data lake para luego tener otro proceso de ELT hacia el data warehouse, creando más complejidad, demoras y nuevos potenciales puntos de falla. Sumado a esto, nuevos casos de uso para analítica avanzada como Machine Learning no son soportados de forma ideal. Para ser más específicos, hay 4 problemas principales con las arquitecturas actuales:

Fiabilidad: mantener el data lake y el warehouse consistentes entre si es difícil, costoso y requiere mantenimiento constante para disponibilizar la data rápido para los sistemas de BI.

Data no actualizada: la data en un warehouse tiende a quedar vieja (a veces lleva días actualizar) comparada con el data lake.

Soporte limitado para analítica avanzada: ninguno de los sistemas de Machine Learning líderes como TensorFlow, PyTorch o XGBoost soportan trabajar sobre warehouses. La mayoría recomiendan exportar la data como archivos al data lake (agregando un tercer ETL, e incrementando los dos primeros problemas).

Costo total: además del costo por el ETL continuo, los usuarios pagan doble por el almacenamiento de la data en data lake y en warehouse.

El momento ideal para hacer la transición hacia un Lakehouse es este, ya que recientemente se desarrollaron nuevas soluciones que intentan atacar los siguientes problemas:

Administración fiable de data en data lakes: un lake necesita almacenar raw data, pero también dar soporte a procesos ETL que limpien la data para mejorar su calidad para análisis sin perder características clave como transacciones, rollbacks o clones de copia cero. Librerías como Delta Lake o Apache Iceberg ofrecen estas características.

Soporte para Machine Learning y ciencia de datos: muchos sistemas soportan la lectura directa desde data lakes y esto los hace eficientes para trabajar con Lakehouse, y se benefician de forma directa con las optimizaciones que se incluyan en estos.

SQL Performance: Lakehouse tiene que proveer buena performance en SQL corriendo sobre datasets Parquet/ORC grandes, y es un desafío ya que no posee las facilidades de optimización que tienen los warehouse clásicos (indexación, por ejemplo). Sin embargo, se presentan algunas técnicas que se pueden implementar para mejorar esto con repositorios de metadata y particionado de la data en estos formatos para mejorar performance.

2. Pasos hacia Lakehouse:

Muchas tendencias de la industria dan evidencia de que los clientes no están 100% satisfechos con el modelo de separación entre data lake y warehouse.

En los últimos años los data warehouse lideres han agregado soporte para tablas externas en formato Parquet y ORC, esto permite consultarlos usando el mismo motor SQL, pero no simplifica su administración, ni reduce la complejidad en los ETL. Además, estos conectores suelen tener mala performance comparado con data interna de los warehouse.

También se están haciendo grandes inversiones en motores SQL que corran directamente sobre el almacenamiento en data lakes (como Spark SQL, Presto, Hive, etc), pero incluso estos están faltantes de features básicas como transacciones ACID (atomicidad, consistencia [integridad], aislamiento y durabilidad [persistencia], por sus siglas en inglés) o métodos de acceso eficientes como índices.

3. La arquitectura Lakehouse:

Se define la arquitectura Lakehouse como un sistema de administración de datos, basado en almacenamiento de bajo costo y directamente accesible que provee features de administración y rendimiento como las bases de datos tradicionales, tales como transacciones ACID, versionado de datos, auditoria, índices, cache y optimización de consultas.

A continuación, se habla sobre una posible forma de implementar un Lakehouse basado en tres ideas técnicas que aparecieron en la industria: Delta Lake, Delta Engine y Databricks ML Runtime.

3.1 Implementando un Lakehouse:

La primera idea clave es permitir que el sistema use como almacenamiento un data lake (Azure Data Lake, S3, etc) usando formatos de archivos estándar como Apache Parquet, pero con una capa de metadatos transaccionales para permitir transacciones ACID, versionado, etc. Delta Lake y Apache Iceberg actualmente permiten lograr esto, pero con la contra de que no son suficiente para lograr una buena performance en cuanto a consultas SQL. Si bien se pueden utilizar discos de estado sólido, índices para archivos y mantener estadísticas, en un Lakehouse podemos implementar otras optimizaciones tales como cache, estructuras de datos auxiliares como índices y estadísticas (enfocado en tablas, no archivos) y optimizaciones en cuanto a la clusterizacion de la data.

Un aspecto importante es que un Lakehouse ayuda muchísimo a que las principales librerías de machine learning puedan acceder al dato gracias a la implementación de DataFrame APIs, que permiten obtener Dataframes (al estilo R o Pandas en el caso de Python) para hacer transformaciones y cálculos. Una ventaja de estas APIs es que manejan Lazy evaluation (es decir que las operaciones no se ejecutan una a una, sino que se acumulan y se ejecutan todas juntas), y esto permite hacerlas pasar por un optimizador antes de su ejecución real.

3.2 Capas de metadata para administración:

La capa de metadatos debería elevar el nivel de abstracción en el almacenamiento de los data lakes al punto de poder ofrecer transacciones ACID y otras features clásicas de los DBMS. Features como hacer update a un documento de texto no son nativas de los data lake, ni de ningún sistema basado en HDFS. Por esta razón es que Databricks empezó en 2016 el desarrollo de Delta Lake, que guarda información acerca de los objetos que forman parte de una tabla en el mismo data lake, en la forma de un log de transacciones en formato Parquet, lo que le permite escalar a billones de objetos por tabla. Otras librerías que intentar lograr algo similar son Apache Iceberg (nacida en Netflix) o Apache Hudi (nacida en Uber, enfocada en streaming).

La experiencia y los tests muestran que estas librerías logran performance similares o mejores comparados con la lectura directa de archivos Parquet/ORC, al tiempo que ofrecen features como transacciones, viaje entre versiones (time travel) o clones de copia cero (clonar una tabla sin duplicar la data en otro lugar).

Esta capa de metadatos además controla el esquema de las tablas antes de escribirlos (cosa que no pasa al escribir solo archivos Parquet), y permiten definir restricciones a valores particulares para evitar que entre basura en nuestras tablas.

Por último, en estas capas es donde mejor se pueden implementar features de Governance tales como control de acceso o logs de auditoria.

Para pensar en el futuro: las capas de metadata son algo nuevo, y por el momento almacenan los logs de transacciones en el mismo data lake, pero no es ideal ya que estos están diseñados para devolver grandes volúmenes de datos, y estas capas son pequeñas en datos por lo que podría preferirse almacenar la capa de metadata en otro sistema con menos latencia.

3.3 Performance de SQL en el Lakehouse:

Uno de los mayores desafíos técnicos es proveer de buena performance en SQL. Se proponen a continuación optimizaciones que no dependen del formato de archivo, para hacerlas así aplicables a todos.

3.3.1 Cache:

Cuando se consultan los datos usando capas de metadatos, lo mejor es almacenar en cache algunos archivos clave en almacenamientos más rápidos tales como discos de estado sólido en la nube, o en la misma memoria RAM de los nodos de procesamiento. Las transacciones nos ayudan a saber cuándo un cache es válido o cuando hay que descartarlo, y podemos cambiar el formato subyacente al guardarlo como cache para hacerlo aún más rápido. Como ejemplo, el cache en Databricks descomprime parcialmente los archivos Parquet que carga.

3.3.2 Data Auxiliar:

Estadísticas tales como valores maximos-minimos para ciertas columnas, permiten saltear filas que no coinciden con nuestro criterio de búsqueda y agilizar consultas. Esta data auxiliar también incluye índices que pueden ayudar con este propósito.

3.3.3 Distribución de data:

La distribución en la cual están guardados los datos influye mucho en la performance, por ejemplo, si guardamos en un mismo sector datos que nos interesa leer siempre juntos su performance mejora al ser más simple de leer para el data lake.

Estas 3 optimizaciones funcionan bien cuando están aplicadas juntas, ya que las cargas de trabajo típicas tienden a estar enfocadas en un subset de la información y no en toda.

Resultados de rendimiento: en Databricks se combinan estas 3 optimizaciones con un nuevo motor de ejecución en C++ para Apache Spark llamado Delta Engine. El estudio llevado a cabo indica que hace un uso más eficiente del dinero (es más barato), mientras ofrece una performance similar o mejor.

Dirección para el futuro y diseños alternativos: Una alternativa que aún no se exploro es diseñar nuevos tipos de archivos para almacenar la información que favorezcan el caso de uso de Lakehouse. Otra dirección para la investigación es determinar cuándo y como usar servicios serverless para responder consultas (como AWS Athena).

3.4 Acceso eficiente para analítica avanzada:

Como se discutió antes en este paper, las librerías de analítica avanzada están usualmente escritas en código imperativo que no puede correr como SQL, y necesitan consumir grandes cantidades de datos. Una de las incógnitas más grandes es de qué forma se puede diseñar el acceso a la data para beneficiarse de las optimizaciones que ofrece un Lakehouse. En este punto se tuvo bastante éxito usando DataFrame APIs en estas librerías, que simplifica llevar la data a Spark SQL y beneficiarse de los query planner y demás optimizaciones. Se uso este enfoque en Spark DataFrames y en Koalas (que ofrece más compatibilidad con Pandas).

En el futuro se tendrá que desarrollar para nuevas formas de lectura, y para aquellas librerías que se enfocan en procesamiento en GPUs (tarjetas gráficas).

Dirección para el futuro y diseños alternativos: aún falta por explorar diseños completamente diferentes para acceder data para machine learning. Si bien se pueden hacer mejoras en la forma de procesar y acceder la data, no hay que dejar de lado que los científicos de datos necesitan librerías estándar para beneficiarse de las ventajas ofrecidas por Lakehouse.

4. Preguntas de investigación e implicancias:

¿Hay otras formas de lograr los objetivos de Lakehouse? Uno se podría imaginar que los objetivos se pueden lograr creando una capa que exponga la data y permita lecturas en paralelo. Sin embargo, esa infraestructura seria más costosa, difícil de administrar y casi con seguridad menos performante que leer directamente desde el almacenamiento. Un intento de esta implementación se hizo con Hive LLAP. Además de las contras mencionadas, la gobernanza de datos nos da razones más que suficientes para almacenar su data en formatos abiertos, para cumplir con regulaciones, auditorias y estandarizar el acceso a la misma.

¿Cuáles son los formatos de almacenamiento y las apis de acceso correctos? La interfaz de acceso al Lakehouse debe incluir librerías para leer el formato crudo (raw) y una interfaz de alto nivel SQL. Aun está por verse que combinación de formato de archivo, capa de metadatos y API de acceso es la que mejor funciona.

¿Como afecta el Lakehouse otras investigaciones y tendencias sobre administración de datos? La prevalencia de data lakes y el creciente uso de interfaces de administración sobre ellos tiene implicancias en otras áreas:

Los Polystores fueron diseñados para atacar el problema de consultar data entre diferentes motores de almacenamiento.

Herramientas de integración y limpieza de datos podrían diseñarse para correr directamente sobre el Lakehouse paralelizando el acceso con múltiples joins y algoritmos de clusterizacion.

Sistemas de procesamiento hibrido transaccional/analítico (HTAP) podrían ser creados sobre el Lakehouse haciendo uso de las APIs de transacciones.

El manejo de data para Machine Learning se podría volver mucho más simple y potente si se implementa directamente sobre Lakehouse.

Se pueden diseñar DBMS nativos de nube (como los motores serverless) para integrarse con las capas de metadata enriquecida en lugar de escanear directamente sobre la data cruda en el data lake.

Últimamente se está hablando del concepto de "data mesh" en el cual diferentes equipos tienen el control inicio-a-fin y son dueños de procesos y productos de data. Este concepto está ganando popularidad sobre el enfoque de tener un equipo centralizado de data.

5. Trabajos relacionados:

Los sistemas más relacionados son "nativos de nube". Data warehouses asentados sobre un almacenamiento separado (data lake) como Apache Hive.

También los warehouse nativos de nube como Snowflake y BigQuery han tenido éxito comercial, pero siguen sin ser el principal almacén de data en las organizaciones (siguen teniendo todo en data lakes). Como resultado de esto, tienen opciones para leer tablas externas e interfaces para distintos tipos de archivos, pero siguen sin ofrecer las mismas características que ofrecen para las tablas internas (como transacciones ACID). Como se discutió anteriormente, tampoco son el formato óptimo para analítica avanzada.

6. Conclusión:

Hemos visto como una plataforma unificada de datos que implemente funcionalidades de data warehouse sobre archivos de formato abierto puede proveer de rendimientos competitivos sobre los data warehouse de hoy, e intentamos dar respuesta a los desafíos que surgen con esta propuesta, tales como la falta de optimización en el acceso a datos. Creemos que la industria va a converger a un formato de Lakehouse en el futuro por la cantidad de data que manejan las organizaciones, la infinidad de casos de uso que nos ofrece, y por como simplifica las arquitecturas de datos.

Escrito por Martin Zurita

Twitter