Quelle est/sont la principale différence(s) entre Flink et de la Tempête?

avertissement: je suis un membre D'Apache Flink committer et PMC et je ne suis familier qu'avec le design de Storm, pas avec ses intérieurs.

Apache Flink est un framework pour le traitement de flux et de lots unifiés. Flink's runtime supporte nativement les deux domaines en raison de transferts de données pipelined entre des tâches parallèles qui comprend des boutons de manchette pipelined. 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 un tampon pour le réseau transfert.) 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 en flux. L'API batch de Flink semble assez similaire et traite des cas d'utilisation similaires comme Spark mais diffère dans les internes. Pour la diffusion en continu, les deux systèmes suivent des approches très différentes (mini-lots par rapport à la diffusion en continu), ce qui les rend adaptés à différents types d'applications. Je dirais que comparer Spark et Flink est valable 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é de traitement par lots. En fait, le moteur pipelé interne de Flink ressemble 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 transfert de données par pipelinette. Cependant, Flink offre une API de haut niveau comparé à la tempête. 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 de traitement sémantique. Storm garantit un traitement au moins une fois alors que Flink fournit exactement-une fois. Les implémentations qui donnent ces garanties de traitement sont assez différentes. Alors Que La Tempête Flink utilise une variante de L'algorithme de 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 contrôle 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 engagés. En cas de panne, tous les opérateurs sources sont réinitialisés à leur état lorsqu'ils ont vu le dernier marqueur engagé et le traitement est continuer. Cette approche marqueur-point de contrôle est plus légère que les accusés de réception record de Storm. Ce diaporama et le diaporama " talk traitent de L'approche de traitement en continu de Flink, y compris la tolérance à la défaillance, le pointage et la manipulation de l'état.

Storm offre également une API de haut niveau appelée Trident. Cependant, Trident est basé sur des mini-lots et donc plus proche de Spark que Flink.

Flink est réglable de latence se réfère à la façon dont Flink envoie des enregistrements à partir d'une tâche à l'autre. J'ai dit avant, que Flink utilise des transferts de données pipelined et transmet des enregistrements dès qu'ils sont produits. Pour des raisons d'efficacité, ces enregistrements sont collectés dans un tampon qui est envoyé sur le réseau une fois qu'il est plein ou un certain seuil de temps est atteint. Ce seuil contrôle la latence des enregistrements car il spécifie la durée maximale de séjour d'un enregistrement dans un tampon sans d'être envoyé à la tâche suivante. Cependant, il ne peut pas être utilisé pour donner des garanties tangibles sur le temps qu'il faut pour un enregistrement de l'entrée à la sortie d'un programme parce que cela dépend également du temps de traitement dans les tâches et le nombre de transferts de réseau entre autres choses.