Quels sont les avantages et les inconvénients de Kafka par rapport à Apache Pulsar ?

Question

Yahoo a développé Pulsar, un système de messagerie de type pub-sub, et l'a rendu open source. C'est maintenant un projet d'incubation d'Apache. Depuis, Kafka est également utilisé dans le même but. Vous voulez savoir quels sont les principaux avantages et inconvénients de Kafka par rapport à Pulsar.

Answer 1

J'ai joué un peu avec les deux dernièrement, et voici ce que j'en ai retiré.

Neutre :

• J'allais faire gagner Kafka sur la communauté/documentation etc. Mais je n'ai pas pu trouver facilement les réponses aux questions que j'avais sur Kafka, certaines étaient anciennes et confuses (visant l'ancienne API). Mais la documentation de Pulsar est suffisamment bonne, les développeurs sont très réactifs sur Slack (hello @Matteo Merli :) ). et les éléments sous-jacents (Zookeeper, Bookkeeper) disposent également d'une documentation décente si vous souhaitez vous plonger dans les détails internes.
• Kafka vise un débit élevé, Pulsar une faible latence. Tous deux fournissent des paramètres pour la contrôler.
• Tous deux sont prêts pour la production et ont été testés dans plusieurs entreprises.

Pro pulsar :

• D'après mon expérience, l'API est plus facile à utiliser. Dans Kafka, le courtier est muet et les consommateurs se chargent de structurer les communications comme ils l'entendent. Cette flexibilité a pour contrepartie que l'utilisateur de Kafka doit comprendre comment faire pour que les pièces s'assemblent. Je suppose que le bénéfice attendu est une plus grande flexibilité, mais puisque Pulsar a été capable de reproduire l'API des consommateurs de Kafka (et avec assez peu de code), je donne cela comme un avantage à Pulsar.
• vous pouvez faire des choses qui ne sont pas faciles à faire (ou peut-être impossibles dans Kafka) : multi-tenancy (sécurité, isolation...), gestion des ressources (étranglement des sujets, quotas), géo-réplication.
• Il possède certaines fonctionnalités qui font actuellement défaut à Kafka, comme la recherche d'un MessageId particulier.
• Pulsar s'adapte à des millions de sujets, alors que Kafka est limité par la façon dont il structure les données dans Zookeeper.
• Un déploiement plus facile. Un Pulsar autonome va démarrer son propre Zookeeper local, et j'ai personnellement trouvé la configuration plus facile à comprendre.
• écrit en Java, par opposition à un mélange de code Scala et Java hérité. J'ai également trouvé la base de code bien organisée et beaucoup plus facile à suivre. En partie parce qu'il s'appuie sur Zookeeper et Bookkeeper, qui sont des projets externes avec leur propre documentation/communauté/développeurs, etc. (veuillez noter qu'ils font également partie de la fondation Apache, et qu'ils proviennent également de Yahoo, donc ils fonctionnent bien ensemble).

Pro Kafka :

• Kafka a des choses construites au-dessus comme Kafka Streams (je ne l'ai jamais utilisé donc je ne peux pas dire s'il y a un équivalent).

Lisez aussi :

• https://news.ycombinator.com/item?id=12453080
• https://news.ycombinator.com/item?id=15601222
• https://streaml.io/blog/why-apache-pulsar/
• https://kafka.apache.org/uses

Answer 2

Apache Kafka est plus mature (il existe depuis plus longtemps) et possède des API de plus haut niveau (par exemple, KStreams). Sa maturité limite cependant la fluidité et la flexibilité, par exemple, ~500 PR ouverts sur github.

Apache Pulsar a étudié en profondeur les décisions de conception d'Apache Kafka, et a incorporé une conception améliorée et un ensemble de capacités passionnantes, à savoir l'idée de espacement des noms et permettre aux ACL ou aux quotas d'être appliqués au niveau de l'espace-nom semble être une très bonne idée, pour fournir une meilleure qualité de service. multi-location soutien. D'autres caractéristiques intéressantes de Pulsar sont les suivantes géo-réplication ainsi que le unification des files d'attente et des flux

Answer 3

Nous avions besoin d'une plateforme de streaming avec des sujets persistants, une latence raisonnable et un débit élevé. Récemment, nous avons évalué si nous devions opter pour Kafka ou Pulsar et, contrairement à @nha, nous sommes désormais favorables à Apache Kafka. Voici nos conclusions :

Pulsar - Les avantages

• riche en fonctionnalités - sujets persistants/non persistants, multitenance, ACLs, réplication multi-DC, etc.
• une API client plus souple, comprenant des CompletableFutures, des interfaces fluides, etc.
• les composants clients java sont thread safe - le consommateur peut accuser réception des messages provenant de différents threads

Pulsar - Contre

• le client java a peu ou pas de javadoc
• petite communauté - 8 questions stackoverflow actuellement
• Le concept de messageId est lié à BookKeeper - les consommateurs ne peuvent pas se positionner facilement sur le sujet par rapport au décalage de Kafka qui est une séquence continue de nombres.
• Le lecteur ne peut pas lire facilement le dernier message du sujet - il doit parcourir tous les messages jusqu'à la fin.
• aucune transaction
• plus grande complexité opérationnelle - Zookeeper + nœuds Broker + BookKeeper - tous en cluster
• latence discutable - il y a un appel à distance supplémentaire entre le nœud Broker et BookKeeper (par rapport à Kafka)

Kafka - Les avantages

• javadoc très riche et utile
• Kafka Streams
• communauté mature et large
• plus simple à exploiter en production - moins de composants - le nœud de courtage fournit également le stockage
• transactions - lectures et écritures atomiques au sein des sujets
• les décalages forment une séquence continue - le consommateur peut facilement chercher le dernier message

Kafka - Cons

• le consommateur ne peut pas accuser réception d'un message provenant d'un autre thread
• pas de multilocation
• pas de réplication Multi-DC robuste - (offerte dans Confluent Enterprise)

Answer 4

source

---

Pulsar, le dernier projet de l'Apache Software Foundation à atteindre le statut de projet de premier niveau, est très souvent comparé à Kafka, un autre projet de l'ASF.

Pulsar est une plateforme de messagerie hautement évolutive et à faible latence fonctionnant sur du matériel de base. Elle offre une sémantique simple de pub-sub et de file d'attente sur les sujets, un cadre de calcul léger, une gestion automatique des curseurs pour les abonnés et une réplication entre centres de données.

Pendant ce temps, le rapport Apache Kafka 2018, qui a interrogé plus de 600 utilisateurs, a constaté que les pipelines de données et la messagerie étaient les deux principales utilisations de la technologie. Il a constaté une utilisation croissante avec l'essor des architectures microservices.

"Les cas d'utilisation des deux systèmes se recoupent largement, mais les conceptions initiales étaient très différentes", a déclaré Matteo Merli, l'un de ses créateurs qui a depuis formé Streamlio, une startup proposant une plateforme de données rapides.

Yahoo a créé Pulsar en tant que système unique multi-tenant comme solution à ses problèmes de systèmes de messagerie multiples et d'équipes multiples les déployant.

Il a été publié en open source en 2016 et est entré dans l'incubateur ASF en juin 2017. Depuis environ quatre ans, elle est utilisée dans les applications Yahoo Mail, Finance, Sports, Gemini Ads et Sherpa, le service distribué clé-valeur de Yahoo.

Dans un billet de blog, le cofondateur Sijie Guo a résumé Pulsar et Kafka de la manière suivante :

"Apache Pulsar combine le streaming haute performance (que poursuit Apache Kafka) et la mise en file d'attente traditionnelle flexible (que poursuit RabbitMQ) dans un modèle de messagerie et une API unifiés. Pulsar vous offre un seul système pour le streaming et la mise en file d'attente, avec les mêmes performances élevées, en utilisant une API unifiée."

Selon M. Merli, "il y a des différences entre le streaming et la mise en file d'attente ; il y a de nombreux cas d'utilisation où vous avez besoin de l'un ou de l'autre, mais la plupart des gens ont besoin des deux pour différents cas d'utilisation."

Architecture à deux couches Une conception à deux couches est la clé de Pulsar, a déclaré M. Merli. Il y a une couche de courtiers sans état qui reçoivent et délivrent les messages, et une couche de persistance avec état, avec un ensemble de nœuds de stockage Apache BookKeeper appelés bookies qui fournissent un stockage durable à faible latence.

Pulsar a été construit sur l'idée d'avoir des garanties de données solides, a déclaré Merli. Il a été conçu pour la consommation partagée, alors que Kafka ne l'était pas. Et Pulsar permet aux utilisateurs de configurer une période de rétention des messages, même après que tous les abonnements les aient consommés.

Son architecture en couches et son stockage centré sur les segments constituent des avantages essentiels :

Vous pouvez faire évoluer les courtiers ou la couche de stockage indépendamment. Comme les brokers sont sans état, un sujet peut être rapidement déplacé vers d'autres brokers. Cela ouvre une voie efficace pour équilibrer le trafic entre les brokers. Il est possible d'avoir plusieurs consommateurs sur la même partition et vous pouvez en ajouter autant que vous le souhaitez. Comme aucune donnée n'est stockée localement, il n'est pas nécessaire de copier les données de la partition lors de l'expansion de la capacité et aucun rééquilibrage n'est nécessaire. Lorsqu'un sujet partitionné est créé, Pulsar partitionne automatiquement les données d'une manière agnostique pour les consommateurs et les producteurs.

Le courtier envoie les données des messages à plusieurs nœuds BookKeeper, qui écrivent les données dans un journal en écriture anticipée et en gardent également une copie en mémoire. Avant que le nœud n'envoie un accusé de réception, le journal est écrit de force sur un stockage stable, ce qui garantit la rétention même en cas de coupure de courant. Les partitions de sujets peuvent évoluer jusqu'à la capacité totale du cluster BookKeeper, et vous pouvez faire évoluer un cluster en ajoutant simplement des nœuds.

Depuis l'entrée dans l'incubateur, nous nous sommes attachés à faciliter le démarrage de Pulsar.

La version 2.0 de Pulsar a été publiée en juin. Elle comprend une fonction de traitement "native" appelée Pulsar Functions, qui permet aux utilisateurs d'écrire des fonctions de traitement en Java ou en Python pour les données qui circulent dans le pipeline. La version 2.2 sera bientôt disponible et comprendra une fonction d'interrogation SQL interactive.

Pulsar offre de multiples liaisons de langage et de protocole, notamment Java, C++, Python et WebSockets, ainsi qu'une API compatible avec Kafka.

---

Pour en savoir plus : Apache Pulsar : Est-il un tueur de KAFKA ?

Apache Pulsar : Est-il un tueur de KAFKA ? Écrit par Bhagwan s. Soni

---

POURQUOI choisir Apache Pulsar plutôt que Kafka ?

Apache Pulsar est une édition d'entreprise de PubSub, développée à l'origine par Yahoo et maintenant soutenue par Apache Software Foundation. Apache Pulsar fonctionne sur des systèmes de production depuis plus de 3 ans et a prouvé sa stabilité.

Apache Pulsar couvre presque toutes les fonctionnalités que Kafka nous offre, peut-être avec des noms différents. Pulsar a de nombreuses fonctionnalités mais je voudrais en souligner certaines qui nous aideront à nous différencier de Kafka.

1} Apache Pulsar vous donne 3 types d'abonnement sur le sujet : A} Exclusif  - Un seul consommateur consommera les données d'un sujet. B} Partagé  - Plusieurs consommateurs vont consommer les données d'un sujet C} Basculement  - Plus d'un consommateur, mais à un moment donné, un seul consommera les données.

2} Chaque espace de nom peut avoir un ou plusieurs sujets.

3} Un soutien fort pour la Multitanence

4} Réplication des données sur plusieurs clusters

5} Support solide de la durabilité des messages contre la perte de données

---