Quels sont les avantages d'Apache Beam par rapport à Spark / Flink pour le traitement par lots?
Apache Beam supporte plusieurs moteurs, y compris Apache Spark et Flink. Je connais Spark/Flink et j'essaie de voir les avantages/inconvénients de Beam pour le traitement par lots.
En regardant exemple de comptage de mots dans un rayon , on constate qu'il est très similaire aux équivalents Spark/Flink natifs, peut-être avec une syntaxe légèrement plus détaillée.
Je ne vois pas actuellement de gros avantage à choisir Beam plutôt que Spark/Flink pour une telle tâche. Les seules observations que je puisse faire jusqu'à présent:
- Pro: Abstraction sur différents backends d'exécution.
- Inconvénient: cette abstraction a le prix d’avoir moins de contrôle sur ce qui est exactement exécuté dans Spark/Flink.
Existe-t-il de meilleurs exemples mettant en évidence d'autres avantages/inconvénients du modèle Beam? Existe-t-il des informations sur l'impact de la perte de contrôle sur les performances?
Notez que je ne demande pas de différences dans les aspects de streaming, qui sont en partie couverts dans cette question et résumés dans cet article (obsolète en raison de Spark 1.X).
Beam ajoute quelques éléments à de nombreux moteurs existants.
Unification du traitement par lots et de la diffusion en continu. De nombreux systèmes peuvent gérer à la fois le traitement par lots et la diffusion en continu, mais ils le font souvent via des API distinctes. Mais dans Beam, batch et streaming ne sont que deux points sur un spectre de latence, de complétude et de coût. Il n'y a pas d'apprentissage/réécriture falaise du lot au streaming. Ainsi, si vous écrivez un pipeline par lots aujourd'hui mais que, demain, vos besoins en temps de latence changent, il est extrêmement facile à ajuster. Vous pouvez voir ce genre de voyage dans les exemples de jeux mobiles .
API augmentant le niveau d'abstraction : les API de Beam se concentrent sur la capture des propriétés de vos données et de votre logique, au lieu de laisser passer les détails de l'exécution sous-jacente. C'est à la fois une clé pour la portabilité (voir paragraphe suivant) et peut également donner aux runtimes beaucoup de flexibilité dans la manière dont ils s'exécutent. Quelque chose comme la fusion ParDo (alias composition de fonction) est une optimisation assez basique que la grande majorité des coureurs font déjà. D'autres optimisations sont encore en cours d'implémentation pour certains coureurs. Par exemple, les API source de Beam sont spécifiquement conçus pour éviter la spécification excessive du partage dans un pipeline. Au lieu de cela, ils offrent aux coureurs le bon moyen de rééquilibrer de manière dynamique le travail sur les machines disponibles. Cela peut faire une énorme différence de performance en éliminant essentiellement les fragments de retardataires. En général, plus nous sommes intelligents pour les coureurs, mieux nous serons. Même le réglage manuel le plus prudent échouera à mesure que les données, le code et les environnements changent.
Portabilité entre les exécutions. : Les formes de données et les exigences d’exécution étant parfaitement séparées, le même pipeline peut être exécuté de différentes manières. Et cela signifie que vous ne finissez pas par réécrire du code lorsque vous devez passer d'un système sur site au cloud ou d'un système éprouvé à un système performant. Vous pouvez très facilement comparer les options pour trouver la combinaison d'environnement et de performance qui convient le mieux à vos besoins actuels. Et cela pourrait être un mélange de choses - traiter des données sensibles sur site avec un programme d'exécution open source et traiter d'autres données sur un service géré dans le cloud.
Concevoir le modèle Beam de manière à constituer une abstraction utile sur de nombreux moteurs différents est délicat. Le faisceau n'est ni l'intersection de la fonctionnalité de tous les moteurs (trop limitée!) Ni l'union (trop d'un évier de cuisine!). Au lieu de cela, Beam tente d’être à l’avant-garde du traitement des données, en insérant des fonctionnalités dans les moteurs d’exécution et en les extrayant.
- Keyed State est un excellent exemple de fonctionnalité qui existait dans différents moteurs et permettait des cas d'utilisation intéressants et communs, mais qui à l'origine n'était pas exprimable dans Beam. Nous avons récemment étendu le modèle Beam afin d'inclure une version de cette fonctionnalité selon les principes de Beam principes de conception .
- Et inversement, nous espérons que Beam influencera également les feuilles de route de divers moteurs. Par exemple, la sémantique des flux de données de Flink était influencée par le modèle Beam (née Dataflow).
- Cela signifie également que les capacités ne seront pas toujours identiques entre les différents coureurs de Beam à un moment donné. C'est pourquoi nous utilisons matrice de capacités pour essayer de communiquer clairement l'état des choses.