Kafka: Consumer API vs flux API
J'ai récemment commencé à apprendre Kafka et à me retrouver avec cette question.
Quelle est la différence entre Consumer et Stream? Pour moi, si un outil / application consomme des messages de Kafka est un consommateur dans le monde de Kafka. Alors, comment Stream est différent car cela consomme aussi de ou produire des messages à Kafka? et pourquoi est-il nécessaire que nous pouvons écrire notre propre consommation application utilisant L'API Consumer et les traiter au besoin ou les envoyer à Spark à partir de l'application consumer?
Je l'ai fait Google à ce sujet, mais n'a pas obtenu de bonnes réponses pour cela. Désolé si cette question est trop triviale.
1 réponses
Mise à jour avril 09, 2018: de nos jours, vous pouvez également utiliser KSQL, le moteur SQL de streaming pour Kafka, pour traiter vos données dans Kafka. KSQL est construit au-dessus de L'API Streams de Kafka, et il est également livré avec un support de première classe pour les "streams" et les "tables". Pensez-y comme le frère SQL de Kafka Streams où vous n'avez pas à écrire de code de programmation en Java ou Scala.
Quelle est la différence entre L'API grand public et les flux API?
API flux de Kafka ( https://kafka.apache.org/documentation/streams/) est construit sur les clients producteurs et consommateurs de Kafka. Il est beaucoup plus puissant et aussi plus expressif que le client consommateur Kafka. Voici quelques-unes des fonctionnalités de L'API Kafka Streams:
- prend en charge la sémantique de traitement exactement une fois (Kafka versions 0.11+)
- prend en charge le traitement avec État tolérant aux pannes, y compris le streaming jointures , agrégations, et fenêtrage
- soutient événement traitement en temps ainsi que le traitement basée sur temps de traitement et ingestion temps
- a un support de première classe pour les flux et les tables , où le traitement de flux rencontre les bases de données; en pratique, la plupart des applications de traitement de flux ont besoin à la fois de flux et de tables pour implémenter leurs cas d'utilisation respectifs, donc si une technologie de traitement de flux les deux abstractions (disons, pas de support pour les tables) vous sont bloquées ou doivent implémenter manuellement cette fonctionnalité vous - même (bonne chance avec ça...)
- prend en charge les requêtes interactives pour exposer les derniers résultats de traitement à d'autres applications et services)
- plus expressif: il est livré avec (1) un style de programmation fonctionnel DSL avec des opérations telles que
map,filter,reduceainsi que (2) un style impératif processeur API Pour par exemple faire complexe event processing (CEP), et (3) vous pouvez même combiner le DSL et L'API du processeur.
Voir 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. Il y a aussi un tutoriel basé sur Docker pour L'API Kafka Streams , que j'ai blogué sur plus tôt cette semaine.
Alors, en quoi L'API Kafka Streams est-elle différente, car elle consomme ou produit des messages vers Kafka?
Oui, L'API Kafka Streams peut à la fois lire des données et écrire des données dans Kafka.
Et pourquoi est-ce nécessaire car nous pouvons écrire notre propre application de consommation en utilisant L'API de consommation et les traiter au besoin ou les envoyer à Spark à partir de l'application de consommation?
Oui, vous pouvez écrire votre propre application grand public - comme je l'ai mentionné, L'API Kafka Streams utilise le client consommateur Kafka (plus le client producteur) lui-même-mais vous devrez implémenter manuellement toutes les fonctionnalités uniques fournies par L'API Streams. Voir la liste ci-dessus pour tout ce que vous obtenez "gratuitement". Il est donc plutôt rare qu'un utilisateur choisisse le client consommateur de bas niveau plutôt que L'API Kafka Streams plus puissante.