Où Apache Samza et Apache Storm diffèrent dans leurs cas d'utilisation?
Je suis tombé sur cet article qui prétend faire contraste Samza avec Storm, mais il semble ne traiter que les détails de l'implémentation.
Où ces deux moteurs de calcul distribués diffèrent-ils dans leurs cas d'utilisation? Pour quel type d'emploi chaque outil est-il bon?
La plus grande différence entre Apache Storm et Apache Samza se résume à la façon dont ils diffusent les données pour les traiter.
Apache Storm effectue le calcul en temps réel à l'aide de la topologie et il alimente un cluster où le nœud maître distribue le code entre les nœuds de travail qui l'exécutent. Dans la topologie, les données sont transmises entre des spouts qui crachent des flux de données sous forme d'ensembles immuables de paires clé-valeur.
Voici l'architecture d'Apache Storm: 
Apache Samza diffuse en traitant les messages au fur et à mesure. Les flux sont divisés en partitions qui sont une séquence ordonnée où chacun a un ID unique. Il prend en charge le traitement par lots et est généralement utilisé avec YARN de Hadoop et Apache Kafka.
Voici l'architecture d'Apache Samza: 
En savoir plus sur les façons spécifiques dont chacun des systèmes exécute les spécificités ci-dessous.
CAS D'UTILISATION
Apache Samza a été créé par LinkedIn.
Un ingénieur logiciel a écrit ne publication :
Il est en production chez LinkedIn depuis plusieurs années et fonctionne actuellement sur des centaines de machines dans plusieurs centres de données. Notre plus grand travail Samza traite plus de 1 000 000 de messages par seconde pendant les heures de pointe du trafic.
Ressources utilisées:
Eh bien, j'examine ces systèmes depuis quelques mois, et je ne pense pas qu'ils diffèrent profondément dans leurs cas d'utilisation. Je pense qu'il vaut mieux les comparer dans ce sens:
- Age: Storm est le projet le plus ancien et l'original dans cet espace, il est donc généralement plus mature et testé au combat. Samza est un projet de deuxième génération plus récent qui semble éclairé par les leçons tirées de Storm.
- Kafka: Samza est issu de l'écosystème Kafka et est très centré sur Kafka. Par exemple, la documentation indique qu'ils permettre de brancher différents systèmes de messagerie ... tant qu'ils fournissent un partitionnement, un ordre et une relecture sémantiques similaires à Kafka le fait. Storm, étant un système plus ancien, n'est pas si spécialisé pour travailler avec Kafka .
- Complexité: Samza, en partie parce qu'il fait des hypothèses plus fortes sur son environnement ("vous pouvez avoir n'importe quelle infrastructure que vous aimez tant qu'il fonctionne comme Kafka") et en partie parce que c'est juste plus récent, me semble généralement plus simple que Storm, dans le bon sens. Mais une façon peut-être moins bonne que Samza est plus simple est qu'il manque (délibérément?) Le concept de Storm de topologies ( graphiques d'exécution complexes). Si vous avez besoin d'un processeur complexe à plusieurs étapes, il doit être implémenté en tant que tâches indépendantes qui communiquent via Kafka. Cela présente des avantages ainsi que des inconvénients, mais Samza rend le choix pour vous alors que Storm vous offre plus d'options.
- Gestion des états: De nombreuses applications Storm doivent utiliser un magasin externe comme Redis lorsqu'elles doivent maintenir un grand volume d'état pour traiter les tuples entrants. Cette situation semble être l'une des principales raisons qui ont motivé la conception de Samza; l'une des caractéristiques les plus distinctives de Samza est qu'il fournit à ses tâches leur propre magasin de clés/valeur sur disque local à utiliser à cette fin s'ils en ont besoin.
Voici un article de Tony Siciliani qui fournit une comparaison de cas d'utilisation (et d'architecture) pour Storm, Spark et Samza. Des liens Apache.org vers des cas d'utilisation réels sont également fournis ci-dessous.
https://tsicilian.wordpress.com/2015/02/16/streaming-big-data-storm-spark-and-samza/
Concernant les cas d'utilisation de Samza et Storm, il écrit:
Les trois cadres sont particulièrement bien adaptés pour traiter efficacement des quantités massives et continues de données en temps réel. Alors lequel utiliser? Il n'y a pas de règles strictes, tout au plus quelques directives générales.
Apache Samza
Si vous avez un grand nombre d’états avec lesquels travailler (par exemple, plusieurs gigaoctets par partition), Samza colocalise le stockage et le traitement sur les mêmes machines, ce qui permet de travailler efficacement avec un état qui ne fonctionne pas). tenir dans la mémoire. Le cadre offre également de la flexibilité avec son API enfichable: ses moteurs d'exécution, de messagerie et de stockage par défaut peuvent chacun être remplacés par votre choix d'alternatives. De plus, si vous avez un certain nombre d'étapes de traitement des données de différentes équipes avec différentes bases de code, Samza seraient particulièrement bien adaptés, car ils peuvent être ajoutés/supprimés avec un minimum d'ondulations).
Quelques entreprises utilisant Samza: LinkedIn, Intuit, Metamarkets, Quantiply, Fortscale…
Liste de cas d'utilisation de Samza: https://cwiki.Apache.org/confluence/display/SAMZA/Powered+By
Apache Storm
Si vous voulez un système de traitement d'événements à grande vitesse qui permette des calculs incrémentiels, Storm conviendrait parfaitement. Si vous devez en outre exécuter des calculs distribués à la demande, pendant que le client attend les résultats de manière synchrone, vous aurez le RPC distribué (DRPC) prêt à l'emploi. Enfin, parce que Storm utilise Apache Thrift, vous pouvez écrire des topologies dans n'importe quel langage de programmation. Si vous avez besoin de la persistance de l'état et/ou d'une livraison en une seule fois, vous devriez regarder l'API Trident de niveau supérieur, qui propose également le micro-batch.
Quelques entreprises utilisant Storm: Twitter, Yahoo !, Spotify, The Weather Channel…
Liste de cas d'utilisation Storm: http://storm.Apache.org/documentation/Powered-By.html