← blog

El estado actual de la “Arquitectura lambda”

El estado actual de la “Arquitectura lambda”

Ha pasado ya algún tiempo desde que Nathan Marz escribió el primer post de la “Arquitectura lambda”. ¿Qué ha pasado desde entonces? ¿Cómo ha reaccionado la comunidad a tal concepto ? ¿Cuáles son las tendencias de arquitecturas en el espacio del Big Data, así como los retos y problemas que quedan ?

Big Data : Sólo procesamiento por lotes

A pesar del atractivo de una mezcla entre procesamiento por lotes (“batch”) y procesamiento en tiempo real, existe una amplia variedad de problemas Big Data para los que una capa “batch” es suficientemente buena, y creo que seguirá siendo así.

La adopción consolidada de Hadoop, junto con la espectacular mejora de sus herramientas disponibles, hace que hoy en día a menudo el principal requisito arquitectónico para resolver muchos retos Big Data sea simplemente el procesamiento por lotes. Con las herramientas “SQL-on-Hadoop” como Impala o Apache Drill, ya no es el caso de que los datos que entran en Hadoop no son rápidamente aprovechables. Aplicaciones operacionales – por ejemplo, involucrando recomendaciones, análisis profundo de un gran histórico de datos, segmentación de clientes, etc. – se benefician de un ecosistema más rico, lo que resulta en ciclos de desarrollo más cortos, así como la mejora del hardware con un mejor software subyacente repercute en tiempos de ciclo más cortos. Más “frameworks” para elegir (Spark , Stratosphere ) y futuros paradigmas como Tez (¿os acordáis de Dryad?) completan el escenario.

(Como curiosidad, mencionar la historia de la evolución arquitectónica de Spiderio, que cambiaron su capa “tiempo real” por una capa sólo “batch” en algún momento.)

Big Data : Sólo procesamiento tiempo real

Dirigidas a empresas donde el tiempo real es crucial, estamos empezando a ver interesantes soluciones tiempo real empaquetadas tales como Druid. Las plataformas de procesamiento tiempo-real como Storm y las bases de datos NoSQL siguen siendo una tendencia (¿os acordáis de la migración de Facebook a HBase ?). Storm mejoró su API por defecto añadiendo Trident, que añade “exactly-once semantics” – y Google anunció Millwheel, que, como siempre, parece dar un gran paso adelante. Sin dejar de mencionar Spark Streaming.

Resulta no-obvio pensar en la “tolerancia contra fallos humanos” de éstos sistemas, así como en su complejidad y precio total. Interesante ver la forma en que ambos mundos se encuentran, visto que algunos de éstos sistemas tiempo real incorporan también un re-indexado o re-proceso total de los datos como parte de su arquitectura fundamental.

Architecturas lambda “unificadas”

Lo que parecía imposible una vez está empezando a llegar: el desarrollo de “Arquitecturas lambda” usando un marco “unificado” que hace que el mismo código esté disponible tanto en la capa tiempo real como en la capa “batch”, y que combina los resultados de las dos capas transparentemente. Dos herramientas están trantado de lograr ésto:

  • Summingbird: Sobre la base de “monoides”, usando Hadoop y Storm como la infraestructura de apoyo. Usado en Twitter con “Manhattan” como base de datos de sólo lectura y Memcached como base de datos “tiempo real”.
  • Lambdoop: Sobre la base de operaciones definidas por el usuario, esquemas Avro, con Hadoop y Storm como la infraestructura de apoyo, HBase como base de datos “batch” y Redis como la de tiempo real.

Con Lambdoop todavía sin liberar y Summingbird siendo un lanzamiento muy reciente, la utilidad real de éstos “frameworks” está aún por ver. Podría darse el caso de que fueran demasiado complejos o restrictivos, o que evolucionaran de forma natural en algo muy útil. Por el momento, el tipo de operaciones que se pueden poner en práctica usándolos parece de alguna manera restringido por la naturaleza de éstos “frameworks”, y los datos finales que se pueden servir se limitan a llave / valor.

Arquitecturas lambda “libres”

Lo que aún me parece el caso más común de arquitectura lambda es una implementación “literal” de la misma donde cada capa funciona de manera independiente y los resultados se combinan en función de las necesidades del negocio.

Cuando cosas como documentos complejos y buscadores textuales entran en juego, se vuelve más difícil razonar acerca de un marco hipotético “unificado” que proporcionaría las garantías y la semántica de una capa de procesamiento por lotes y la inmediatez de un capa tiempo real. Los chicos de Trovit hicieron su sistema capaz de coordinar una capa “batch” y otra tiempo real utilizando Zookeeper.

Como otro ejemplo, en Datasalt hemos implementado analítica para redes de anuncios usando Splout SQL como base de datos de sólo lectura. Esto nos permite precalcular menos cosas y calcular agregaciones en tiempo real sobre la marcha. Junto con Splout, es muy fácil de implementar una capa SQL en tiempo real basada en el uso de tecnologías maduras y probadas como MySQL, teniendo en cuenta que los problemas más difíciles ya están resueltos por la capa de “batch”.

También recuerdo que los chicos de GameDuell de alguna manera lograron mezclar Hadoop y VoltDB bidireccionalmente .

El futuro

Con cosas como Hadoop-Storm para YARN de Yahoo y dado que las herramientas de Big Data son hoy en día más y más fáciles de instalar y gestionar (Cloudera Manager o Apache Ambari hacen la vida realmente mucho más fácil), creo que va a ser mucho menos un dolor de cabeza el implementar un código y una arquitectura Big Data que ejecute procesos por lotes y a la vez los combine con procesamiento en tiempo real. Es más, como hemos dicho, muchos casos todavía serán fácilmente solucionable con sólo procesamiento por lotes. Y como también hemos visto, los “frameworks” tiempo real ya proporcionan a menudo una semántica de re-indexación o re-procesamiento por debajo.

Debido a los numerosos casos de uso posibles, la naturaleza heterogénea de los datos y la variabilidad de requisitos, no está claro si “frameworks” como Summingbird o Lambdoop serán clave para la implementación de arquitecturas lambda. Pero quién sabe, ¡Quizá lo mejor está por venir!



2 Comentarios en "El estado actual de la “Arquitectura lambda”"

  1. Wow, muy interesante. Yo me pierdo bastante entre estos tecnicismos pero reenvío el artículo a unos colegas de la universidad que a buen seguro les encantará la temática y tu reflexión sobre las posibilidades actuales y las tendencias en el mundo Big Data.

    Un saludo y gracias de nuevo por la información, de lo más potente y completo que he leído en tiempo. Felicidades,
    Juan.

  2. Gracias Juan! Un saludo.

Comentar