Compromis entre Storm et Hadoop (MapReduce)

12

Quelqu'un peut-il bien vouloir me parler des compromis impliqués lors du choix entre Storm et MapReduce dans Hadoop Cluster pour le traitement des données? Bien sûr, en dehors de l'évidence, Hadoop (traitement via MapReduce dans un cluster Hadoop) est un système de traitement par lots, et Storm est un système de traitement en temps réel.

J'ai un peu travaillé avec Hadoop Eco System, mais je n'ai pas travaillé avec Storm. Après avoir parcouru de nombreuses présentations et articles, je n'ai toujours pas trouvé de réponse satisfaisante et complète.

Remarque: Le terme compromis ici n'est pas destiné à être comparé à des choses similaires. Il est censé représenter les conséquences de l'obtention de résultats en temps réel qui sont absents d'un système de traitement par lots.

mbbce
la source

Réponses:

13

MapReduce : Un cadre de calcul distribué tolérant aux pannes. MapReduce vous permet d'opérer sur d'énormes quantités de données - avec beaucoup de travail pour éviter les pannes dues au matériel. MapReduce est un mauvais choix pour calculer les résultats à la volée car il est lent. (Un travail MapReduce typique prend de l'ordre des minutes ou des heures, pas des microsecondes)

Un travail MapReduce prend un fichier (ou un magasin de données) comme entrée et écrit un fichier de résultats. Si vous souhaitez que ces résultats soient disponibles pour une application, il est de votre responsabilité de placer ces données dans un endroit accessible. Ceci est probablement lent et il y aura un décalage entre les valeurs que vous pouvez afficher et les valeurs qui représentent votre système dans son état actuel.

Une distinction importante à faire lorsque vous envisagez d'utiliser MapReduce dans la construction de systèmes en temps réel est celle de la formation de votre modèle et de l'application de votre modèle. Si vous pensez que vos paramètres de modèle ne changent pas rapidement, vous pouvez les adapter avec MapReduce, puis disposer d'un mécanisme pour accéder à ces paramètres de pré-ajustement lorsque vous souhaitez appliquer votre modèle.

Storm : Un système de calcul en temps réel et en streaming. Storm est un framework en ligne, ce qui signifie, en ce sens, un service qui interagit avec une application en cours d'exécution. Contrairement à MapReduce, il reçoit de petites données (pas un fichier entier) lors de leur traitement dans votre application. Vous définissez un DAG d'opérations à effectuer sur les données. Un cas d'utilisation commun et simple pour Storm est le suivi des compteurs et l'utilisation de ces informations pour remplir un tableau de bord en temps réel.

Storm n'a rien (nécessairement) à voir avec la persistance de vos données. Ici, le streaming est une autre façon de dire garder les informations qui vous intéressent et jeter le reste. En réalité, vous avez probablement une couche de persistance dans votre application qui a déjà enregistré les données, et c'est donc une bonne et justifiée séparation des préoccupations.

Si vous voulez en savoir plus ... Si vous souhaitez en savoir plus sur les systèmes en temps réel qui ajustent les paramètres avec MR et appliquent les modèles d'une manière différente, voici des diapositives pour une conférence que j'ai donnée sur la construction de moteurs de recommandation en temps réel sur HBase.

Un excellent article qui allie le comptage en temps réel et la persistance de manière intéressante est la personnalisation de Google Actualités: filtrage collaboratif en ligne évolutif

Un autre mariage intéressant de MR et Storm est SummingBird . Summingbird vous permet de définir des opérations d'analyse de données qui peuvent être appliquées via Storm ou MR.

j_houg
la source
9

C'est un peu comme poser des questions sur les compromis entre la poêle et votre tiroir à couverts. Ce ne sont pas vraiment deux choses que vous comparez. Vous pouvez les utiliser ensemble dans le cadre d'un projet plus vaste.

Hadoop lui-même n'est pas une chose, mais un nom pour une fédération de services, comme HDFS, Hive, HBase, MapReduce, etc. Storm est quelque chose que vous utilisez avec certains de ces services, comme HDFS ou HBase. Il s'agit d'un cadre de traitement de flux. Il y en a d'autres au sein de l'écosystème Hadoop étendu, comme Spark Streaming.

Quand choisiriez-vous un framework de traitement de flux? lorsque vous devez réagir à de nouvelles données en temps quasi réel. Si vous avez besoin de ce type d'outil, vous déployez également ce type d'outil.

Sean Owen
la source
J'ai appelé le traitement via MapReduce dans le système Hadoop Echo simplement Hadoop parce que c'est le terme couramment utilisé (bien que techniquement incorrect et j'ai changé la question en conséquence).
mbbce
Je me trompe peut-être, mais je pense qu'il y a plus à cela que le simple traitement en temps réel. S'il n'y avait pas de compromis entre eux, tout le monde aurait aimé faire les choses en temps quasi réel. Une approche hybride permet de tirer le meilleur parti des deux mondes (dans une certaine mesure). C'est pourquoi Summingbird a été créé.
mbbce
1
Une différence majeure est qu'un système de traitement de flux peut simplement toucher les données une fois et n'a pas en soi d'état à long terme. Certains problèmes ne peuvent pas être résolus de cette façon. Pour les problèmes pour lesquels cela est OK, il est plus rapide d'utiliser un système qui ne nécessite pas au préalable des données persistantes dans un stockage (relisible). MapReduce n'est pas intrinsèquement plus lent que Storm; les deux sont des conteneurs. Ce sont des paradigmes différents pour différents problèmes.
Sean Owen
Le fait de ne pas avoir d'état persistant à long terme signifie-t-il que ces systèmes en temps quasi réel ne peuvent pas accumuler de mises à jour d'entrée sur une longue durée? Pouvez-vous me référer à des ressources qui discutent plus à ce sujet?
mbbce
C'est en quelque sorte la définition d'un système de streaming. Si vous imaginez un système qui peut accéder à volonté à long terme, ce n'est pas vraiment du streaming.
Sean Owen