Apache Storm

Introduction

« La technologie de l’information a changé la façon dont les gens créent de la valeur économique. » de Alan Greenspan, l’ancien président de la Réserve fédérale, la banque centrale des États-Unis.

Les entreprises de réseaux sociaux, comme on les appelle communément, font partie des premières entreprises qui ont ressenti le besoin de gérer efficacement les données générées par l’accroissement de l’activité sur Internet. Leur activité économique étant fondée sur la capitalisation des données produites par leurs utilisateurs, il était urgent qu’elles développent des technologies capables de gérer les données à grande échelle. La vitesse de création de données, qui est à la base du phénomène qu’on qualifie aujourd’hui de « streaming », a amplifié cette urgence. En réalité, le streaming n’est pas un phénomène qui concerne juste le traitement en temps réel des données, il concerne deux problématiques : l’ingestion de données en temps réel, voire de gros volumes de données,et le traitement immédiat de ces données. Ainsi, s’attaquer...

Définition de Storm

Storm est un environnement de développement et un moteur de déploiement de calcul distribué des données streaming sur un cluster. Il fournit deux modèles de développements d’applications. Le premier modèle, communément appelé "Storm classique", déploie les applications sous forme de graphe acyclique direct appelé topologie. Les données streaming qui viennent des sources telles que Kafka ou Hadoop, ou de toute autre source produisant les données streaming, sont exposées sur un composant de la topologie appelé dans le jargon Storm "spout". Chaque source de données est exposée sur un spout différent. Ces spouts passent ensuite les données à des nœuds ou unités de calcul de la topologie appelés dans le jargon Storm des "bolts". Les bolts transforment les données selon un ensemble d’opérations définies par le développeur. Un bolt fait deux choses : soit il persiste les données dans un support de stockage, soit il leur applique des transformations spécifiques et passe le résultat de ces transformations à d’autres bolts. On peut donc voir une topologie comme une chaîne de bolts appliqués sur des données exposées par des spouts. Les bolts sont distribués...

Fonctionnement de Storm

Storm fonctionne sur un cluster maître/esclave. Le nœud Maître est responsable de la distribution des calculs dans le cluster, de l’assignation des tâches aux nœuds esclaves, et du suivi des pannes, tandis que les nœuds esclaves sont responsables de l’exécution des calculs. La mise en production d’un cluster Storm demande trois composants : Nimbus, les superviseurs et ZooKeeper.

Nimbus est le processus central d’un cluster Storm. Il tourne au niveau du nœud Maître et c’est lui qui est responsable de la distribution et de l’assignation des tâches (soit les spouts, soit les bolts) aux nœuds du cluster. Il est également responsable du rééquilibrage des charges en cas de défaillance dans le cluster et du suivi de l’exécution des topologies dans les nœuds du cluster. À première vue, Nimbus peut apparaître comme un point de défaillance unique, au même titre que le jobtracker ou le nœud de référence dans un cluster Hadoop traditionnel. Mais ce n’est pas vraiment le cas, car lorsque Nimbus tombe en panne, les topologies continuent de s’exécuter sans aucun problème. Ceci est possible parce qu’à la différence du jobtracker ou du nœud de référence dans un cluster Hadoop, Nimbus n’est pas directement...

Topologies

Les topologies sont pour Storm ce qu’est le MapReduce pour Hadoop. Pour faire plus simple, la topologie est le modèle de calcul de Storm. Il est indispensable que vous compreniez la philosophie qu’il y a derrière les topologies pour savoir comment utiliser Storm.

1. Philosophie et fonctionnement des topologies

La topologie, est le mécanisme par lequel Storm traite les données. Une topologie est un graphe acyclique direct dans lequel les vertices, ou nœuds, sont soit des spouts, soit des bolts. Là où le graphe acyclique direct du MapReduce est limité à trois étapes, une topologie Storm peut contenir plusieurs étapes. La seule ressemblance qu’il y a entre les deux modèles de calcul est que la topologie est également un graphe acyclique, c’est-à-dire non itératif (pour en savoir plus sur les graphes, voir le chapitre MapReduce, section Tez : le moteur d’optimisation du MapReduce).

La figure ci-après illustre la singularité du graphe acyclique direct de la topologie.

Figure 56 : Exemple de topologie Storm. À la différence du MapReduce, la topologie n’a pas un nombre fini d’étapes. Il peut y avoir un spout, puis un bolt, puis un autre spout, et ainsi de suite, tandis que dans le MapReduce, il y a un Map, puis un Reduce.

L’exécution d’une topologie par Storm commence toujours par un spout. Le spout représente la source de données streaming. Dans le spout, les données streaming sont transformées en tuples. Les tuples sont l’équivalent Storm des lignes d’une table. Ces tuples sont partitionnés en lots, chaque lot est envoyé à un ou plusieurs bolts, et ces bolts sont répartis sur le cluster. Storm propose plusieurs façons de partitionner les tuples :...

Utilisation de Storm

Développer une application Storm consiste à décrire et implémenter une ou plusieurs topologies. Une topologie Storm peut être considérée comme le plan d’exécution d’une requête SQL pour un SGBDR. Du coup, la description d’une topologie par le développeur consiste à écrire le plan d’exécution du problème de calcul en temps réel sous forme de chaîne de spouts et de bolts. Le développeur spécifie également le nombre d’instances ou de tâches pour chaque spout et bolt à déployer de façon parallèle dans le cluster. Au moment de la rédaction de ce livre, Apache travaille sur l’assignation et le changement automatique par Storm de ce nombre sur la base d’un objectif de performance. Après cela, Storm crée les instances et les interconnexions du flux de la topologie. Par exemple, le plan d’exécution physique de la topologie de décompte des tweets de la figure 53 est illustré à la figure 57.

Notez que les topologies Storm ont un paramètre Max Spout Pending (nombre de spouts maximum) qui place une limite sur le nombre de tuples qui peuvent manquer dans la topologie à tout point dans le temps. Ce paramètre est l’un des paramètres fondamentaux de la topologie, car Storm utilise un système de messagerie publish/subscribe ZeroMQ pour transférer les tuples d’une tâche bolt ou spout à une autre. Si le consommateur de ZeroMQ est incapable de suivre le rythme de transfert des tuples, alors...

Storm et Hadoop

Il existe deux façons de combiner Storm et Hadoop : Storm-YARN et l’architecture λ.

1. Storm-YARN

En fait, il n’existe pas de relation directe entre Storm et Hadoop. Hadoop s’appuie sur le MapReduce pour effectuer des traitements batch, tandis que Storm s’appuie sur des topologies pour effectuer des calculs en temps réel. Hadoop n’est pas directement utilisé pour le traitement streaming, bien que dans certains cas, Storm utilise le HDFS pour le stockage ou la réception des données. Mais lorsque c’est le cas, les deux sont généralement dans deux clusters séparés. Gardez à l’esprit qu’un problème streaming ne se gère pas à l’aide d’une seule technologie. Storm est seulement un composant dans une architecture informatique de streaming temps réel. C’est le composant chargé du calcul à faible latence. Il est néanmoins vrai que rapprocher Storm et tous les autres composants de l’architecture de traitement streaming temps réel dans le même cluster permettrait de réduire le coût de transfert des données entre les composants de l’architecture. Yahoo! a rendu ce rapprochement possible grâce à Storm-YARN, une application qui permet de faire tourner Storm dans le même cluster qu’Hadoop à l’aide du YARN (voir le chapitre Futur d’Hadoop : limites d’Hadoop et YARN). Le YARN est un gestionnaire de ressources qui permet de faire tourner plusieurs types d’applications et de modèles de calcul dans le même cluster Hadoop. Storm-YARN offre l’élasticité nécessaire en termes de ressources pour les traitements streaming temps réel (des liens à ce sujet sont fournis au chapitre/annexe Liens et référence utiles).

La figure suivante illustre l’architecture et le fonctionnement d’un cluster avec Storm-YARN.

Figure 60 : Architecture et fonctionnement de Storm-YARN.

Lors de la soumission d’une topologie pour exécution, celle-ci passe par le client Storm-YARN, qui fait la requête au Resource Manager afin qu’il lance le Storm Application master. Le Storm Application master lance ensuite un serveur Nimbus et un serveur d’interface utilisateur. Storm-YARN va également...

Conclusion

Lorsqu’on parle de « streaming » ou de « streaming temps réel », techniquement on fait référence à deux problématiques : l’ingestion des données produites avec une périodicité égale ou inférieure à la seconde, et le traitement immédiat de ces données ou traitement en temps réel. Grâce à un mode de développement modulaire, la fondation Apache offre des outils qui permettent de construire des systèmes informatiques complets, de l’ingestion au traitement. Apache Storm est l’un des outils du traitement en temps réel. Grâce à des outils comme Storm, les traitements métier (rédaction des topologies) sont séparés des traitements informatiques tels que la gestion des pannes, la distribution des calculs, et laissent les utilisateurs se focaliser sur les problématiques métier. Par là, ils rendent le calcul streaming, jusque-là réservé à des experts, accessible à une majorité d’utilisateurs métier et ajoute à Hadoop la capacité à résoudre des problématiques pour lesquelles il n’était pas originellement conçu. Cela favorise l’adoption plus globale d’Hadoop en entreprise et contribue à l’établir...

À retenir