De Lambda a Kappa: Guía sobre arquitecturas de big data en tiempo real

De Lambda a Kappa: Guía sobre arquitecturas de big data en tiempo real

Si hablamos de arquitecturas de big data en tiempo real hoy en día... existen muchas opciones. Hoy en día podemos encontrar alternativas que van más allá de la arquitectura Lambda y, en esta serie del blog, analizaré un par de estas opciones y las cotejaré mediante ejemplos prácticos pertinentes. Así pues, ¿cómo elegimos la arquitectura más conveniente para nuestro proyecto en tiempo real? Vayamos por partes.

Requisitos en tiempo real

Antes de adentrarnos en la arquitectura, comentemos algunos de los requisitos de los sistemas de procesamiento de datos en tiempo real para tratar con big data.

El más evidente de estos requisitos es que los datos están en movimiento. Dicho de otra forma, los datos son continuos e ilimitados. En realidad lo importante es cuándo analices los datos. Si está buscando respuestas ante el alud actual de datos o tiene algún requisito de baja latencia concreto, seguramente le interesará trabajar en tiempo real.

Además, muchas veces las empresas tienen sus plazos de entrega que hay que cumplir. Al fin y al cabo, si saltarse los plazos no tuviera consecuencias para el análisis en tiempo real, podría procesarse todo por lotes. Estas consecuencias varían desde el fracaso total a, sencillamente, la degradación del servicio.

Como estamos hablando de big data, también esperamos superar los límites en cuanto a volumen, velocidad y, posiblemente, incluso la variedad de los datos.

A menudo el procesamiento de datos en tiempo real exige una serie de cualidades, como la escalabilidad, la tolerancia a los fallos, la predecibilidad, la resiliencia ante imperfecciones del flujo y la extensibilidad.

Nuevas arquitecturas para la era de los nuevos datos

Para abordar esta necesidades nacieron las nuevas arquitecturas o, dicho de otro modo, la necesidad agudiza el ingenio.

La arquitectura Lambda, atribuida a Nathan Marz, es una de las más habituales actualmente en el procesamiento de datos en tiempo real. Está pensada para permitir lecturas de baja latencia y actualizaciones de forma linealmente escalable y tolerante a fallos.

El flujo de datos que entra en el sistema alimenta de forma dual tanto una capa por lotes como una de velocidad.

La capa por lotes almacena los datos sin tratar cuando llegan y computa las vistas por lotes para su consumo. Naturalmente los procesos por lotes tendrán lugar a un cierto intervalo y serán de largo recorrido. El alcance de los datos puede variar de horas a años.

La capa de velocidad se utiliza para computar las vistas en tiempo real para complementar las vistas por lotes.

Cualquier consulta puede obtener una imagen completa extrayendo datos tanto de las vistas por lotes como las que son en tiempo real. Las consultas obtendrán lo mejor de ambos mundos. Las vistas por lotes pueden procesarse con reglas más complejas o caras y tener mejor calidad de datos y menos sesgados, mientras que las vistas en tiempo real hoy por hoy nos dan acceso a los datos más recientes posibles. Con el paso del tiempo, los datos en tiempo real caducan y los sustituyen datos de las vistas por lotes.

Otra ventaja de esta arquitectura es que te permite volver a reproducir los mismos datos de entrada y generar nuevas vistas si es necesario algún cambio de código o de fórmula.

El principal reproche a esta arquitectura ha sido la necesidad de conservar dos sistemas distintos (y seguramente complejos) para generar tanto las capas por lotes como las de velocidad. Por suerte con Spark Streaming (capa de abstracción) o Talend (generador de código para Spark Batch y Streaming), este aspecto ya no es tan problemático… si bien la carga operativa sigue existiendo.

A continuación hablaremos de la arquitectura Kappa.

El primero en describir la arquitectura Kappa fue Jay Kreps. Se centra en procesar datos exclusivamente como flujo. No es ninguna alternativa a la arquitectura Lambda, salvo cuando es perfecta para su casuística. Para esta arquitectura los datos de entrada fluyen por una capa en tiempo real y los resultados de estos se colocan en la capa de servicio para consultas.

La idea es manejar el procesamiento de datos en tiempo real y el reprocesamiento continuo en un motor de procesamiento de flujo único. Así es, el reprocesamiento se produce desde el flujo. Esto exige que el flujo de datos de entrada pueda volver a reproducir (muy rápidamente) o bien en su totalidad o bien desde una posición concreta. Si se dan cambios de código, un segundo proceso de flujo volvería a reproducir todos los datos anteriores por medio del último motor en tiempo real y cambiaría los datos almacenados en la capa de servicio.

Esta arquitectura intenta simplificar conservando tan solo una base de código en lugar de gestionar una por cada capa por lotes y cada capa de velocidad de la arquitectura Lambda. Además, las consultas tan solo tienen que buscar en una única ubicación de servicio en lugar de tener que bregar con las vistas por lotes y de velocidad.

La complicación de esta arquitectura pasa sobre todo por tener que procesar estos datos en un flujo, como por ejemplo gestionar duplicaciones, cruzar incidencias o mantener el orden, operaciones que suelen ser más sencillas en el procesamiento por lotes.

Quizá no exista el café para todos en este caso.

Hay muchos casos de uso en tiempo real que serán perfectos para la arquitectura Lambda. No podemos decir lo mismo de la arquitectura Kappa. Si el análisis por lotes y en streaming son idénticos, probablemente la mejor solución sea optar por Kappa. En algunos casos, sin embargo, tener acceso a un conjunto de datos completo en una ventana por lotes puede aportarnos ciertas optimizaciones que mejorarían el rendimiento de la arquitectura Lambda y quizá incluso simplificarían su aplicación.

También existen situaciones muy complejas en las que los algoritmos por lotes y en streaming producen resultados muy distintos (utilizando modelos de machine learning, sistemas expertos u operaciones inherentemente muy caras que deben efectuarse de forma distinta en tiempo real ), en cuyo caso se exigiría el uso de Lambda.

Y hasta aquí el repaso de las dos arquitecturas de procesamiento de datos en tiempo real más habituales. Los próximos artículos de la serie se adentrarán en cada una de ellas y analizaremos varios casos concretos y tecnologías que encontramos a menudo con estas arquitecturas.

Referencias:

“Cómo vencer el teorema CAP”, de Nathan Marz
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

“La arquitectura Lambda en tela de juicio”, de Jay Kreps
https://www.oreilly.com/ideas/questioning-the-lambda-architecture

“Los big data”, de Nathan Marz, James Warren
https://www.manning.com/books/big-data

Join The Conversation

0 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *