Présentation
J'ai décidé d'analyser un article décrivant certains détails intéressants du traitement en streaming une seule fois: une seule fois . Le fait est que certains auteurs comprennent très étrangement les termes. L'analyse de l'article nous permettra de clarifier plus en profondeur de nombreux détails, car l'identification des incohérences et des bizarreries vous permet de découvrir plus pleinement les concepts et la signification.
Commençons.
Analyse
Tout commence très bien:
Le traitement distribué des flux d'événements est devenu un sujet de plus en plus d'actualité dans le domaine du Big Data. Les moteurs de traitement de flux (SPE) notables incluent Apache Storm, Apache Flink, Heron, Apache Kafka (Kafka Streams) et Apache Spark (Spark Streaming). L'une des caractéristiques les plus notables et les plus discutées des SPE est leur sémantique de traitement, «exactement une fois» étant l'une des plus recherchées et de nombreuses SPE prétendant fournir une sémantique de traitement «exactement une fois».
Autrement dit, le traitement des données est extrêmement important, etc., et le sujet en discussion est une seule fois. Discutons-en.
Il existe cependant beaucoup de malentendus et d'ambiguïtés entourant ce qu'est exactement «exactement une fois», ce que cela implique et ce que cela signifie vraiment lorsque des SPE individuelles prétendent le fournir.
En effet, il est très important de comprendre ce que c'est. Pour ce faire, il serait bon de donner la bonne définition avant un long raisonnement. Et qui suis-je pour donner de si bons conseils?
Je vais discuter de la façon dont la sémantique de traitement «une seule fois» diffère entre de nombreuses SPE populaires et pourquoi «une seule fois» peut être mieux décrit comme efficace une fois
Inventer de nouveaux termes est, bien sûr, une tâche importante. J'adore cette chose moi-même. Juste pour cela, une justification est nécessaire. Essayons de le trouver.
Je ne décrirai pas les choses évidentes comme des graphiques de traitement dirigé et ainsi de suite. Les lecteurs peuvent lire eux-mêmes l'article original. De plus, l'analyse de ces détails n'est pas pertinente. Je ne donnerai qu'une photo:
Ensuite, il y a une description de la sémantique:
- Au plus une fois, c'est-à-dire pas plus d'une fois. Avec une évidence apparente, un tel comportement est extrêmement difficile à garantir dans des scénarios au niveau des limites tels que des plantages, des perturbations de la connectivité réseau, etc. Mais pour l'auteur, tout est simple:
- Au moins une fois, c'est-à-dire au moins une fois. Le schéma est plus complexe. Et le râteau peut être collecté plus:
- Exactement une fois. Qu'est-ce qu'une seule fois?
Les événements sont garantis pour être traités «une seule fois» par tous les opérateurs dans l'application de flux, même en cas de diverses pannes.
C'est-à-dire la garantie d'un traitement en une seule fois est lorsque le traitement "une seule fois" a eu lieu.
Ressentez-vous le pouvoir de la détermination? Pour reformuler: le traitement une fois, c'est quand le traitement a lieu «une fois». Eh bien, oui, il dit également que cette garantie doit être préservée en cas de défaillance. Mais pour les systèmes distribués, c'est une chose évidente. Et les guillemets suggèrent que quelque chose ne va pas ici. Définir avec des guillemets sans expliquer ce que cela signifie est le signe d'une approche profonde et réfléchie.
Ce qui suit est une description de la façon d'implémenter une telle sémantique. Et ici, je voudrais m'attarder plus en détail.
Deux mécanismes populaires sont généralement utilisés pour réaliser une sémantique de traitement «en une seule fois».
- Instantané distribué / point de contrôle d'état
- Livraison d'événements au moins une fois plus déduplication des messages
Si le premier mécanisme concernant les instantanés et les points de contrôle ne soulève pas de questions, à l'exception de certains détails tels que l'efficacité, il y a alors de petits problèmes avec le second que l'auteur a ignorés.
Pour une raison quelconque, il est entendu qu'un gestionnaire ne peut être que déterministe. Dans le cas d'un gestionnaire non déterministe, chaque redémarrage ultérieur donnera, de manière générale, d'autres valeurs et états de sortie, ce qui signifie que la déduplication ne fonctionnera pas, car les valeurs de sortie seront différentes. Ainsi, le mécanisme général sera beaucoup plus compliqué que celui décrit dans l'article. Ou, franchement, un tel mécanisme est incorrect.
Cependant, nous nous tournons vers les plus délicieux:
Exactement une fois est-il vraiment exactement une fois?
Maintenant, réexaminons ce que la sémantique de traitement «en une seule fois» garantit réellement à l'utilisateur final. L'étiquette «exactement une fois» est trompeuse en décrivant ce qui est fait exactement une fois.
On dit qu'il est temps de reconsidérer ce concept, car il y a quelques incohérences.
Certains pourraient penser que «exactement une fois» décrit la garantie du traitement des événements dans lequel chaque événement du flux n'est traité qu'une seule fois. En réalité, aucune SPE ne peut garantir un traitement unique. Il est impossible de garantir que la logique définie par l'utilisateur dans chaque opérateur ne s'exécute qu'une fois par événement face à des échecs arbitraires, car l'exécution partielle du code utilisateur est une possibilité omniprésente.
Cher auteur, il convient de rappeler le fonctionnement des processeurs modernes. Chaque processeur en cours de traitement effectue un grand nombre d'étages parallèles. De plus, il existe des branches dans lesquelles le processeur commence à effectuer les mauvaises actions si le prédicteur de branche est incorrect. Dans ce cas, les actions sont annulées. Ainsi, le processeur peut exécuter deux fois le même morceau de code, même si aucun échec n'est survenu!
Le lecteur attentif s'exclamera immédiatement: car l'échappement est important, et non la manière dont il est effectué. Exactement! Ce qui compte, c'est ce qui s'est passé et non comment cela s'est réellement passé. Si le résultat est comme s'il s'est produit exactement une fois, cela signifie qu'il s'est produit exactement une fois. Vous ne trouvez pas? Et tout le reste est décortiqué, sans importance. Les systèmes sont complexes et les abstractions qui en résultent ne créent que l'illusion de l'exécution d'une certaine manière. Il nous semble que le code est exécuté séquentiellement, instruction par instruction, qui lit d'abord, puis écrit, puis une nouvelle instruction. Mais ce n'est pas le cas, tout est beaucoup plus compliqué. Et l'essence des abstractions correctes est de maintenir l'illusion de garanties simples et compréhensibles, sans approfondir à chaque fois, lorsque vous devez attribuer des valeurs à une variable.
Et tout le problème de cet article réside dans le fait qu'exactement une fois est une abstraction qui vous permet de créer des applications sans penser aux doublons et aux valeurs perdues. Que tout ira bien, même en cas de chute. Et il n'est pas nécessaire d'inventer de nouveaux termes pour cela.
L'exemple de code de l'article montre clairement un manque de compréhension de la façon d'écrire des gestionnaires:
Map (Event event) { Print "Event ID: " + event.getId() Return event }
Le lecteur est invité à réécrire indépendamment le code afin de ne pas répéter les erreurs de l'auteur de l'article.
Alors, qu'est-ce que les SPE garantissent lorsqu'ils revendiquent une sémantique de traitement «une seule fois»? S'il n'est pas garanti que la logique utilisateur soit exécutée une seule fois, qu'est-ce qui est exécuté une seule fois? Lorsque les SPE revendiquent une sémantique de traitement «une seule fois», ce qu'ils disent en réalité, c'est qu'ils peuvent garantir que les mises à jour de l'état géré par la SPE ne sont validées qu'une seule fois dans un magasin d'arrière-plan durable.
L'utilisateur n'a pas besoin d'une garantie de l'exécution physique du code. En sachant comment fonctionne le processeur, il est facile de conclure que ce n'est pas possible. L'essentiel est l'exécution logique une seule fois, comme s'il n'y avait aucun échec. Attirer les concepts de «s’engager dans l’entrepôt de données» ne fait qu’aggraver le manque de compréhension de l’auteur des choses de base, car il existe des implémentations de telles sémantiques sans avoir besoin d'un commit.
Pour plus d'informations, vous pouvez lire brièvement mon article: Traitement concurrentiel hétérogène des données en temps réel strictement une fois .
En d'autres termes, le traitement d'un événement peut se produire plusieurs fois, mais l'effet de ce traitement n'est reflété qu'une seule fois dans la mémoire d'état du backend durable.
Qu'il existe un "magasin d'état backend durable" pour l'utilisateur est absolument violet. Seul l'effet du traitement est important, c'est-à-dire cohérence et valeurs de sortie sur toute la durée du traitement des données en streaming. Il convient de noter que pour certaines tâches, il n'est pas nécessaire d'avoir un magasin d'état backend durable, et il serait bon de garantir exactement une fois.
Chez Streamlio, nous avons décidé qu'effectivement une fois est le meilleur terme pour décrire ces sémantiques de traitement.
Un exemple typique de saisie stupide de concepts: nous écrirons quelques exemples et de longs arguments pour un paragraphe entier, et à la fin nous ajouterons que «nous définissons ce concept de cette manière». La précision et la clarté des définitions provoquent une réponse émotionnelle vraiment vive.
Conclusions
La méconnaissance de l'essence des abstractions conduit à une distorsion de la signification originale des concepts existants et à la création ultérieure de nouveaux termes à partir de zéro.
[1] Exactement une fois n'est PAS exactement la même chose .
[2] Traitement hétérogène des données concurrentielles en temps réel strictement une fois .