Kafka : API grand public et API de flux

Question

J'ai récemment commencé à apprendre Kafka et je me retrouve avec ces questions.

1. Quelle est la différence entre Consumer et Stream ? Pour moi, si un outil/application consomme des messages de Kafka, c'est un consommateur dans le monde Kafka.

2. En quoi Stream est-il différent puisqu'il consomme ou produit également des messages vers Kafka ? Et pourquoi est-il nécessaire puisque nous pouvons écrire notre propre consommateur ? application consommateur utilisant l'API consommateur et les traiter selon les besoins ou les envoyer à Spark depuis l'application consommateur ?

J'ai fait une recherche sur Google à ce sujet, mais je n'ai pas obtenu de bonnes réponses. Désolé si cette question est trop triviale.

Answer 1

Mise à jour : janvier 2021 : J'ai écrit un série de blogs en quatre parties sur les principes fondamentaux de Kafka que je recommande de lire pour des questions comme celles-ci. Pour cette question en particulier, jetez un coup d'œil à partie 3 sur les principes fondamentaux de la transformation .

Mise à jour avril 2018 : De nos jours, vous pouvez aussi utiliser ksqlDB ksqlDB, la base de données de streaming d'événements pour Kafka, pour traiter vos données dans Kafka. ksqlDB est construit au-dessus de l'API de flux de Kafka, et il est également livré avec un support de première classe pour les flux et les tableaux.

Quelle est la différence entre Consumer API et Streams API ?

La bibliothèque Streams de Kafka ( https://kafka.apache.org/documentation/streams/ ) est construit au-dessus des clients producteurs et consommateurs de Kafka. Kafka Streams est nettement plus puissant et aussi plus expressif que les clients ordinaires.

Il est beaucoup plus simple et rapide d'écrire une application du monde réel du début à la fin avec Kafka Streams qu'avec le simple consommateur.

Voici quelques-unes des fonctionnalités de l'API Kafka Streams, dont la plupart ne sont pas prises en charge par le client consommateur (il vous faudrait implémenter vous-même les fonctionnalités manquantes, c'est-à-dire réimplémenter Kafka Streams).

• Prise en charge de la sémantique du traitement "exactly-once" via les transactions Kafka ( ce que signifie EOS )
• Prise en charge de la tolérance aux pannes avec état (ainsi qu'apatrides, bien sûr), y compris le streaming. rejoint , agrégations et fenêtrage . En d'autres termes, il prend en charge la gestion de l'état de traitement de votre application dès sa sortie de l'emballage.
• Supports traitement des événements ainsi que le traitement basé sur délai de traitement y temps d'ingestion . Il traite également de manière transparente données non conformes .
• Un soutien de premier ordre pour les deux ruisseaux et tables En pratique, la plupart des applications de traitement de flux ont besoin à la fois de flux et de tables pour mettre en œuvre leurs cas d'utilisation respectifs. Si une technologie de traitement de flux ne dispose pas de l'une des deux abstractions (par exemple, pas de support pour les tables), vous êtes soit coincé, soit obligé d'implémenter manuellement cette fonctionnalité vous-même (bonne chance...).
• Supports les requêtes interactives (également appelé "état interrogeable") pour exposer les derniers résultats du traitement à d'autres applications et services via une API de type demande-réponse. C'est particulièrement utile pour les applications traditionnelles qui ne peuvent faire que de la demande-réponse, mais pas le côté streaming des choses.
• est plus expressif : il est livré avec (1) un style de programmation fonctionnel DSL avec des opérations telles que map , filter , reduce ainsi que (2) un style impératif API du processeur pour le traitement des événements complexes (CEP), par exemple, et (3) vous pouvez même combiner le DSL et l'API du processeur.
• A sa propre kit de test pour les tests unitaires et d'intégration.

Ver http://docs.confluent.io/current/streams/introduction.html pour une introduction plus détaillée mais toujours de haut niveau à l'API Kafka Streams, qui devrait également vous aider à comprendre les différences avec le client consommateur Kafka de niveau inférieur.

Au-delà de Kafka Streams, vous pouvez également utiliser la base de données de streaming ksqlDB pour traiter vos données dans Kafka. ksqlDB sépare sa couche de stockage (Kafka) de sa couche de calcul (ksqlDB lui-même ; il utilise ici Kafka Streams pour la plupart de ses fonctionnalités). Il prend en charge essentiellement les mêmes fonctionnalités que Kafka Streams, mais vous écrivez des instructions SQL en continu au lieu de code Java ou Scala. Vous pouvez interagir avec ksqlDB par le biais d'une interface utilisateur, d'une CLI et d'une API REST ; il dispose également d'un client Java natif si vous ne souhaitez pas utiliser REST. Enfin, si vous préférez ne pas avoir à gérer vous-même votre infrastructure, ksqlDB est disponible en tant que service entièrement géré. dans Confluent Cloud.

En quoi l'API Kafka Streams est-elle différente puisqu'elle consomme ou produit également des messages vers Kafka ?

Oui, l'API Kafka Streams peut à la fois lire des données et écrire des données dans Kafka. Elle prend en charge les transactions Kafka, de sorte que vous pouvez, par exemple, lire un ou plusieurs messages à partir d'un ou de plusieurs sujets, mettre à jour l'état du traitement si nécessaire, puis écrire un ou plusieurs messages de sortie vers un ou plusieurs sujets, le tout en une seule opération atomique.

et pourquoi est-ce nécessaire puisque nous pouvons écrire notre propre application consommateur en utilisant l'API consommateur et les traiter selon les besoins ou les envoyer à Spark depuis l'application consommateur ?

Oui, vous pourriez écrire votre propre application de consommation -- comme je l'ai mentionné, l'API Kafka Streams utilise le client de consommation Kafka (ainsi que le client de production) lui-même -- mais vous devriez implémenter manuellement toutes les fonctionnalités uniques que l'API Streams fournit. Voir la liste ci-dessus pour tout ce que vous obtenez "gratuitement". Il est donc rare qu'un utilisateur choisisse le simple client consommateur plutôt que la bibliothèque Kafka Streams, plus puissante.

Answer 2

Composant Kafka Stream construit pour supporter le type ETL de transformation des messages. Cela signifie que le flux d'entrée du sujet, la transformation et la sortie vers d'autres sujets. Il prend en charge le traitement en temps réel et, en même temps, les fonctions analytiques avancées telles que l'agrégation, le fenêtrage, la jointure, etc.

"Kafka Streams simplifie le développement d'applications en s'appuyant sur les bibliothèques de producteurs et de consommateurs Kafka et en tirant parti des capacités natives de Kafka pour offrir le parallélisme des données, la coordination distribuée, la tolérance aux pannes et la simplicité opérationnelle."

Voici les principales caractéristiques architecturales de Kafka Stream. Veuillez vous référer à aquí

1. Partitions et tâches de flux : Kafka Streams utilise les concepts de partitions et de tâches comme unités logiques de son modèle de parallélisme basé sur les partitions de sujets Kafka.
2. Modèle de filetage : Kafka Streams permet à l'utilisateur de configurer le nombre de threads que la bibliothèque peut utiliser pour paralléliser le traitement dans une instance d'application.
3. Magasins d'État locaux : Kafka Streams fournit ce que l'on appelle des magasins d'état, qui peuvent être utilisés par les applications de traitement de flux pour stocker et interroger les données, ce qui est une capacité importante lors de la mise en œuvre d'opérations avec état.
4. Tolérance aux pannes : Kafka Streams s'appuie sur les capacités de tolérance aux pannes intégrées nativement dans Kafka. Les partitions Kafka sont hautement disponibles et répliquées. Ainsi, lorsque les données de flux sont persistées dans Kafka, elles sont disponibles même si l'application échoue et doit les retraiter.

D'après ce que j'ai compris, voici les principales différences. Je suis prêt à mettre à jour les informations manquantes ou trompeuses.

Où utiliser Consommateur - Producteur :

1. S'il n'y a qu'un seul consommateur, il consomme le processus de message mais ne le transmet pas à d'autres sujets.
2. Comme le point 1, si nous avons juste un producteur qui produit un message, nous n'avons pas besoin de Kafka Stream.
3. Si le message du consommateur provient d'un seul cluster Kafka mais qu'il est publié sur différents sujets du cluster Kafka. Dans ce cas, même si vous pouvez utiliser Kafka Stream, vous devez utiliser un producteur distinct pour publier les messages vers différents clusters. Ou simplement utiliser le mécanisme Kafka Consumer - Producer.
4. Traitement par lots - s'il est nécessaire de collecter un message ou un type de traitement par lots, il est bon d'utiliser la méthode traditionnelle normale.

Où utiliser Kafka Stream :

1. Si vous consommez des messages d'un sujet, les transformez et les publiez vers d'autres sujets, Kafka Stream est le mieux adapté.
2. Traitement en temps réel, analyse en temps réel et apprentissage automatique.
3. Transformation statique telle que l'agrégation, la fenêtre de jonction, etc.
4. Vous envisagez d'utiliser les magasins publics locaux ou les magasins publics montés tels que Portworx, etc.
5. Obtenir une tolérance aux pannes sémantique et auto-définie pour un seul traitement.

Answer 3

Streams s'appuie sur les API Consommateur et Producteur et fonctionne donc à un niveau supérieur, ce qui signifie que

• Streams est plus facile à utiliser pour les tâches de type "lecture à partir d'un sujet/traitement/écriture vers un sujet".
• Producer/Consumer permet plus de contrôle et peut être utilisé dans certains cas que Streams ne gère pas.

Par exemple, Streams gère automatiquement les transactions, ce qui signifie que vous ne pouvez pas contrôler le moment exact où elles sont validées (que vous utilisiez le DSL Streams ou l'API de traitement). En revanche, l'API Consumer/Producer vous donne ce contrôle.