Flink a été comparé à Spark , qui, comme je le vois, est la mauvaise comparaison car il compare un système de traitement d'événements fenêtré à un micro-batching; De même, cela n'a pas beaucoup de sens pour moi de comparer Flink à Samza. Dans les deux cas, il compare une stratégie de traitement d'événements en temps réel par rapport à une stratégie de traitement par lots, même à une plus petite «échelle» dans le cas de Samza. Mais j'aimerais savoir comment Flink se compare à Storm, qui lui semble conceptuellement beaucoup plus similaire.

J'ai trouvé cela (diapositive n ° 4) documentant la principale différence en tant que «latence réglable» 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 lui-même note dans une interview que "Par rapport à 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 fournir des garanties de traitement une seule fois".

Tout cela est un peu rare pour moi et je ne comprends pas tout à fait le point. Quelqu'un peut-il expliquer quel (s?) Problème (s?) De traitement de flux dans Storm est (sont?) Exactement résolu par Flink? À quoi Hueske fait-il référence par les problèmes d'API et leur «stratégie de tolérance aux pannes plus légère»?

Clause de non - responsabilité : Je suis un committer Apache Flink et un membre 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 unifié des flux et des lots. Le runtime de Flink prend en charge nativement les deux domaines en raison des transferts de données en pipeline entre des tâches parallèles qui incluent des brassages en pipeline. Les enregistrements sont immédiatement expédiés de la production des tâches à la réception des tâches (après avoir été collectés dans une mémoire tampon pour le transfert réseau). Les travaux par lots peuvent être exécutés en option en bloquant les transferts de données.

Apache Spark est un framework qui prend également en charge le traitement par lots et par flux. L'API par lots de Flink est assez similaire et répond à des cas d'utilisation similaires à Spark, mais diffère dans les composants internes. Pour le streaming, les deux systèmes suivent des approches très différentes (mini-lots vs 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 en interne un peu à Storm, c'est-à-dire que les interfaces des tâches parallèles de Flink sont similaires aux boulons de Storm. Storm et Flink ont ​​en commun de viser un traitement de flux à faible latence par des transferts de données en pipeline. Cependant, Flink propose une API de plus haut niveau par rapport à Storm. Au lieu d'implémenter la fonctionnalité d'un boulon 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 concerne le traitement de la sémantique. Storm garantit un traitement au moins une fois 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 qui ont été traités auparavant) sont validés. En cas d'échec, tous les opérateurs sources sont remis à leur état lorsqu'ils ont vu le dernier marqueur validé et le traitement se poursuit. 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 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 qui ont été traités auparavant) sont validés. En cas d'échec, tous les opérateurs sources sont remis à leur état lorsqu'ils ont vu le dernier marqueur validé et le traitement se poursuit. 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 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 qui ont été traités auparavant) sont validés. En cas d'échec, tous les opérateurs sources sont remis à leur état lorsqu'ils ont vu le dernier marqueur validé et le traitement se poursuit. 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 tous les opérateurs de sources sont réinitialisés à leur état lorsqu'ils ont vu le dernier marqueur validé et le traitement se poursuit. 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 tous les opérateurs de sources sont réinitialisés à leur état lorsqu'ils ont vu le dernier marqueur validé et le traitement se poursuit. 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. Cejeu de diapositives et correspondant talk discuter de l' approche de traitement en continu de Flink , y compris la tolérance aux pannes, checkpointing et la manipulation de l' État.

Storm propose également une API de haut niveau exactement unique appelée Trident. Cependant, Trident est basé sur des mini-lots et donc plus similaire à Spark qu'à Flink.

La latence réglable 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 les enregistrements dès qu'ils sont produits. Par souci d'efficacité, ces enregistrements sont collectés dans un tampon qui est envoyé sur le réseau une fois qu'il est plein ou qu'un certain seuil de temps est atteint. Ce seuil contrôle la latence des enregistrements car il spécifie la durée maximale pendant laquelle un enregistrement restera dans une mémoire tampon sans être envoyé à la tâche suivante. Cependant, il ne peut pas être utilisé pour donner des garanties concrètes sur le temps qu'il faut à un enregistrement entre l'entrée et la sortie d'un programme, car cela dépend également du temps de traitement au sein des tâches et du nombre de transferts réseau, entre autres.

Ajoutant à la réponse de Fabian Hueske:

Flink améliore également Storm des manières suivantes:

• Contre-pression: le runtime de streaming de Flink se comporte bien lorsque différents opérateurs fonctionnent à des vitesses différentes, car les opérateurs en aval font très bien la contre-pression des opérateurs en amont alors que la couche réseau gère les pools de tampons.

• État défini par l'utilisateur: Flink permet aux programmes de maintenir un état personnalisé dans vos opérateurs. Cet état peut en fait participer au point de contrôle de la tolérance aux pannes, fournissant des garanties une seule fois pour l'état personnalisé défini par l'utilisateur. Voir cet exemple de machine à états définie par l'utilisateur à l'intérieur d'un opérateur, qui est systématiquement pointée avec le flux de données.

• Streaming Windows: le fenêtrage 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 des approches différentes. Chaque fonctionnalité de Flink mentionnée par @Stephan Ewen peut être assortie par Storm avec l'API interne (c'est-à-dire, les spolts et les boulons ) et l' API Trident maintenant. Quelqu'un prétend que Trident est de style mini-batch alors que je pense que la plupart des applications complexes avec état ou agrégation ne pourraient dépendre que du traitement par lots avec style de fenêtre. Je viens donc d'énumérer ici quelques différences principales sans dire laquelle est la meilleure.

• Style de développement . orienté informatique (par exemple, opérateur chaînable) dans Flink vs orienté flux de données (par exemple addSpolt()/addBolt()) dans Storm.
• API de haut niveau . Fonctions (par exemple, Map, Window, Join in Streaming level) dans Flink vs. Native Window et Trident dans Storm.
• Traitement des messages garanti (GMP. C.- à-d. Exactement une fois ) . Point de contrôle avec connecteur de validation en deux phases (par exemple, KafkaConsumer) dans Flink vs Tuple-tree avec la machine à états externe ou Trident dans Storm.
• Tolérance aux pannes . Marker-checkpoint dans Flink vs record-level-ACK dans Storm.
• Architecture interne . Abstraction simple et parallélisme relatif (par exemple, emplacement pour chaque thread considéré avec les cœurs de processeur) dans Flink vs abstractions multicouches (par exemple, emplacement pour chaque JVM en tant que travailleur dans superviseur et chaque superviseur peut avoir de nombreux travailleurs) dans Storm.

Disclaimer: Je suis un employé de Cloudera, un grand supporter de Storm et (bientôt) de Flink.

Fonctionnel

De nombreux bons points techniques ont déjà été présentés. Un très bref résumé des faits saillants:

• Flink et Storm peuvent tous deux effectuer un traitement par événement
• Storm ne semble pas prendre en charge le temps de l'événement hors de la boîte
• Storm n'a pas sorti le support SQL de la phase expérimentale

Non fonctionnel

• De nombreux clients ont trouvé Storm (trop) difficile à utiliser
• L'adoption de Storm a ralenti et la communauté de Flink semble désormais plus active que Storm
• Flink a encore du rattrapage à faire (par exemple, des exemples documentés), mais dans l'ensemble, il a rattrapé presque tous les domaines auxquels vous pourriez penser

Conclusion

Cloudera a récemment annoncé la dépréciation de Storm (en HDP). Et simultanément Flink a été annoncé comme son successeur.

Donc, si vous avez des cas d'utilisation sur la tempête, ils continueront bien sûr à fonctionner. Mais pour de nouveaux cas d'utilisation, je me pencherais sur Flink ou d'autres moteurs de streaming.