De Lambda a Kappa: evolución de las arquitecturas Big Data.

La irrupción de Internet, hace más de dos décadas, ha ido transformando los modelos de negocio y, en estos últimos años, los datos han cobrado una especial relevancia a la hora de tomar decisiones y decidir el futuro de las empresas.

En esta línea, desde hace algunos años, escuchamos de forma cada vez más habitual el término Big Data, pero ¿sabemos realmente en qué consiste?

Big Data

Cuando hablamos de Big Data nos referimos a grandes volúmenes de datos, tanto estructurados como no estructurados, que se generan y almacenan en el día a día. Aunque lo realmente importante no es la cantidad de datos de los que disponemos, sino qué hacemos con ellos y qué decisiones tomamos para ayudar a mejorar nuestro negocio basándonos en el conocimiento obtenido tras analizarlos.

Directamente relacionado con este concepto, podemos encontrar la pirámide DIKW que establece que la información, el conocimiento y la sabiduría se definen en base a los datos como vemos en la siguiente imagen:

Los proyectos Big Data se llevan a cabo sobre sistemas de archivos distribuidos, en muchos de los casos sobre el sistema de almacenamiento distribuido del ecosistema Hadoop que recibe el nombre de HDFS (Hadoop Distributed File System).

HDFS es un sistema de archivos distribuido, escalable y portable escrito en Java, que fue inicialmente diseñado para usarse junto con Hadoop, un framework open source para desarrollo de aplicaciones distribuidas inspirado en los papers de Google Google File System y MapReduce.

Desde hace unos años es el framework más utilizado para llevar a cabo proyectos Big Data y ha sido la pieza clave de su evolución para llevarlo hasta el punto en el que se encuentra en nuestros días.

Para situar en el tiempo la aparición de Hadoop y otras fuertemente relacionadas con el Big Data utilizaremos la imagen siguiente:

Además de las tecnologías relacionadas con el ecosistema Hadoop (Hadoop, Hive, HBase, etc...) hay que destacar Spark por su rol determinante en la evolución del Big Data.

Spark es un motor de procesamiento de datos distribuidos que permite manejar grandes volúmenes de información. Se podría entender como una evolución de Hadoop MapReduce, ofreciendo entre otras las siguientes ventajas sobre este:

• Trabaja con los datos en memoria a diferencia de MapReduce, que utiliza datos almacenados en disco, lo que le permite ser más rápido a costa de un mayor consumo de recursos.
• Ofrece procesamiento en tiempo real.
• Dispone de módulos de extensión que permiten hacer Machine Learning, streaming, grafos, acceso a datos, etc...
• Soporta diferentes lenguajes de programación.

En la imagen de la línea del tiempo que hemos visto anteriormente, podemos encontrar dos letras griegas en el gráfico en los años 2012 y 2014, que han dado nombre a las diferentes arquitecturas de las que vamos a hablar a continuación.

Arquitectura Lambda y Arquitectura Kappa

Debido a que las empresas disponen de un volumen cada vez mayor de datos y a la necesidad de analizarlos y obtener valor de ellos lo antes posible, surge la necesidad de definir nuevas arquitecturas para cubrir casos de uso distintos a los que había hasta el momento.

Las arquitecturas más comunes en estos proyectos son principalmente dos: Arquitectura Lambda y Arquitectura Kappa. La principal diferencia entre ambas son los flujos de tratamiento de datos que intervienen, pero vamos a ver en qué consiste cada una con más detalle.

Un par de conceptos que tenemos que definir antes de ver las características de ambas, son el procesamiento batch y el procesamiento en streaming.

• Batch hace referencia a un proceso en el que intervienen un conjunto de datos y que tiene un inicio y un fin en el tiempo.
• Por el contrario, decimos que un procesamiento es de tipo streaming cuando está continuamente recibiendo y tratando nueva información según va llegando sin tener un fin en lo referente al apartado temporal.

Arquitectura Lambda

La Arquitectura Lambda representada mediante la letra griega , apareció en el año 2012 y se atribuye a Nathan Marz. La definió en base a su experiencia en sistemas de tratamiento de datos distribuidos durante su etapa como empleado en las empresas Backtype y Twitter, y está inspirada en su artículo How to beat the CAP theorem.

Su objetivo era tener un sistema robusto tolerante a fallos, tanto humanos como de hardware, que fuera linealmente escalable y que permitiese realizar escrituras y lecturas con baja latencia.

Nathan da solución a este problema creando una arquitectura cuyo diagrama de alto nivel aparece en la siguiente imagen:

Las características de la Arquitectura Lambda son:

• La nueva información recogida por el sistema se envía tanto a la capa de batch como a la capa de streaming (denominada como Speed Layer en la imagen anterior).
• En la capa batch (Batch Layer) se gestiona la información en crudo, es decir, sin modificar. Los datos nuevos se añaden a los ya existentes. Seguidamente se hace un tratamiento mediante un proceso batch cuyo resultado serán las denominadas Batch Views, que se usarán en la capa que sirve los datos para ofrecer la información ya transformada al exterior.
• La capa que sirve los datos o Serving Layer, indexa las Batch Views generadas en el paso anterior de forma que puedan ser consultadas con baja latencia.
• La capa de streaming o Speed Layer, compensa la alta latencia de las escrituras que ocurre en la serving layer y solo tiene en cuenta los datos nuevos.
• Finalmente, la respuesta a las consultas realizadas se construye combinando los resultados de las Batch Views y de las vistas en tiempo real (Real-time Views), las cuales se han generado en el paso anterior.

En resumen, este tipo de arquitectura se caracteriza por utilizar distintas capas para el procesamiento batch y el streaming.

Arquitectura Kappa

El término Arquitectura Kappa, representada por la letra , fue introducido en 2014 por Jay Kreps en su artículo Questioning the Lambda Architecture.

En él señala los posibles puntos “débiles” de la Arquitectura Lambda y cómo solucionarlos mediante una evolución. Su propuesta consiste en eliminar la capa batch dejando solamente la capa de streaming.

Esta capa, a diferencia de la de tipo batch, no tiene un comienzo ni un fin desde un punto de vista temporal y está continuamente procesando nuevos datos a medida que van llegando.

Como un proceso batch se puede entender como un stream acotado, podríamos decir que el procesamiento batch es un subconjunto del procesamiento en streaming.

Esta evolución consiste en una simplificación de la Arquitectura Lambda, en la que se elimina la capa batch y todo el procesamiento se realiza en una sola capa denominada de tiempo real o Real-time Layer, dando soporte a procesamientos tanto batch como en tiempo real.

El diagrama de arquitectura estaría representado por la siguiente imagen:

Podemos decir que sus cuatro pilares principales son los siguientes:

• Todo es un stream: las operaciones batch son un subconjunto de las operaciones de streaming, por lo que todo puede ser tratado como un stream.
• Los datos de partida no se modifican: los datos son almacenados sin ser transformados y las vistas se derivan de ellos. Un estado concreto puede ser recalculado puesto que la información de origen no se modifica.
• Solo existe un flujo de procesamiento: puesto que mantenemos un solo flujo, el código, el mantenimiento y la actualización del sistema se ven reducidos considerablemente.
• Posibilidad de volver a lanzar un procesamiento: se puede modificar un procesamiento concreto y su configuración para variar los resultados obtenidos partiendo de los mismos datos de entrada.

Como requisito previo a cumplir, se tiene que garantizar que los eventos se leen y almacenan en el orden en el que se han generado. De esta forma, podremos variar un procesamiento concreto partiendo de una misma versión de los datos.

¿Qué arquitectura se adapta mejor a nuestro problema?

Una vez visto en qué consiste cada una de las arquitecturas, viene la parte complicada que es decidir cuál es la que encaja mejor para nuestro modelo de negocio.

Como en la mayoría de los casos, se puede decir que no hay una única solución óptima para todos los problemas, lo que se suele definir mediante el término “One size does not fit all”. La Arquitectura Lambda es más versátil y es capaz de cubrir un mayor número de casos, muchos de ellos que requieren incluso procesamiento en tiempo real.

Una pregunta que debemos plantearnos para poder decidir es, ¿el análisis y el procesamiento que vamos a realizar en las capas batch y streaming es el mismo? En ese caso la opción más acertada sería la Arquitectura Kappa.

Como ejemplo real de esta arquitectura podríamos poner un sistema de geolocalización de usuarios por la cercanía a una antena de telefonía móvil. Cada vez que se aproximase a una antena que le diese cobertura se generaría un evento. Este evento se procesaría en la capa de streaming y serviría para pintar sobre un mapa su desplazamiento respecto a su posición anterior.

Sin embargo, en otras ocasiones necesitaremos acceder a todo el conjunto de datos sin penalizar el rendimiento por lo que la Arquitectura Lambda puede ser más apropiada e incluso más fácil de implementar.

También nos inclinaremos hacia una Arquitectura Lambda si nuestros algoritmos de batch y streaming generan resultados muy distintos, como puede suceder con operaciones de procesamiento pesado o en modelos de Machine Learning.

Un caso de uso real para una arquitectura Lambda podría ser un sistema que recomiende libros en función de los gustos de los usuarios. Por un lado, tendría una capa batch encargada de para entrenar el modelo e ir mejorando las predicciones; y por otro, una capa streaming capaz de encargarse de las valoraciones en tiempo real.

Conclusiones

Para finalizar, hay que destacar lo rápido que evolucionan los casos de uso que queremos cubrir con nuestras soluciones Big Data, y eso supone que hay que adaptarse a ellos lo antes posible.

Cada problema a resolver tiene unos condicionantes particulares y en muchos casos habrá que evolucionar la arquitectura que estábamos utilizando hasta el momento, o como se suele decir: “renovarse o morir”.