Skip to main content
Ejercito Apache

Flume, Kafka, Spark y Storm, ¿un nuevo ejército Apache?

Que la Apache Software Foundation (ASF) se las ingenie para concebir algún producto software innovador y curioso y que le pongan un nombre original para que no sea fácil de olvidar parece ser algo a lo que ya nos tiene acostumbrados. Son esos nombres los que utilizamos día a día para referirnos a un compendio de información y terminologías; por ejemplo, si hablamos de patrones o queremos abordar algún tema de mensajería JMS, respectivamente, nos evocarán Camel y ActiveMQ.

Ahora bien, si hablamos de Flume, Kafka, Spark o Storm, ¿a qué nos referimos? ¿Nos evocan algún conjunto de ideas? Todos ellos también son aportaciones de la ASF y aunque los dos últimos (Spark y Storm) están empezando a coger fuerza, aún se nombran sin quedar del todo claro qué aporta cada uno o cómo utilizarlos. ¿Esto no os recuerda a la metáfora de Big Data?: “everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it”.

Para aportar un poco de luz a estos nombres tan oscuros, voy a haceros una descripción intentando no extenderme demasiado para que estas cuatro palabras “raras” se vuelvan “amigables”.

Apache Spark

Apache Spark es un sistema de computación en cluster de propósito general que resultará muy amigable a quien haya estado trasteando con la computación de altas prestaciones (HPC) ya que le evocará una gran similitud con Open MPI por cómo se configura su ejecución en cluster o su arquitectura.

spark

El modelo de datos utilizado por Apache Spark se denomina “Resilient Distributed Datasets” (RDDs). Este nombre no os debe asustar ya que al fin y al cabo estas estructuras de datos no son más que arrays. ¿Por qué arrays como estructura de datos? Un array tiene acceso directo a todas sus posiciones, no incorpora punteros al siguiente elemento o al anterior,… y esto, entre otras cosas, permite minimizar el ancho de banda necesario para los paquetes enviados entre el Driver Program y los Work Nodes.

Apache Spark permite dos tipos de operaciones: transformaciones y acciones. Las transformaciones se podrían definir como la creación de un dataset de uno existente. Estas operaciones se ejecutan en modo lazy, es decir, se ejecutarán verdaderamente cuando se lleve a cabo una acción. Por otro lado, las acciones se podrían definir como el cálculo de un dataset que retorna un valor al Driver Program.

Con el fin de mejorar el rendimiento entre operaciones, se permite la persistencia o el almacenamiento en caché de un RDD entre operaciones.

Para terminar con Apache Spark, hay que mencionar los tipos de variables compartidas que aporta; variables Broadcast y acumuladores. Las variables Broadcast se podrían definir como una memoria de constantes optimizada para solo lectura disponible en los Work Nodes. Los acumuladores por el contrario son como una variable estática protegida contra modificaciones concurrentes en el Driver Program que sólo puede ser leída por éste pero que es actualizada por los Work Nodes.

Apache Flume

Apache Flume es un servicio que agrega grandes cantidades de log. Según indica la documentación, su flexible arquitectura basada en agentes podría utilizarse con otros fines distintos, aunque la recomendación de ASF sobre su uso es bastante clara: “If you need to ingest textual log data into Hadoop/HDFS then Flume is the right fit for your problem, full stop”.

flume

Conceptualmente, Apache Flume sería como una especialización del uso de JMS. Dentro del agente, tanto la Source como el Sink se ejecutan en transacciones separadas y el Channel permite la gestión de ficheros para persistir los mensajes.

El modelo de datos utilizado por Apache Flume podría considerarse como un mensaje JMS muy limitado ya que consiste en un conjunto de atributos opcionales de tipo String y un Byte payload.

Como fuentes de mensajes (sources) podemos encontrar todo tipo de formatos como por ejemplo JMS, Syslog y HTTP. Sin embargo, como destino de los mensajes (sinks), aunque se permite la implementación de custom sinks, los que incorpora Apache Flume están muy focalizados; HDFS, Logger, File Roll, Null, ElasticSearch,… de ahí que yo también comparta la recomendación de la ASF sobre su utilización focalizada en la agregación de logs.

Apache Storm

Apache Storm es un sistema de computación distribuida en tiempo real que sigue una arquitectura Master-Slave donde ninguna instancia mantiene estado y éste se delega para que sea gestionado por ZooKeeper. La instancia Master se denomina “Nimbus” y las instancias Slave se denominan “Supervisor”.

Storm

El modelo de datos de Apache Storm se basa en tuplas. Este modelo de datos tan simple es aprovechado al máximo mediante el paralelismo a nivel de datos que se lleva a cabo en sus estructuras de cómputo denominadas Topologies. El paralelismo a nivel de datos, para quien no le suene la terminología, es el que se lleva a cabo en las GPUs y se basa, a grandes rasgos, en que los datos fluyan por las instrucciones y no sean las instrucciones las que compiten por una zona de exclusión mutua (el cual sería el paralelismo de instrucciones al que estamos habituados).

Las Topologies no son más que árboles complejos que se encargan de realizar el cómputo y se componen de spouts y bolts. Se denomina spout a la fuente de datos y bolt al nodo, por decirlo de alguna manera, que se encarga de llevar a cabo el cálculo.

storm_02

Las topologies se pueden ejecutar tanto en local mode como en cluster y cada bolt a su vez se ejecuta en un pool de hilos. Por este motivo, el nivel de concurrencia que se puede obtener con Apache Storm me parece muy interesante y algo a tener muy en cuenta.

Apache Kafka

Apache Kafka es un sistema de mensajería distribuido de alto rendimiento que se fundamenta en el uso de TOPIC, fusionando de este modo las colas y tópicos que conocemos de JMS en un único recurso. Los consumidores se etiquetan a sí mismos con un nombre de grupo y cada mensaje publicado en un TOPIC es entregado a un solo consumidor dentro de cada grupo:

  • Si todos los consumidores tienen el mismo nombre de grupo, funcionará como una cola en la cual se balancean los mensajes entre consumidores.
  • Si todos los consumidores tienen diferentes nombres de grupo, funcionará como un tópico y todos los mensajes serán enviados a todos los consumidores modo broadcast.

Apache Kafka escribe en un TOPIC como si fuera un RAID de discos duros que se denominan particiones. Son estas particiones las que permiten paralelizar la escritura y gestionar la redundancia, la tolerancia a fallos del sistema y el balanceo de carga.

kafka_001

Apache Kafka no basa sus mensajes en JMS, sino que usa un protocolo binario sobre TCP con su propia especificación. Un mensaje no es más que un byte payload y un checksum para comprobar que no se han corrompido. Gracias a esto, se limita el tráfico de datos por la red y la latencia de los mensajes.

Lo más llamativo de Apache Kafka es cómo se realiza la lectura y borrado de los mensajes:

  • La lectura de los mensajes por parte de los consumidores se basa en un offset desde el inicio para leer el mensaje correspondiente en cada momento. Esto implica que una lectura no implica el borrado del mensaje leído por lo que se mejora el rendimiento de manera considerable.
  • Por otro lado, el borrado de los mensajes se realiza mediante una especie de proceso desatendido que se encarga de hacer una especie de purge de base de datos en los ficheros de logs (particiones) en el tiempo que se configure. Esto es posible ya que la estructuración de las particiones se fundamenta en la jerarquía de ficheros con indirección que algunos recordaréis de los sistemas operativos Linux cuando los ficheros eran muy grandes.

kafka_002

Consideraciones

Todas estas descripciones quedan muy interesantes y eficientes sobre el papel, pero, ¿realmente estas arquitecturas tan curiosas llegan a suponer un beneficio? ¿En qué se podrían aplicar cada una de ellas?

  • Ninguna tecnología es mejor sinónimo de Big Data que Apache Hadoop. Hadoop es un framework que permite el procesamiento distribuido de inmensas cantidades de datos de manera linealmente escalable y eficiente. Logs de aplicaciones, seguimiento GPS y sensores digitales constituyen todos ellos un flujo considerable de datos para almacenar en el sistema de ficheros distribuidos de Hadoop (HDFS – Hadoop Distributed File System). Como cabe esperar, existen numerosas tecnologías para direccionar y transportar estos flujos de datos, pero sin dudarlo, Apache Flume está llegando a ser el estándar de facto para dirigir estos flujos de datos a Hadoop.
  • Hadoop depende del almacenamiento persistente para proporcionar tolerancia a fallos y su modelo de cálculo para realizar “MapReduce” lo hace ser una mala opción para aplicaciones de baja latencia y cálculos iterativos como algoritmos de aprendizaje automático y grafos. Apache Spark es capaz de cachear los dataset en memoria para no perjudicar el rendimiento en aplicaciones de baja latencia y su gestión para compartir datos a través de memoria soluciona el problema de los cálculos iterativos que presenta Hadoop. Entre las múltiples utilidades que se le puede dar a Spark, destacaría el análisis de datos interactivo, mayor rendimiento en operaciones batch, toma rápida de decisiones y procesamiento de streaming en tiempo real.
  • Existen grandes cantidades de proyectos que se están llevando a cabo con Apache Storm dentro de las áreas de optimización de ingresos, anti-spam y content discovery. Pero sin duda alguna, si tuviera que quedarme con un ejemplo de uso concreto elegiría el de Twitter. Storm se encarga de procesar cada tweet que se publica en Twitter para proporcionar un análisis en tiempo real a sus partners. Además, Storm se integra sin problemas con el resto de la infraestructura de Twitter, incluyendo Cassandra, Kestrel (sistema de cola de mensajes distribuido desarrollado por Twitter) y Mesos.
  • Para terminar, un ejemplo de uso de Apache Kafka sería su utilización por parte de la gente de LinkedIn para construir un pipeline de datos centralizado en tiempo real. Kafka se encarga de integrar gran variedad de datos (gente que podrías conocer, métricas y logs de sistemas y aplicaciones,…) y los hace disponibles para sus sistemas evitando pipelines punto a punto.

Y con esto concluyo esperando que os haya aportado algo de luz sobre estas tecnologías y pueda serviros de guía para problemas futuros. Aun así, recordad que cada problema es un mundo y en la imaginación está el límite, así que usadla con moderación.

 

 

Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

Elías Grande Rubio ha escrito 7 entradas


Elías Grande Rubio

Arquitecto SOA/BPM y Consultor de Seguridad TIC pragmático e investigador. Apasionado de la seguridad, las tecnologías middleware y de la computación de altas prestaciones. Diseñador de ideas revolucionarias que me hubieran hecho rico… pero las guardé en Megaupload y ahora escribo blogs.

7 comentarios en “Flume, Kafka, Spark y Storm, ¿un nuevo ejército Apache?

  1. Encuentro muy interesante el artículo. También me gustaría adicionar que Apache Flume, provee un sink para bases de datos NoSQL como HBase, el cual permite ingestar datos de baja latencia rápidamente y después a través de sistemas como Apache Storm, hacer análisis de información en tiempo real.

Deja un comentario

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