Quelle est/quelles sont les principales différences entre Flink et Storm?
Flink a été comparé à Spark , qui, selon moi, est une comparaison erronée car il compare un système de traitement d’événements fenêtré à un traitement par micro-traitement en lots; De même, comparer Flink à Samza n’a pas beaucoup de sens. Dans les deux cas, il compare une stratégie de traitement des événements en temps réel et par lots, même à une "échelle" plus petite dans le cas de Samza. Mais j'aimerais savoir comment Flink se compare à Storm, qui semble beaucoup plus similaire sur le plan conceptuel.
J'ai trouvé this (diapositive n ° 4) documentant la différence principale en tant que "temps de latence ajustable" pour Flink. Un autre indice semble être un article de Slicon Angle qui suggère que Flink s’intègre mieux dans un monde Spark ou HadoopMR, mais aucun détail réel n’est mentionné ou référencé. Enfin, Fabian Hueske note lui-même dans une interview que "Comparée à Apache Storm, la fonctionnalité d’analyse de flux de Flink offre une API de haut niveau et utilise une stratégie de tolérance aux pannes plus légère pour garantir des traitements uniques. "
Tout cela est un peu maigre et je ne comprends pas tout à fait. Quelqu'un peut-il expliquer quel (s) problème (s) de traitement du flux dans Storm est (sont?) Exactement résolu (s) par Flink? À quoi Hueske fait-il référence par les problèmes liés à l'API et à leur "stratégie de tolérance de panne plus légère"?
Clause de non-responsabilité: Je suis un partisan de Apache Flink et un membre du PMC et je ne connais que la conception de haut niveau de Storm, pas ses composants internes.
Apache Flink est un framework pour le traitement par lots et flux unifiés. Le moteur d'exécution de Flink prend en charge de manière native les deux domaines en raison des transferts de données en pipeline entre tâches parallèles, ce qui inclut les shuffles en pipeline. Les enregistrements sont immédiatement envoyés des tâches de production aux tâches de réception (après avoir été rassemblés dans une mémoire tampon pour le transfert réseau). Les travaux par lots peuvent éventuellement être exécutés à l'aide de transferts de données bloquants.
Apache Spark est un framework qui prend également en charge le traitement par lots et par flux. L'API de traitement par lots de Flink est assez similaire et traite des cas d'utilisation similaires à ceux de Spark, mais diffère au niveau interne. Pour le streaming, les deux systèmes suivent des approches très différentes (mini-lots par rapport au streaming), ce qui les rend adaptés à différents types d'applications. Je dirais que comparer Spark et Flink est valide et utile, cependant, Spark n’est pas le moteur de traitement de flux le plus similaire à Flink.
Pour en venir à la question initiale, Apache Storm est un processeur de flux de données sans capacités de traitement par lots. En fait, le moteur en pipeline de Flink ressemble un peu en interne à Storm, c’est-à-dire que les interfaces des tâches parallèles de Flink sont similaires à celles de Storm. Storm et Flink ont en commun d’obtenir un traitement de flux à faible temps de latence par transfert de données en pipeline. Cependant, Flink offre une API de plus haut niveau par rapport à Storm. Au lieu d'implémenter la fonctionnalité d'un verrou avec un ou plusieurs lecteurs et collecteurs, l'API DataStream de Flink fournit des fonctions telles que Map, GroupBy, Window et Join. Une grande partie de cette fonctionnalité doit être implémentée manuellement lors de l'utilisation de Storm. Une autre différence est la sémantique de traitement. Storm garantit au moins une fois le traitement, tandis que Flink fournit exactement une fois. Les implémentations qui donnent ces garanties de traitement diffèrent un peu. Alors que Storm utilise des accusés de réception au niveau de l'enregistrement, Flink utilise une variante de l'algorithme Chandy-Lamport. En un mot, les sources de données injectent périodiquement des marqueurs dans le flux de données. Chaque fois qu'un opérateur reçoit un tel marqueur, il vérifie son état interne. Lorsqu'un marqueur a été reçu par tous les puits de données, le marqueur (et tous les enregistrements traités auparavant) sont validés. En cas de défaillance, tous les opérateurs de sources sont réinitialisés à leur état lorsqu'ils ont vu le dernier marqueur validé et que le traitement est poursuivi. Cette approche marqueur-point de contrôle est plus légère que les accusés de réception au niveau de l'enregistrement de Storm. Ce ensemble de diapositives et les discussions décrivent l'approche de traitement en continu de Flink, y compris la tolérance aux pannes, les points de contrôle et la gestion des états.
Storm propose également une API unique, de haut niveau, appelée Trident. Cependant, Trident est basé sur des mini-lots et est donc plus similaire à Spark qu'à Flink.
La latence ajustable de Flink fait référence à la façon dont Flink envoie les enregistrements d'une tâche à l'autre. J'ai déjà dit que Flink utilise des transferts de données en pipeline et transmet des enregistrements dès leur production. Pour plus d'efficacité, ces enregistrements sont collectés dans une mémoire tampon qui est envoyée sur le réseau une fois que celui-ci est plein ou qu'un certain délai est atteint. Ce seuil contrôle la latence des enregistrements car il spécifie la durée maximale pendant laquelle un enregistrement reste dans une mémoire tampon sans être envoyé à la tâche suivante. Cependant, il ne peut pas être utilisé pour donner de sérieuses garanties quant au temps nécessaire pour qu'un enregistrement passe d'un programme à un autre, car cela dépend également du temps de traitement au sein des tâches et du nombre de transferts réseau, entre autres.
Ajout à la réponse de Fabian Hueske:
Flink améliore aussi Storm de plusieurs manières:
Contre-pression: l'exécution en continu de Flink se comporte bien lorsque différents opérateurs s'exécutent à des vitesses différentes, car les opérateurs en aval contre-exploitent très bien les opérateurs en amont bien que la couche réseau gère les pools de mémoire tampon.
État défini par l'utilisateur: Flink permet aux programmes de conserver un état personnalisé dans vos opérateurs. Cet état peut réellement participer au point de contrôle pour la tolérance aux pannes, fournissant des garanties uniques pour un état personnalisé défini par l'utilisateur. Voir cet exemple d'une machine à états définie par l'utilisateur dans un opérateur, qui est systématiquement contrôlée avec le flux de données.
Windows en streaming: les fenêtres de flux et les agrégations de fenêtres sont un élément essentiel pour l'analyse des flux de données. Flink est livré avec un système de fenêtrage assez puissant qui prend en charge de nombreux types de fenêtres.
Basé sur mon expérience de Storm et Flink. Je pense que ces outils peuvent résoudre le même problème avec différentes approches. Storm peut associer chaque fonctionnalité de Flink mentionnée par @Stephan Ewen avec une API interne (c'est-à-dire, spolts et bolts) et une API Trident maintenant. Quelqu'un affirme que Trident est un style mini-batch alors que je pense que la plupart des applications complexes avec agrégation ou liées à un état ne pourraient dépendre que du traitement par lots avec un style de fenêtre. Donc, je viens d’énumérer ici quelques différences principales sans dire lequel est meilleur.
- Style de développement . orienté informatique (par exemple, opérateur chaînable) dans Flink par rapport à orienté flux de données (par exemple,
addSpolt()/addBolt()) dans Storm. - API de haut niveau . Fonctions (par exemple, Carte, Fenêtre, Joindre au niveau de diffusion) dans Flink vs. Fenêtre native et Trident dans Storm.
- Traitement des messages garanti (GMP. C’est-à-dire à la date exacte) . Point de contrôle avec connecteur de validation à deux phases (par exemple, KafkaConsumer) dans Flink vs. Tuple-tree avec la machine à états externe ou Trident dans Storm.
- Tolérance aux pannes . Marqueur-point de contrôle dans Flink vs record-ACK-dans Storm.
- Architecture interne . Abstraction simple et parallélisme relatif (par exemple, emplacement pour chaque thread considéré avec des cœurs de processeur) dans Flink vs. Abstractions multicouches (par exemple, un emplacement pour chaque JVM en tant que travailleur dans superviseur et chaque superviseur peut avoir de nombreux travailleurs) dans Storm.