Ya hemos dedicado los suficientes posts como para estar convencidos de que Hadoop es un producto adecuado para hacer el procesamiento batch actuando como un data warehouse escalable y distribuido.
En otros casos tenemos flujos de datos que se desean procesar según llegan. En estos casos entra en juego Storm: Storm es un framework para procesar streams de forma distribuida, o por decirlo en palabras BigData, el Hadoop de flujos de datos.
En Hadoop la unidad de ejecución es MapReduce: Los flujos de trabajo se programan directamente en MapReduce o traducidos de scripts Pig o queries Hive.
En Storm las correspondientes unidades de ejecución son Spouts y Bolts. Los Spouts son las fuentes de datos y los Bolts. Las conexiones entre Spouts y Bolts y entre los Bolts tienen configuraciones propias para indicar como el strem se divide entre los "hilos" de ejecución. En terminología Storm cada "hilo" es una instancia independiente paralelo de un Bolt.
Un conjunto de Spouts y Bolts se organizan en una topología DAG (Directed Acyclic Graph). En Hadoop un flujo de trabajo se traduce a menudo en un conjunto secuencial de Maps y Reduce jobs.
Storm permite explicitar esto. Storm elimina los Single Points of Failure (SPOFs) de Hadoop de modo que es realmente tolerante a fallos.
Si habéis entendido algo de lo que digo habréis encontrado bastante similitudes con un CEP (Complex Event Processing), de hecho ambas tecnologías resuelven los mismos casos de uso.
La principal diferencia radica en la arquitectura. Storm es una tecnología paralela que se ejecute en un clúster de máquinas y soporta escalado horizontal infinito.
Storm es compatible con los principales lenguajes de programación (Java, Python,…) y no requiere aprender una nueva tecnología.
Poría verse a Storm como una evolución de los CEPs, que elimina los defectos arquitectónicos que llevaron a CEP a no progresar tanto como se esperaba.
Un poco de Java 
Deja un comentario