Storm or Spark: choisissez votre arme en temps réel

L'idée de la Business Intelligence en temps réel existe depuis un certain temps (voir la page Wikipédia sur le sujet commencée en 2006). Mais alors que les gens parlent de l'idée depuis des années, je n'ai pas vu de nombreuses entreprises adopter la vision, encore moins réaliser les avantages qu'elle permet.

Au moins une partie de la raison est le manque d'outils pour mettre en œuvre la BI et l'analyse en temps réel. Les environnements traditionnels d'entreposage de données étaient fortement orientés vers les opérations par lots avec des latences extrêmement élevées, étaient incroyablement coûteux, ou les deux.

Un certain nombre de plates-formes open source puissantes et faciles à utiliser ont vu le jour pour changer cela. Deux des plus notables sont Apache Storm et Apache Spark, qui offrent des capacités de traitement en temps réel à un éventail beaucoup plus large d'utilisateurs potentiels. Les deux sont des projets au sein de l'Apache Software Foundation, et bien que les deux outils offrent des capacités qui se chevauchent, ils ont chacun des caractéristiques et des rôles distincts à jouer.

Storm: le Hadoop du traitement en temps réel

Storm, un cadre de calcul distribué pour le traitement des flux d'événements, a vu le jour sous la forme d'un projet de BackType, une société d'intelligence marketing rachetée par Twitter en 2011. Twitter a rapidement ouvert le projet et l'a mis sur GitHub, mais Storm a finalement déménagé vers l'incubateur Apache. et est devenu un projet de premier niveau Apache en septembre 2014.

Storm a parfois été appelé le Hadoop du traitement en temps réel. La documentation Storm semble concorder: "Storm facilite le traitement fiable de flux de données illimités, faisant pour le traitement en temps réel ce que Hadoop a fait pour le traitement par lots."

Pour atteindre cet objectif, Storm est conçu pour une évolutivité massive, prend en charge la tolérance aux pannes avec une approche «échec rapide, redémarrage automatique» des processus et offre une solide garantie que chaque tuple sera traité. Storm utilise par défaut une garantie «au moins une fois» pour les messages, mais offre également la possibilité de mettre en œuvre un traitement «exactement une fois».

Storm est principalement écrit en Clojure et est conçu pour prendre en charge le câblage des «jets» (pensez aux flux d'entrée) et des «boulons» (modules de traitement et de sortie) ensemble sous la forme d'un graphe acyclique dirigé (DAG) appelé topologie. Les topologies Storm s'exécutent sur des clusters et le planificateur Storm distribue le travail aux nœuds autour du cluster, en fonction de la configuration de la topologie.

Vous pouvez considérer les topologies comme à peu près analogues à une tâche MapReduce dans Hadoop, sauf que, étant donné que Storm se concentre sur le traitement en temps réel basé sur le flux, les topologies par défaut s'exécutent pour toujours ou jusqu'à ce qu'elles soient terminées manuellement. Une fois qu'une topologie est démarrée, les becs apportent des données dans le système et les transmettent aux boulons (qui peuvent à leur tour transmettre les données aux boulons suivants) où le travail de calcul principal est effectué. Au fur et à mesure que le traitement progresse, un ou plusieurs boulons peuvent écrire des données dans une base de données ou un système de fichiers, envoyer un message à un autre système externe ou rendre les résultats du calcul disponibles pour les utilisateurs.

L'une des forces de l'écosystème Storm est une riche gamme de becs disponibles spécialisés pour recevoir des données de tous types de sources. Bien que vous deviez peut-être écrire des spouts personnalisés pour des applications hautement spécialisées, il y a de fortes chances que vous puissiez trouver un spout existant pour une incroyablement grande variété de sources - de l'API de streaming Twitter à Apache Kafka en passant par les courtiers JMS et tout le reste.

Des adaptateurs existent pour faciliter l'intégration avec les systèmes de fichiers HDFS, ce qui signifie que Storm peut facilement interagir avec Hadoop si nécessaire. Une autre force de Storm est sa prise en charge de la programmation multilingue. Alors que Storm lui-même est basé sur Clojure et fonctionne sur la JVM, les spouts et les boulons peuvent être écrits dans presque tous les langages, y compris les langages non JVM qui tirent parti d'un protocole de communication entre les composants utilisant JSON sur stdin / stdout.

En bref, Storm est un système open source très évolutif, rapide et tolérant aux pannes pour le calcul distribué, avec un accent particulier sur le traitement de flux. Storm excelle dans le traitement d'événements et le calcul incrémentiel, calculant des métriques glissantes en temps réel sur des flux de données. Alors que Storm fournit également des primitives pour activer le RPC distribué générique et peut théoriquement être utilisé pour assembler presque n'importe quel travail de calcul distribué, sa force est clairement le traitement des flux d'événements.

Spark: traitement distribué pour tous

Spark, un autre projet adapté au calcul distribué en temps réel, a débuté comme un projet d'AMPLab à l'Université de Californie à Berkeley avant de rejoindre l'incubateur Apache et finalement d'obtenir son diplôme en tant que projet de haut niveau en février 2014. Comme Storm, Spark prend en charge stream - traitement orienté, mais il s'agit plutôt d'une plate-forme informatique distribuée à usage général.

En tant que tel, Spark peut être considéré comme un remplacement potentiel des fonctions MapReduce de Hadoop, tandis que Spark a la capacité de s'exécuter au-dessus d'un cluster Hadoop existant, en s'appuyant sur YARN pour la planification des ressources. En plus de Hadoop YARN, Spark peut se superposer au-dessus de Mesos pour la planification ou s'exécuter en tant que cluster autonome à l'aide de son planificateur intégré. Notez que si Spark n'est pas utilisé avec Hadoop, un type de système de fichiers réseau / distribué (NFS, AFS, etc.) est toujours requis s'il est exécuté sur un cluster, de sorte que chaque nœud aura accès aux données sous-jacentes.

Spark est écrit en Scala et, comme Storm, prend en charge la programmation multilingue, bien que Spark ne fournisse une prise en charge API spécifique que pour Scala, Java et Python. Spark n'a pas l'abstraction spécifique d'un «spout», mais inclut des adaptateurs pour travailler avec des données stockées dans de nombreuses sources disparates, y compris les fichiers HDFS, Cassandra, HBase et S3.

Là où Spark brille, c'est dans sa prise en charge de plusieurs paradigmes de traitement et des bibliothèques de prise en charge. Oui, Spark prend en charge un modèle de streaming, mais cette prise en charge est fournie par un seul des nombreux modules Spark, y compris des modules spécialement conçus pour l'accès SQL, les opérations graphiques et l'apprentissage automatique, ainsi que le traitement de flux.

Spark fournit également un shell interactif extrêmement pratique qui permet un prototypage rapide et une analyse exploratoire des données en temps réel à l'aide des API Scala ou Python. En travaillant dans le shell interactif, vous remarquez rapidement une autre différence majeure entre Spark et Storm: Spark a plus une saveur «fonctionnelle», où le travail avec l'API est davantage guidé par le chaînage d'appels de méthode successifs pour appeler des opérations primitives - par opposition à la Modèle Storm, qui a tendance à être piloté par la création de classes et l'implémentation d'interfaces. Aucune des deux approches n'est meilleure ou pire, mais le style que vous préférez peut influencer votre décision sur le système le mieux adapté à vos besoins.

Comme Storm, Spark est conçu pour une évolutivité massive, et l'équipe Spark a documenté les utilisateurs du système exécutant des clusters de production avec des milliers de nœuds. De plus, Spark a remporté le récent concours Daytona GraySort 2014, remportant le meilleur moment pour une charge de travail époustouflante consistant à trier 100 To de données. L'équipe Spark documente également les opérations Spark ETL avec des charges de travail de production dans la plage de plusieurs pétaoctets.

Spark est une plate-forme informatique distribuée open source rapide, évolutive et flexible, compatible avec Hadoop et Mesos, qui prend en charge plusieurs modèles de calcul, notamment le streaming, les opérations centrées sur les graphiques, l'accès SQL et l'apprentissage automatique distribué. Spark a été documenté pour évoluer exceptionnellement bien et, comme Storm, est une excellente plate-forme sur laquelle créer un système d'analyse et de veille stratégique en temps réel.

Prendre votre décision

Comment choisissez-vous entre Storm et Spark?

Si vos besoins sont principalement axés sur le traitement de flux et le traitement de style CEP et que vous démarrez un projet greenfield avec un cluster spécialement conçu pour le projet, je préférerais probablement Storm - en particulier lorsque des becs Storm existants qui correspondent à vos exigences d'intégration sont disponibles. . Ce n'est en aucun cas une règle stricte et rapide, mais de tels facteurs suggéreraient au moins de commencer par Storm.

D'un autre côté, si vous exploitez un cluster Hadoop ou Mesos existant et / ou si vos besoins de traitement impliquent des exigences substantielles pour le traitement des graphiques, l'accès SQL ou le traitement par lots, vous voudrez peut-être commencer par regarder Spark.

Un autre facteur à considérer est la prise en charge multilingue des deux systèmes. Par exemple, si vous avez besoin d'exploiter du code écrit en R ou dans tout autre langage non pris en charge nativement par Spark, Storm a l'avantage d'une prise en charge plus large du langage. De même, si vous devez disposer d'un shell interactif pour l'exploration de données à l'aide d'appels d'API, Spark vous propose une fonctionnalité que Storm ne propose pas.

En fin de compte, vous voudrez probablement effectuer une analyse détaillée des deux plates-formes avant de prendre une décision finale. Je recommande d'utiliser les deux plates-formes pour créer une petite preuve de concept, puis exécutez vos propres benchmarks avec une charge de travail qui reflète aussi étroitement que possible vos charges de travail anticipées avant de vous engager pleinement dans l'une ou l'autre.

Bien sûr, vous n'avez pas besoin de prendre une décision soit / soit. En fonction de vos charges de travail, de votre infrastructure et de vos exigences, vous constaterez peut-être que la solution idéale est un mélange de Storm et Spark, ainsi que d'autres outils tels que Kafka, Hadoop, Flume, etc. C'est là que réside la beauté de l'open source.

Quel que soit l'itinéraire choisi, ces outils démontrent que le jeu de BI en temps réel a changé. Des options puissantes autrefois disponibles uniquement pour une élite limitée sont désormais à la portée de la plupart, sinon de toutes, des entreprises de taille moyenne à grande. Profitez-en.