El procesamiento y el análisis de datos desempeñan un papel clave en la toma de decisiones de las empresas. Sin embargo, estas tareas se realizan continuamente entre bastidores y elegir cómo comenzar a construir una infraestructura de datos adecuada para satisfacer las necesidades de tu negocio puede ser difícil.
ETL (extracting, transforming and loading data) es el proceso de extracción, transformación y carga de datos de diversas fuentes en sistemas de almacenamiento de datos o warehouses. Este proceso solía ser realizado por lotes, pero las arquitecturas modernas están evolucionando y ahora ocurre casi en tiempo real siempre que sea posible. Además de las capacidades de procesamiento casi en tiempo real, una infraestructura de datos moderna debe ser flexible, escalable, automatizada, elástica, extensible, así como capaz de soportar actualizaciones y nuevas aplicaciones.
En este contexto, las arquitecturas Kappa y Lambda pueden manejar conjuntos de datos (datasets) tanto en tiempo real (transmisión o streaming de datos) como estáticos (batch o por lotes), pero lo hacen de maneras muy diferentes.
Arquitectura Lambda
Nathan Marz, el primero en describir el paradigma Lambda, explicó que “calcular funciones arbitrarias en un conjunto de datos arbitrario en tiempo real es un problema intimidante. No hay una sola herramienta que proporcione una solución completa. En cambio, tienes que usar una variedad de herramientas y técnicas para construir un sistema completo de Big Data”. Para abordar este problema, las arquitecturas Lambda intentan resolver el problema de procesar ambos tipos de flujos de datos de manera híbrida, “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)”.
Cuando los datos alimentan el sistema, la capa batch y la capa de velocidad los reciben simultáneamente. Esto inicia el procesamiento y, luego, los datos del stream son corregidos en la capa batch. Sin embargo, cada capa tiene una tarea específica que completar.
Esto significa que la arquitectura Lambda separa el procesamiento de datos en tiempo real de los datos por lotes. La capa batch puede tomar su tiempo para procesar toneladas de datos que toman mucho tiempo de cómputo, mientras que la capa de velocidad trabaja en tiempo real y realiza actualizaciones incrementales a los resultados de la capa batch. La capa de servicio toma los outputs de ambos y utiliza estos datos para resolver consultas (queries) pendientes.
Arquitectura Kappa
La arquitectura Kappa está basada en eventos y solo tiene una capa de streaming y una capa de servicio, por lo que todo tipo de datos que necesitan ser procesados se manejan con una sola pila de tecnología. Este paradigma resuelve la redundancia en las arquitecturas Lambda, al evitar el mantenimiento de dos bases de código diferentes para alimentar las capas, así como la estructura multicapa.
La idea detrás de hacer todo en la capa de streaming es reproducir los datos (data replay): esto significa manejar el reprocesamiento continuo y en tiempo real de los datos utilizando solo un motor de procesamiento, lo que evita mantener un código diferente para diferentes capas. Kappa puede parecer más simple, pero ¿qué sucede cuando los datos no están en orden y deben reorganizarse? ¿Qué sucede cuando se debe agregar un campo, o los elementos deben ser referenciados por otros? Estos desafíos se resuelven más fácilmente mediante el procesamiento por lotes y las arquitecturas de Kappa no fueron diseñadas para manejar este tipo de operaciones, aunque algunas soluciones a esos problemas han surgido con el tiempo.
Ventajas y desventajas de las arquitecturas Lambda y Kappa
Ventajas
| Lambda | Kappa |
| Los problemas de datos desordenados se resuelven mediante el procesamiento por lotes. | Resuelve el problema de redundancia de la arquitectura Lambda con una pila única de infraestructura. |
| Balancea velocidad, fiabilidad y escalabilidad. | Solo usa una base de código. |
| El procesamiento de conjuntos de datos completos permite optimizaciones de código. | Utiliza menos recursos. |
| Los grandes conjuntos de datos (en el rango de petabytes) se pueden procesar de manera más eficiente. | Tener cada punto de datos como un evento de streaming te permite revisar el estado completo de la organización en cualquier momento. |
| Abarca muchos escenarios de análisis de datos. | Las consultas son realizadas en una sola ubicación. |
| No es necesario modificar la arquitectura para nuevos casos de uso. |
Desventajas
| Lambda | Kappa |
| La doble codificación para el procesamiento de los datos por lotes y en tiempo real podría requerir dos equipos de desarrolladores. | Difícil de implementar, especialmente la parte de reproducción de datos. |
| Los cambios en un lado deben propagarse al otro. | Manejar eventos duplicados o mantener el orden de los datos es difícil cuando todos los datos se procesan como un único stream. |
| Doble infraestructura significa doble inversión, doble monitoreo y doble cantidad de logs. | Es más difícil de escalar. |
| Módulos duplicados y gran cantidad de código. | El uso extensivo de recursos informáticos es más caro que el almacenamiento en frío (cold storage). |
| Reprocesa cada ciclo de lote. | |
| La migración se dificulta cuando un conjunto de datos ha sido modelado para ser utilizado por una arquitectura Lambda. |
Casos de uso para arquitecturas Lambda
● Cuando los datos almacenados son permanentes y necesitas actualizar e incorporar nuevos datos a la base de datos.
● Cuando se utiliza el almacenamiento inmutable y las consultas del usuario deben ser respondidas tal como sucedieron.
● Cuando se requieren respuestas rápidas y, al mismo tiempo, el sistema necesita manejar varias actualizaciones provenientes de otros flujos de datos.
Casos de uso para Arquitecturas Kappa
● Cuando los algoritmos aplicados a datos en tiempo real y a conjuntos de datos históricos son los mismos, el uso de una sola capa de procesamiento de datos es beneficioso.
● Al desarrollar sistemas de datos de aprendizaje automático en línea, lo que significa que no hay necesidad de una capa para procesamiento de datos por lotes.
● En general, cualquier otro caso de uso que no sea específico para los requisitos de Lambda se puede resolver elegantemente con una arquitectura Kappa.
Arquitectura Lambda vs. Arquitectura Kappa: ¿Cómo elegir una para mi negocio?
Al iniciar un proyecto de Big Data, un análisis integral te ayuda a decidir qué tipo de arquitectura utilizar, recordando que una posterior migración de una a la otra no es sencilla y a veces puede ser una misión imposible. Por lo tanto, elegir la arquitectura correcta desde el principio es clave.
Las arquitecturas Kappa y Lambda pueden ser complementarias, por ahora. Tal vez alguien prefiera una u otra, pero la decisión final dependerá de las necesidades del proyecto. Sin embargo, seguiremos viendo proyectos de análisis de datos que se realizan con ambas arquitecturas, ya que no existe una solución única para cada tipo de problema que se presenta con el procesamiento de datos en tiempo real.