Contenido


Procese big data en tiempo real con Twitter Storm

Una introducción a big data de modalidad continua

Comments

Hadoop, el rey indiscutible de la analítica de big data, se centra en el procesamiento por lotes. Este modelo es suficiente para muchos casos (como el indexado en web), pero existen otros modelos de uso en los cuales se requiere información en tiempo real de orígenes altamente dinámicos. La solución de este problema dio como resultado la introducción de Storm de Nathan Marz (ahora con Twitter mediante BackType). Storm no opera sobre datos estáticos sino sobre datos de modalidad continua que se espera que sean continuos. Debido a que los usuarios de Twitter generan 140 millones de tweets por día, es fácil ver la utilidad de esta tecnología.

Pero Storm es más que un sistema tradicional de analítica de big data: es un ejemplo de un sistema complejo de procesamiento de eventos (CEP). Los sistemas CEP son normalmente categorizados como orientados a la computación y a la detección, cada una de los cuales puede ser implementada en Storm mediante algoritmos definidos por el usuario. Los CEPs pueden, por ejemplo, utilizarse para identificar eventos significativos a partir de una gran cantidad de eventos y después actuar sobre esos eventos en tiempo real.

Nathan Marz proporciona varios ejemplos en los que se usa Storm dentro de Twitter. Uno de los más interesantes es la generación de información de tendencias. Twitter extrae tendencias emergentes a partir de los tweets publicados y las mantiene a nivel local y nacional. Esto significa que a medida que una historia comienza a surgir, el algoritmo de temas de tendencia de Twitter identifica el tema en tiempo real. Este algoritmo en tiempo real se implementa en Storm como un análisis continuo de datos de Twitter.

Storm comparado con los big data tradicionales

Lo que diferencia a Storm de otras soluciones de big data es el paradigma que aborda. Hadoop es fundamentalmente un sistema de procesamiento por lotes. Los datos se introducen en el sistema de archivos de Hadoop (HDFS) y se distribuyen a través de los nodos para su procesamiento. Cuando el procesamiento está completo, los datos resultantes regresan a HDFS para ser utilizados por el originador. Storm soporta la construcción de topologías que transforman secuencias de datos sin finalizar. Esas transformaciones, a diferencia de los trabajos de Hadoop, nunca se detienen, sino que continúan procesando datos conforme van llegando.

Implementaciones de big data

El núcleo de Hadoop fue escrito en lenguaje Java™ pero soporta aplicaciones de analítica de datos escritas en diversos lenguajes. Competidores recientes han elegido rutas más esotéricas para sus implementaciones con el objeto de explotar lenguajes modernos y sus dispositivos. Por ejemplo, Spark de la Universidad de California (UC), Berkley, está implementado en el lenguaje de Scala, mientras que Twitter Storm está implementado en Clojure (se pronuncia igual que closure).

Clojure es un dialecto moderno del lenguaje de Lisp. Clojure, como Lisp, soporta un estilo funcional de programación, pero Clojure también incorpora dispositivos para simplificar la programación de multihebras (un dispositivo útil para la construcción de Storm). Clojure es un lenguaje basado en máquina virtual (VM) que se ejecuta en Java Virtual Machine. Pero aunque Storm fue desarrollado en Clojure, es posible escribir aplicaciones dentro de Storm en prácticamente cualquier lenguaje. Lo único que necesita es un adaptador para conectarse a la arquitectura de Storm. Existen adaptadores para Scala, JRuby, Perl y PHP, y hay un adaptador de Structured Query Language que soporta la modalidad continua en una topología de Storm.

Atributos clave de Storm

Storm implementa un conjunto de características que lo definen en términos de rendimiento y confiabilidad. Storm utiliza ZeroMQ para el pase de mensajes, lo cual elimina las colas intermedias y permite que los mensajes fluyan directamente entre las tareas mismas. Detrás de la mensajería se encuentra un mecanismo automatizado eficaz para la serialización y deseralización de tipos primitivos de Storm.

Lo que hace que Storm sea interesante es su enfoque en la tolerancia a fallas y en la gestión. Storm implementa un procesamiento de mensajes garantizado de modo que cada tupla es completamente procesada mediante la topología; si se descubre que una tupla no ha sido procesada, se reproduce automáticamente desde el spout. Storm también implementa la detección de fallas al nivel de la tarea. Cuando falla una tarea, los mensajes se reasignan automáticamente para reiniciar rápidamente el procesamiento. Storm incluye una gestión de procesos más inteligente que Hadoop, donde los procesos son gestionados por supervisores para garantizar que los recursos sean utilizados adecuadamente.

El modelo de Storm

Storm implementa un modelo de flujo de datos en el cual los datos fluyen continuamente a través de una red de entidades de transformación (vea la Figura 1). La abstracción de un flujo de datos se denomina secuencia, que es una secuencia ilimitada de tuplas. La tupla es como una estructura que puede representar tipos de datos estándar (como enteros, flotantes y matrices de bytes) o tipos definidos por el usuario con algo de código de serialización adicional. Cada secuencia se define con un ID exclusivo que puede ser utilizado para desarrollar topologías de orígenes de datos y sinks. Las secuencias se originan a partir de spouts, por los que los datos fluyen desde orígenes externos hacia la topología de Storm.

Figura 1. Arquitectura conceptual de una topología de Storm trivial
Diagram of the conceptual architecture of a trivial Storm topology
Diagram of the conceptual architecture of a trivial Storm topology

Los sinks (o entidades que proporcionan transformaciones) se denominan bolts. Los bolts implementan una sola transformación en una secuencia y todo el procesamiento dentro de la topología de Storm. Los bolts pueden implementar cosas tradicionales como la funcionalidad de MapReduce o acciones más complejas (funciones de un solo paso) como el filtrado, las agregaciones o la comunicación con entidades externas como una base de datos. Una topología de Storm típica implementa múltiples transformaciones y por lo tanto requiere múltiples bolts con secuencias de tupla independientes. Tanto los spouts como los bolts se implementan como una o más tareas dentro de un sistema de Linux® .

Es posible utilizar Storm para implementar fácilmente la funcionalidad de MapReduce para la frecuencia de palabras. Como se muestra en la Figura 2, un spout genera la secuencia de datos textuales y un bolt implementa la función de correlación (para tokenizar las palabras de una secuencia). La secuencia resultante del bolt "correlación" luego fluye en un solo bolt que implementa la función Reduce (para agregar las palabras en conteos).

Figura 2. Topología simple de Storm para la función de MapReduce
Diagram of a simple Storm topology for the MapReduce function
Diagram of a simple Storm topology for the MapReduce function

Tenga en cuenta que los bolts pueden secuenciar datos para múltiples bolts así como aceptar datos de múltiples orígenes. Storm tiene el concepto de agrupaciones de secuencia, que implementan la redistribución(distribución aleatoria pero equitativa de tuplas a bolts) o la agrupación de campo (particionamiento de secuencia con base en los campos de la secuencia). Existen otras agrupaciones de secuencia, incluso la capacidad del productor de enrutar las tuplas utilizando su propia lógica interna.

Pero una de las características más interesantes en la arquitectura de Storm es el concepto de procesamiento de mensajes garantizado. Storm puede garantizar que todas las tuplas que emita un spout serán procesadas; si no son procesadas antes de que se exceda el tiempo de espera, Storm reproduce la tupla a partir del spout. Esta funcionalidad requiere de algunos trucos para realizar el seguimiento de la tupla a través de la topología y es uno de los valores agregados clave de Storm.

Además de soportar la mensajería confiable, Storm utiliza ZeroMQ para maximizar el rendimiento de la mensajería (eliminando las colas intermedias e implementando el pase directo de mensajes entre tareas). ZeroMQ incorpora la detección de congestión y altera su comunicación para optimizar el ancho de banda disponible.

Storm en un ejemplo

Observemos ahora un ejemplo de Storm a través del código para implementar una topología simple de MapReduce (vea el Listado 1). Este ejemplo utiliza el bien construido ejemplo de conteo de palabras del kit de principiante de Storm de Nathan disponible en GitHub (vea Temas relacionados donde encontrará un enlace). Este ejemplo ilustra la topología que se muestra en la Figura 2, y que implementa una transformación de correlación que consiste en un bolt y una transformación de reduce que consiste en un bolt individual.

Listado 1. Desarrollo de una topología en Storm para la Figura 2
01  TopologyBuilder builder = new TopologyBuilder();
02          
03  builder.setSpout("spout", new RandomSentenceSpout(), 5);
04          
05  builder.setBolt("map", new SplitSentence(), 4)
06           .shuffleGrouping("spout");
07  
08  builder.setBolt("reduce", new WordCount(), 8)
09           .fieldsGrouping("map", new Fields("word"));
10  
11  Config conf = new Config();
12  conf.setDebug(true);
13  
14  LocalCluster cluster = new LocalCluster();
15  cluster.submitTopology("word-count", conf, builder.createTopology());
16  
17  Thread.sleep(10000);
18  
19  cluster.shutdown();

El Listado 1 m(números de línea añadidos para referencia) comienza con la declaración de una nueva topología medianteTopologyBuilder. Luego, en la línea 3, se define un spout (llamado spout ) que consiste en un RandomSentenceSpout. La clase RandomSentenceSpout (llamada el método nextTuple ) emite una de cinco oraciones aleatorias como datos. El argumento 5 al final del método setSpout es una pista de paralelismo (o el número de tareas a crear para esta actividad).

En las líneas 5 y 6, defino el primer bolt (o la entidad de transformación algorítmica)—en este caso, el bolt map (o split). Este bolt utiliza SplitSentence para tokenizar la corriente de entrada y la emite como palabras individuales de salida. Tenga en cuenta el uso de shuffleGrouping en la línea 6, que define la suscripción de entrada para este bolt (en este caso, el "spout") pero también que la agrupación de secuencia está definida como aleatoria. Esta agrupación aleatoria significa que la entrada desde el spout será redistribuida, o distribuida aleatoriamente en tareas dentro de este bolt(que tiene una pista de paralelismo de cuatro tareas).

En las líneas 8 y 9, defino el último bolt, que sirve efectivamente como el elemento reduce, con su entrada como el bolt map. El método WordCount implementa el comportamiento de conteo de palabras necesario (agrupando palabras similares para mantener un conteo general) pero no es redistribuido, por lo que su salida es coherente. Si hubieran múltiples tareas implementando el comportamiento de reduce, terminaría con conteos segmentados, no con conteos generales.

Las líneas 11 y 12 crean y definen un objeto de configuración y habilitan el modo de depuración. La clase Config contiene un gran número de posibilidades de configuración (vea Temas relacionados para obtener un enlace a más información sobre el árbol de clase Storm).

Las líneas 14 y 15 crean el clúster local (en este caso, definiendo el uso del modo Local). Yo defino el nombre de mi clúster local, mi objeto de configuración y mi topología (recuperada mediante el elemento createTopology de la clase builder ).

Finalmente, en la línea 17, Storm duerme durante un tiempo y después concluye el clúster en la línea 19. Recuerde que Storm es un sistema operativo de funcionamiento continuo, por lo que las tareas pueden existir durante una cantidad de tiempo considerable, y pueden operar en nuevas tuplas en secuencias a las cuales están suscritas.

Puede aprender más sobre esta sorprendentemente simple implementación, incluidos los detalles del spout y los bolts, en el kit de principiante de Storm.

Uso de Storm

Nathan Marz ha escrito un conjunto de documentos legibles que detalla la instalación de Storm para modalidades de operación de clúster y local. La modalidad local permite el uso de Storm sin el requisito de un gran clúster de nodos. Si necesita utilizar Storm en un clúster pero carece de los nodos, también puede implementar un clúster de Storm en Amazon Elastic Compute Cloud (EC2). Vea Temas relacionados para obtener una referencia para cada modalidad de Storm (Local, Cluster y Amazon EC2).

Otras soluciones de código abierto para big data

Desde que Google introdujo el paradigma de MapReduce en 2004, han aparecido varias soluciones que utilizan (o que tienen cualidades de) el paradigma original de MapReduce. La aplicación original de Google de MapReduce fue para el indexado de la World Wide Web. Si bien esta aplicación sigue siendo de uso popular, los problemas que este simple modelo resuelve están creciendo.

La Tabla 1 proporciona una lista de soluciones disponibles de código abierto para big data, incluyendo aplicaciones tradicionales de lote y modalidad continua. Casi un año antes de presentar Storm como código abierto, la plataforma de computación de secuencia distribuida S4 de Yahoo! se volvió de código abierto para Apache. El release de S4 fue en octubre de 2010. Proporciona una plataforma de computación de alto rendimiento (HPC) que oculta la complejidad del procesamiento paralelo al desarrollador de aplicaciones. S4 implementa una arquitectura de clúster descentralizada escalable e incorpora tolerancia a fallas parcial.

Tabla 1. Soluciones de código abierto para big data
SoluciónDesarrolladorTipoDescripción
StormTwitterModalidad continuaNueva solución de analítica de big data de modalidad continua de Twitter
S4Yahoo!Modalidad continuaPlataforma de computación de secuencia distribuida de Yahoo!
HadoopApacheLotePrimer implementación de código abierto del paradigma de MapReduce
SparkUC Berkeley AMPLabLotePlataforma de analítica reciente que soporta conjuntos de datos en la memoria y tolerancia a fallas
DiscoNokiaLoteInfraestructura de MapReduce distribuida de Nokia
HPCCLexisNexisLoteClúster de HPC para big data

En avance

Aunque Hadoop continúa siendo la solución de analítica de big data más publicitada, existen muchas otras posibilidades, cada una con características diferentes. He explorado Spark en artículos anteriores. Incorpora posibilidades en memoria para conjuntos de datos (con la capacidad de volver a desarrollar los datos que se han perdido). Pero tanto Hadoop como Spark se enfocan en el procesamiento de lotes de grandes conjuntos de datos. Storm proporciona un nuevo modelo para analítica de big data y, como recientemente se volvió de código abierto, ha generado un interés considerable.

A diferencia de Hadoop, Storm es un sistema de computación y no incorpora un concepto de almacenamiento. Esto permite utilizar Storm en diversos contextos, ya sea que los datos lleguen dinámicamente desde un origen no tradicional o estén almacenados en un sistema de almacenamiento como una base de datos (o sean consumidos por un controlador para la manipulación en tiempo real de algún otro dispositivo, como un sistema de intercambio).

Vea Temas relacionados para obtener enlaces con más información sobre Storm, cómo hacer funcionar un clúster y otras soluciones de analítica de big data (de lote y de modalidad continua).


Recursos para Descargar


Temas relacionados

  • El procesamiento de eventos complejos es el patrón implementado por Storm y muchas otras soluciones, como S4 de Yahoo!. Una diferencia clave entre Storm y S4 es que Storm proporciona procesamiento de mensaje garantizado en caso de una falla, mientras que S4 puede perder mensajes.
  • Nathan Marz, el desarrollador clave detrás de Storm, ha escrito diversas introducciones interesantes y útiles para esta nueva oferta. El primer vistazo de Storm llegó en mayo de 2011 con Preview of Storm: The Hadoop of Realtime Processing - BackType Technology, seguido en agosto de A Storm is coming: more details and plans for release.
  • La wiki de Storm proporciona un gran conjunto de documentos sobre Storm, su razón de ser y una variedad de tutoriales sobre cómo obtener Storm y configurar un nuevo proyecto. También encontrará un conjunto útil de documentos sobre muchos aspectos de Storm, incluido el uso de Storm en la modalidad Local, en clústeres y en Amazon.
  • Spark, an alternative for fast data analytics (M. Tim Jones, developerWorks, noviembre de 2011) proporciona una introducción a la plataforma de analítica de datos con tolerancia a fallas en memoria de UC Berkeley.
  • Virtualización de aplicaciones , pasado y futuro (M. Tim Jones, developerWorks, mayo de 2011) detalla el uso de virtualización para abstracciones de lenguaje. Storm utiliza el lenguaje basado en VM Clojure para su implementación además de la tecnología Java y muchos otros lenguajes para desarrollar sus aplicaciones internas (bolt).
  • Existe un árbol de clases completo en GitHub para Storm que detalla sus clases e interfaces.
  • Hadoop ha comenzado a abordar modelos más allá del simple procesamiento por lotes. Por ejemplo, mediante la planificación, Hadoop puede alterar la forma en que procesa datos para enfocarse en la interactividad por encima del procesamiento de datos a nivel de lote. Aprenda más sobre la planificación de Hadoop en Scheduling in Hadoop (M. Tim Jones, developerWorks, diciembre de 2011).
  • ZeroMQ es la capa de transporte inteligente para mensajería eficaz en entornos escalables. En el sitio de ZeroMQ, puede aprender sobre la oferta, cómo usarla para solucionar problemas y también cómo dar soporte a este esfuerzo.
  • Apache Zookeeper es un proyecto de código abierto que habilita una coordinación distribuida altamente confiable. Storm utiliza Zookeeper para coordinar entre un conjunto de nodos dentro de un clúster.
  • Clojure es el lenguaje utilizado para implementar el sistema de Storm. Clojure es un derivado reciente del lenguaje de Lisp creado por Rich Hicky como lenguaje de propósito general que también simplifica la programación multihebras.
  • Apache Hadoop es la plataforma desarrollada por Yahoo! para programación de MapReduce. Recientemente, le siguió Spark de UC Berkeley como una oferta para big data tolerante a fallas en memoria y de código abierto desarrollada en Scala.
  • Además de Storm, hay muchas otras ofertas para big data disponibles como código abierto. S4 de Yahoo! es otra plataforma de big data basada en secuencias. Otras ofertas orientadas a lotes como Hadoop incluyen el proyecto Disco de Nokia y HPCC de LexisNexis.
  • Evalúe los productos de IBM de la forma que mejor se ajuste a usted: Descargue una prueba de producto, ensaye un producto en línea, use un producto en un entorno en nube, o pase algunas horas en el Recinto de seguridad SOA aprendiendo a implementar la Arquitectura Orientada a Servicios con eficiencia.
  • Siga a developerWorks en Twitter. También es posible seguir a este autor en Twitter en M. Tim Jones.

Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Big data y analytics, tecnologia Java, Linux
ArticleID=857684
ArticleTitle=Procese big data en tiempo real con Twitter Storm
publish-date=02112013