Quelle est la "tâche" du parallélisme Storm
J'essaie d'apprendre la tempête Twitter en suivant le grand article " Comprendre le parallélisme d'une topologie Storm "
Cependant, je suis un peu confus par le concept de "tâche". Une tâche est-elle une instance en cours d'exécution du composant (bec ou boulon)? Un exécuteur exécutant plusieurs tâches dit en fait que le même composant est exécuté plusieurs fois par l'exécuteur, ai-je raison?
De plus, dans un sens général de parallélisme, Storm engendrera un thread dédié (exécuteur) pour un bec ou un boulon, mais ce qui est contribué au parallélisme par un exécuteur (thread) ayant plusieurs tâches ? Je pense que le fait d'avoir plusieurs tâches dans un thread, puisqu'un thread s'exécute séquentiellement, ne fait que du thread une sorte de ressource "en cache", ce qui évite de générer un nouveau thread pour la prochaine exécution de la tâche. Ai-je raison?
Je vais peut-être effacer ces confusions après avoir pris plus de temps pour enquêter, mais vous savez, nous aimons tous les deux stackoverflow ;-)
Merci d'avance.
Avis de non-responsabilité: j'ai écrit l'article que vous avez mentionné dans votre question ci-dessus.
Cependant, je suis un peu confus par le concept de "tâche". Une tâche est-elle une instance en cours d'exécution du composant (bec ou boulon)? Un exécuteur exécutant plusieurs tâches dit en fait que le même composant est exécuté plusieurs fois par l'exécuteur, ai-je raison?
Oui et oui.
De plus, dans un sens général de parallélisme, Storm engendrera un thread dédié (exécuteur) pour un bec ou un boulon, mais qu'est-ce qui contribue au parallélisme par un exécuteur (thread) ayant plusieurs tâches?
L'exécution de plusieurs tâches par exécuteur n'augmente pas le niveau de parallélisme - un exécuteur a toujours un thread qu'il utilise pour toutes ses tâches, ce qui signifie que les tâches s'exécutent en série sur un exécuteur.
Comme je l'ai écrit dans l'article, veuillez noter que:
- Le nombre de threads d'exécuteur peut être modifié après le démarrage de la topologie (voir
storm rebalancecommande). - Le nombre de tâches d'une topologie est statique.
Et par définition, il y a l'invariant de #executors <= #tasks.
Par conséquent, l'une des raisons pour lesquelles 2 tâches ou plus sont exécutées par thread exécuteur est de vous donner la flexibilité nécessaire pour étendre/faire évoluer la topologie via storm rebalance commande à l'avenir sans mettre la topologie hors ligne. Par exemple, imaginez que vous commencez avec un cluster Storm de 15 machines mais que vous savez déjà que la semaine prochaine, 10 autres boîtes seront ajoutées. Ici, vous pouvez opter pour l'exécution de la topologie au niveau de parallélisme prévu de 25 machines déjà sur les 15 boîtes initiales (ce qui est bien sûr plus lent que 25 boîtes). Une fois les 10 boîtes supplémentaires intégrées, vous pouvez alors storm rebalance la topologie pour utiliser pleinement les 25 boîtes sans aucun temps d'arrêt.
Une autre raison d'exécuter plus de 2 tâches par exécuteur est pour les tests (principalement fonctionnels). Par exemple, si votre machine de développement ou votre serveur CI est seulement assez puissant pour exécuter, disons, 2 exécuteurs à côté de tous les autres éléments exécutés sur la machine, vous pouvez toujours exécuter 30 tâches (ici: 15 par exécuteur) pour voir si du code tel que votre groupement Storm personnalisé fonctionne comme prévu.
En pratique, nous exécutons normalement 1 tâche par exécuteur.
PS: Notez que Storm va réellement apparaître quelques threads de plus dans les coulisses . Par exemple, chaque exécuteur a son propre "thread d'envoi" qui est responsable de la gestion des tuples sortants. Il existe également des threads d'arrière-plan "au niveau du système" pour, par exemple, acking tuples qui côtoient "vos" threads. L'IIRC Storm UI compte ces fils de discussion en plus de "vos" fils.