Compensaciones entre Storm y Hadoop (MapReduce)


12

¿Alguien puede decirme amablemente sobre las compensaciones involucradas al elegir entre Storm y MapReduce en Hadoop Cluster para el procesamiento de datos? Por supuesto, aparte del obvio, que Hadoop (procesamiento a través de MapReduce en un Hadoop Cluster) es un sistema de procesamiento por lotes, y Storm es un sistema de procesamiento en tiempo real.

He trabajado un poco con Hadoop Eco System, pero no he trabajado con Storm. Después de mirar muchas presentaciones y artículos, todavía no he podido encontrar una respuesta satisfactoria y completa.

Nota: El término compensación aquí no tiene el propósito de compararlo con cosas similares. Está destinado a representar las consecuencias de obtener resultados en tiempo real que están ausentes de un sistema de procesamiento por lotes.

Respuestas:


13

MapReduce : un marco computacional distribuido tolerante a fallas. MapReduce le permite operar sobre grandes cantidades de datos, con mucho trabajo para evitar fallas debido al hardware. MapReduce es una mala elección para calcular resultados sobre la marcha porque es lenta. (Un trabajo típico de MapReduce toma el orden de minutos u horas, no microsegundos)

Un trabajo de MapReduce toma un archivo (o algún almacén de datos) como entrada y escribe un archivo de resultados. Si desea que estos resultados estén disponibles para una aplicación, es su responsabilidad colocar estos datos en un lugar accesible. Es probable que esto sea lento, y habrá un desfase entre los valores que puede mostrar y los valores que representan su sistema en su estado actual.

Una distinción importante que debe hacerse al considerar el uso de MapReduce en la construcción de sistemas en tiempo real es la de entrenar su modelo y aplicar su modelo. Si cree que los parámetros de su modelo no cambian rápidamente, puede ajustarlos con MapReduce y luego tener un mecanismo para acceder a estos parámetros de ajuste previo cuando desee aplicar su modelo.

Storm : un sistema computacional de transmisión en tiempo real. Storm es un marco en línea, lo que significa, en este sentido, un servicio que interactúa con una aplicación en ejecución. A diferencia de MapReduce, recibe pequeños datos (no un archivo completo) a medida que se procesan en su aplicación. Defina un DAG de operaciones para realizar en los datos. Un caso de uso común y simple para Storm es el seguimiento de contadores y el uso de esa información para completar un tablero en tiempo real.

Storm no tiene nada (necesariamente) que ver con la persistencia de sus datos. Aquí, la transmisión es otra forma de decir que mantiene la información que le interesa y tira el resto. En realidad, es probable que tenga una capa de persistencia en su aplicación que ya haya registrado los datos, por lo que esta es una separación de preocupaciones buena y justificada.

Si desea saber más ... Si desea obtener más información sobre los sistemas en tiempo real que se ajustan a los parámetros con MR y aplican los modelos de una manera diferente, aquí hay diapositivas para una charla que di sobre la construcción de motores de recomendación en tiempo real en HBase

Un excelente artículo que combina el conteo y la persistencia en tiempo real de una manera interesante es la personalización de Google News: filtrado colaborativo en línea escalable

Otro matrimonio interesante de MR y Storm es SummingBird . Summingbird le permite definir operaciones de análisis de datos que se pueden aplicar a través de Storm o MR.


9

Esto es como preguntar sobre las compensaciones entre la sartén y el cajón de los cubiertos. No son dos cosas que comparas, en realidad. Puede usarlos juntos como parte de un proyecto más grande.

Hadoop en sí no es una cosa, sino un nombre para una federación de servicios, como HDFS, Hive, HBase, MapReduce, etc. Storm es algo que usa con algunos de estos servicios, como HDFS o HBase. Es un marco de procesamiento de flujo. Hay otros dentro del ecosistema extendido de Hadoop, como Spark Streaming.

¿Cuándo elegirías un marco de procesamiento de flujo? cuando necesita reaccionar a nuevos datos en tiempo casi real. Si necesita este tipo de herramienta, también implemente este tipo de herramienta.


Me referí al procesamiento a través de MapReduce en el sistema Hadoop Echo como simplemente Hadoop porque ese es el término comúnmente utilizado (aunque técnicamente es incorrecto y he cambiado la pregunta en consecuencia).
mbbce

Puede ser que esté equivocado, pero creo que hay más que solo tener un procesamiento casi en tiempo real. Si no hubiera compensaciones entre ellos, a todos les gustaría hacer las cosas en tiempo casi real. Un enfoque híbrido permite obtener lo mejor de ambos mundos (hasta cierto punto). Por eso se creó Summingbird.
mbbce 01 de

1
Una diferencia importante es que un sistema de procesamiento de flujo solo puede tocar datos una vez, y por sí solo no tiene un estado a largo plazo. Algunos problemas no se pueden resolver de esta manera. Para los problemas para los que esto está bien, es más rápido usar un sistema que no requiere primero datos persistentes en el almacenamiento (re-legible). MapReduce no es inherentemente más lento que Storm; Ambos son contenedores. Son diferentes paradigmas para diferentes problemas.
Sean Owen

Al no tener un estado persistente a largo plazo, ¿significa que tales sistemas casi en tiempo real no pueden acumular actualizaciones de entrada durante una larga duración? ¿Me puede referir a algún recurso que discuta más sobre esto?
mbbce

Esta es una especie de definición de un sistema de transmisión. Si imagina un sistema que puede acceder a un estado a largo plazo a voluntad, en realidad no está transmitiendo.
Sean Owen
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.