Apache Storm est un framework de calcul de traitement de flux distribué, écrit principalement dans le langage de programmation Clojure . Créé à l'origine par Nathan Marz et l'équipe de BackType, qui a été acquis par Twitter, Storm utilise des "spouts" et des "bolts" créés sur mesure pour définir les sources d'informations et les manipulations permettant un traitement par lots et distribué des données en continu. Le projet est rendu open source après cette acquisition (la première publication a eu lieu le 17 septembre 2011). Storm est devenu un projet de premier niveau de la fondation Apache Software en 2014 et est inclus dans toutes les principales distributions Hadoop.
Une application Storm est conçue comme une "topologie" sous la forme d'un graphe acyclique dirigé (DAG) avec des spouts et des bolts faisant office de sommets du graphe. Les bords du graphique sont des flux nommés et dirigent les données d'un nœud à un autre. Ensemble, la topologie agit comme un pipeline de transformation de données. À un niveau superficiel, la structure topologique générale est similaire à un travail MapReduce , la principale différence étant que les données sont traitées en temps réel par opposition à des lots individuels. De plus, les topologies Storm s'exécutent indéfiniment jusqu'à ce qu'elles soient supprimées, tandis qu'un DAG de travail MapReduce doit finir
Les développeurs reçoivent une série de “spouts” (pour se connecter aux sources de données et injecter les données dans un flux) et de “bolts” (qui traitent les données entrantes et émettent de nouvelles données) qui peuvent être utilisés pour traiter les données de certaines manières.
La structure peut être utilisée pour développer différents types d’applications, notamment l’analyse en temps réel, l’apprentissage automatique en ligne, le calcul continu et les charges de travail d’extraction, de transformation et de chargement (ETL).
Les avantages de Storm incluent la vitesse et la flexibilité. Il a été synchronisé pour traiter plus d’un million de n-uplets par seconde et par nœud, selon la page Web Storm, qui indique également « qu’une topologie Storm utilise des flux de données et les traite de manière arbitraire et complexe ».
Nouvelle architecture implémentée en Java
Dans les versions précédentes, une grande partie de la fonctionnalité principale de Storm était implémentée en Clojure. L’architecture de Storm 2.0.0 a été retravaillé et ses fonctionnalités principales ont été implémentées en Java pur. La nouvelle implémentation basée sur Java a considérablement amélioré les performances et rendu les API internes de Storm plus faciles à gérer et à développer. L’implémentation de Storm en Clojure a bien fonctionné pendant de nombreuses années, mais cela a souvent été cité comme un obstacle à l'entrée de nouveaux contributeurs. La base de code de Storm est maintenant plus accessible aux développeurs qui ne veulent pas apprendre Clojure pour pouvoir contribuer.
Nouveau noyau haute performance
Storm 2.0.0 introduit un nouveau noyau comprenant un modèle de thread plus léger, un sous-système de messagerie ultra rapide et un modèle de contre-pression léger. Il est conçu pour repousser les limites en termes de débit, de latence et de consommation d'énergie, tout en maintenant la compatibilité descendante. La conception a été motivée par le constat que le matériel existant reste capable de beaucoup plus que ce que les meilleurs moteurs de streaming peuvent fournir. D’après la note de version, Storm 2.0 est le premier moteur de diffusion en continu à dépasser la barrière de latence de 1 microseconde.
Nouvelles API Streams
Storm 2.0.0 introduit une nouvelle API typée pour exprimer plus facilement les calculs en continu à l'aide d'opérations de style fonctionnel. Il repose sur les principaux API spout et bolt de Storm et fusionne automatiquement plusieurs opérations pour optimiser le pipeline.
Améliorations du fenêtrage
L'API de fenêtrage de Storm 2.0.0 peut enregistrer / restaurer l'état de la fenêtre dans le backend d'état configuré afin que des fenêtres continues plus grandes puissent être prises en charge. Les limites de la fenêtre sont désormais accessibles via les API.
Changements apporté aux intégrations Kafka
Suppression de Storm-Kafka
Le changement le plus important intervenu dans l'intégration de Storm à Kafka depuis la version 1.x est que Storm-kafka a été supprimé. Le module est obsolète depuis un certain temps en raison de la dépréciation de Kafka de la bibliothèque client sous-jacente. Les utilisateurs devront passer au module storm-kafka-client, qui utilise la bibliothèque Kafka-clients de Kafka pour son intégration.
Pour l’essentiel, la migration vers storm-kafka-client est simple. La documentation de storm-kafka-client contient un mappage utile entre les anciennes et les nouvelles configurations spouts. Si vous utilisez l'un des spouts Storm-Kafka, vous devrez migrer les points de contrôle de l'offset vers le nouveau spout afin d'éviter que le nouveau spout ne recommence à zéro sur vos partitions. Storm fournit un outil d'aide pour le faire (voir plus bas).
Lorsque vous effectuez une migration, vous devez arrêter votre topologie, exécuter l'outil de migration, puis redéployer votre topologie avec le spout storm-kafka-client.
Migrer vers l'utilisation de l'API KafkaConsumer.assign
Storm-kafka-client dans Storm 1.x vous a permis d'utiliser le propre mécanisme de Kafka pour gérer les tâches de spouts qui étaient responsables de quelles partitions. Ce mécanisme convenait mal à Storm et était déconseillé dans 1.2.0. Il a été entièrement supprimé en 2.0.
L'interface d'abonnement storm-kafka-client a également été supprimée. Il offrait un contrôle trop limité sur le comportement de l'abonnement. Il a été remplacé par les interfaces TopicFilter et ManualPartitioner. À moins que vous n'utilisiez une implémentation d'abonnement personnalisée, cela ne vous affectera probablement pas. Si vous utilisiez un abonnement personnalisé, la documentation de storm-kafka-client explique comment personnaliser l'attribution.
outil d'aide
Source : note de version
Et vous ?
Avez-vous déjà utilisé Apache Storm ? Qu'en pensez-vous ?
Avez-vous déjà utilisé un produit concurrent ? Lequel préférez-vous ? Pourquoi ?
Le fait de réécrire l'architecture en Java est-il susceptible d'attire plus de contributeurs ?
Voir aussi :
Apache Software Foundation rejoint la communauté open source de GitHub et met fin à son propre service git
L'Apache Software Foundation annonce NetBeans en tant que projet de premier niveau, l'EDI est donc à la fin de sa phase d'incubation
Western Digital libère son cœur de calcul SweRV sous licence Apache 2, afin de participer à l'écosystème RISC-V
Azure : Microsoft annonce le support d'Apache Storm dans HDInsight, une fonctionnalité qui renforce les capacités d'analyses des flux de données
Apache Storm 2.0.0 est disponible : l'architecture du moteur de traitement de flux a été réécrite en Java
Pour attirer plus de contributeurs
Apache Storm 2.0.0 est disponible : l'architecture du moteur de traitement de flux a été réécrite en Java
Pour attirer plus de contributeurs
Le , par Stéphane le calme
Une erreur dans cette actualité ? Signalez-nous-la !