La arquitectura Delta está ganando popularidad y defensores en el mundo del Big Data. La principal razón: ofrece más simplicidad, calidad, confiabilidad y transacciones con cumplimiento de ACID si se compara con otras opciones, como las arquitecturas Lambda o Kappa.
Como señala Denny Lee, Developer Advocate en Databricks, el sueño de un ingeniero de datos es “procesarlos de forma continua e incremental a medida que llegan nuevos datos, de una manera rentable, sin tener que elegir entre lotes o streaming”. Y la arquitectura Delta promete acercar a los ingenieros a este sueño.
En un artículo previo, discutimos las diferencias entre las arquitecturas Lambda vs. Kappa. Sin embargo, ahora es el momento de entender mejor cómo la arquitectura Delta puede ser una evolución para la gestión de datos.
La arquitectura Lambda, una vieja amiga
Al inicio de la década de 2010, el procesamiento de datos en tiempo real, especialmente en enormes cantidades, seguía siendo un problema. La latencia, la complejidad y la falta de herramientas aptas para construir un sistema de Big Data fueron algunos de los problemas señalados por Nathan Marz en ese momento. En este contexto, Marz propuso la arquitectura Lambda. Su propuesta trató de resolver este problema con un enfoque híbrido, “al descomponer el problema en tres capas: la capa por lotes (batch layer), la capa de servicio (serving layer) y la capa de velocidad (capa de streaming o speed layer)”.
En esta arquitectura, la capa por lotes puede demorar para procesar toneladas de datos que requieren mucho tiempo de cálculo (ruta fría, o cold path). Por su parte, la capa de velocidad calcula en tiempo real y realiza actualizaciones incrementales a los resultados de la capa por lotes (ruta caliente, o hot path). Finalmente, la capa de servicio toma los outputs de ambos y utiliza estos datos para resolver consultas pendientes. Además, “cuenta con una fuente de datos inmutable a la que solo se le pueden agregar inputs, que sirve como un sistema de registro. Los eventos con marca de tiempo (timestamped events) se agregan a los eventos existentes y nada se sobrescribe”, como refiere esta publicación.
Sin embargo, la complejidad siempre ha sido una desventaja de la arquitectura Lambda. “Si bien puede manejar enormes volúmenes de datos, aumenta la complejidad al requerir diferentes bases de código para los datos por lotes y los datos en tiempo real. Además hay una tendencia a causar pérdida y corrupción de datos. En respuesta a estos problemas de confiabilidad de los datos, la arquitectura tradicional se complejiza aún más al agregar pasos como la validación, el reprocesamiento para fallas, así como la actualización y fusión manual”, dice Héctor Leno en este artículo.
La arquitectura Kappa, una alternativa
Poco después, la arquitectura Kappa apareció como una alternativa. Está basada en eventos y no separa las capas. La arquitectura Kappa solo tiene la capa de transmisión (streaming layer) y la capa de servicio (serving layer). De esta manera, todos los tipos de datos que deben procesarse son gestionados por un único stack de tecnología.
La propuesta de Kappa representó una evolución del procesamiento y análisis de datos. De cualquier forma, tiene un alto nivel de complejidad para la implementación y hace un uso extensivo de recursos informáticos. Además, es difícil de escalar.
Arquitectura Delta, un nuevo enfoque
Actualmente, la arquitectura Delta parece ser el siguiente paso para el procesamiento de datos. Pero primero, es mejor familiarizarse con el concepto Delta Lake, ya que la arquitectura Delta se basa en ello. Delta Lake, como explicamos anteriormente, es un framework de almacenamiento de código abierto que brinda soporte para transacciones, con cumplimiento de los principios ACID, así como aplicación de esquemas a data lakes a través del uso de Apache Spark. Esto permite a los usuarios construir una arquitectura “Data Lakehouse” que funciona con datos estructurados, semiestructurados y no estructurados.
Delta Lake “amplía los archivos de datos Parquet con un registro de transacciones basado en archivos para transacciones ACID y manejo escalable de metadatos”. También es compatible con las API de Apache Spark e integrado con Structured Streaming. Además, la separación entre capas en la arquitectura Delta es mínima en comparación con la arquitectura Lambda, por lo que no hay necesidad de tratar los datos de manera diferente en función de su origen.
Dentro de este contexto, Databricks presenta a Delta como “un enfoque completamente diferente para ingerir, procesar, almacenar y administrar datos basado en la simplicidad. Todo el procesamiento y enriquecimiento de datos desde las tablas Bronce (datos brutos) hasta las tablas Plata (filtrados) y luego hasta las tablas Oro (completamente listos para ser utilizados por análisis, informes y ciencia de datos) ocurre dentro de Delta Lake, lo que requiere menos data hops“.
Las promesas de la arquitectura Delta
- Reducción de costos: su simplicidad ayuda a reducir costos significativamente al reducir la cantidad de datos que deben enviarse y recibirse, el tiempo necesario para procesar los datos, así como la cantidad de veces que necesita ejecutar trabajos debido a fallas.
- Delta = Menos código: como ya mencionamos, la arquitectura Lambda necesita diferentes bases de código para cada parte del procesamiento. Al usar Delta, como las transacciones cumplen con los principios ACID, garantiza que el código sea menos complejo porque varias partes del código que debían hacerse manualmente (para garantizar la coherencia de los datos, por ejemplo) ya no son necesarias.
- Indexación mejorada: cuando se usa Delta Lake como almacenamiento para tu arquitectura, se pueden usar Bloom Filter Indexes, que mejoran el rendimiento de ejecución de consultas en más del 50%, según MSSQLTips.com.
- Una sola fuente de datos: al usar otras arquitecturas y tratar de simplificar los procesos, los datos a menudo se copian de un data lake a otros depósitos de datos más pequeños. Esto crea problemas de consistencia y versionamiento que se resuelven mediante el uso de la arquitectura Delta.
- ¿Agregar más fuentes de datos? Sin problema: por lo general, después de que se diseña e implementa una arquitectura de datos para un caso de uso específico, es difícil agregar nuevas fuentes de datos. Al usar Delta Lake como motor, esto no presenta un enorme desafío ya que la evolución del esquema hace que agregar nuevas fuentes de datos (o cambiar los formatos de las fuentes de datos existentes) sea una tarea más simple.
Resumen
En un mundo cada vez más impulsado por los datos, el desarrollo de una solución robusta que sea capaz de escalar y manejar cualquier cantidad o tipo de datos, ha sido el mayor desafío en los últimos años. En este tiempo, propuestas como las arquitecturas Lambda y Kappa han surgido como respuesta a esta necesidad. Sin embargo, todavía están lejos de ser ideales.
“Ha habido intentos de unificar lotes y streaming en un solo sistema en el pasado. Sin embargo, las organizaciones no han tenido tanto éxito en esos intentos. Pero, con la llegada de Delta Lake, estamos viendo que muchos de nuestros clientes adoptan un modelo de flujo de datos continuo simple para procesar los datos a medida que llegan. Llamamos a esta arquitectura, la arquitectura Delta”, explica Databricks, la compañía detrás de ella.“Al usar este enfoque, podemos mejorar nuestros datos a través de una canalización conectada que nos permite combinar flujos de trabajo de datos en vivo y por lotes a través de un almacén de archivos compartido, con transacciones con ACID, y proporcionar lo mejor de ambos mundos”, complementa este análisis.