Akka Stream Kafka vs Kafka Streams
je suis actuellement en train de travailler avec Akka Flux De Kafka pour interagir avec kafka et je me demandais quelles étaient les différences avec Kafka Streams.
je sais que L'approche basée sur Akka met en œuvre les spécifications réactives et gère les contre-pressions, fonctionnalités que Kafka streams semble manquer.
quel serait l'avantage d'utiliser Kafka streams par rapport à akka streams kafka?
3 réponses
Votre question est très générale, donc je vais donner une réponse générale, de mon point de vue.
tout d'Abord, j'ai deux scénario d'utilisation:
- cas où je suis en train de lire des données de kafka, de les traiter et d'écrire une sortie à kafka, pour ceux-ci, j'utilise exclusivement des flux de kafka.
- cas où la source de données ou le puits n'est pas kafka, pour ceux que j'utilise akka streams.
cela me permet déjà de répondre à la partie sur contre-pression: pour le 1er scénario ci-dessus, il existe un mécanisme de contre-pression dans les cours d'eau de kafka.
maintenant, concentrons-nous uniquement sur le premier scénario décrit ci-dessus. Voyons ce que je perdrais si je décidais d'arrêter D'utiliser Kafka streams:
- certaines de mes étapes de processeurs de flux ont besoin d'un stock d'état persistant (distribué), Kafka streams le fournit pour moi. C'est quelque chose qu'akka streams ne fournit pas.
- mise à l'échelle, les flux de kafka s'équilibrent automatiquement la charge dès qu'une nouvelle instance d'un flux processeur est commencé, ou dès que l'on se fait tuer. Cela fonctionne à l'intérieur de la même JVM, ainsi que sur d'autres nœuds: mise à l'échelle et sortie. Cela n'est pas fourni par akka streams.
ce sont les plus grandes différences qui comptent pour moi, j'espère que cela a du sens pour vous!
le grand avantage de Akka Stream sur Kafka Streams serait la possibilité d'implémenter des graphes de traitement très complexes qui peuvent être cycliques avec ventilateur in/out et boucle de rétroaction. Kafka streams n'autorise le graphe acyclique que si Je ne me trompe pas. Il serait très compliqué d'implémenter un graphique de traitement cyclique au-dessus des flux de Kafka
trouvé cet article pour donner un bon résumé des préoccupations de conception distribué que Kafka Streams offre (complète Akka Streams).
https://www.beyondthelines.net/computing/kafka-streams/
commande des messages: Kafka maintient une sorte d'annexe seulement log où il stocke tous les messages, chaque message a un id de séquence également connu sous le nom de son offset. Le décalage est utilisé pour indiquer la position d'un message dans le journal. Kafka streams utilise ces offsets de message pour maintenir l'ordre.
partitionnement: Kafka divise un sujet en partitions et chaque partition est répliquée entre différents courtiers. Le partitionnement permet d'étaler la charge et la réplication rend l'application tolérante aux défauts (si un courtier est en bas, les données sont encore disponibles). C'est bon pour le partitionnement des données, mais nous devons également distribuer les processus d'une manière similaire. Kafka Streams utilise la topologie du processeur qui s'appuie sur la direction du groupe Kafka. Il s'agit de la même gestion de groupe que celle utilisée par le consommateur Kafka pour répartir la charge également entre les courtiers (ce travail est principalement géré par les courtiers).
tolérance de défaut: la réplication des données assure la tolérance des défauts de données. La gestion de groupe a une tolérance de défaut intégrée puisqu'elle répartit la charge de travail entre les instances restantes de courtier en direct.
gestion de l'État: Kafka streams fournit un le stockage est sauvegardé par un sujet Kafka change-log qui utilise le compactage log (ne conserve que la valeur la plus récente pour une clé donnée).Kafka, journal de compactage
Retraitement: lors du démarrage d'une nouvelle version de l'application, nous pouvons retraiter les logs depuis le début pour calculer le nouvel état, puis rediriger le trafic de la nouvelle instance et arrêter l'ancienne application.
gestion du Temps: "Flux de données n'est jamais complète, et il peut toujours arriver en dehors-de-commande" donc il faut distinguer le temps de l'événement par rapport au temps traité et le gérer correctement.
L'auteur dit aussi "en utilisant ce journal de modification, Kafka Stream est capable de maintenir une "vue de table" de l'état de l'application."
mon avis est que cela s'applique principalement à une application d'entreprise où l ' "état d'application" est ... petit.
pour une application de science de données travaillant avec "big data", l '"état d'application" produit par une combinaison de la suppression des données, les modèles d'apprentissage automatique et la logique opérationnelle pour orchestrer tout cela ne seront probablement pas bien gérés avec Kafka Streams.
Aussi, pense que l'utilisation d'un "fonctionnels purs event sourcing runtime" comme https://github.com/notxcain/aecor aidera à rendre les mutations explicites et à séparer la logique d'application de la technologie utilisée pour gérer la forme persistante de l'état par la gestion fondée sur des principes de la mutation de l'état et IO les "effets" (programmation fonctionnelle).
en d'autres termes, la logique commerciale ne s'emmêle pas avec le Kafka api.