Apache Kafka vs Apache Pulsar: comment choisir

De nos jours, la messagerie de pub / sous-marin massivement évolutive est pratiquement synonyme d'Apache Kafka. Apache Kafka reste le choix incontournable et open source pour les applications de streaming distribuées, que vous ajoutiez quelque chose comme Apache Storm ou Apache Spark pour le traitement ou que vous utilisiez les outils de traitement fournis par Apache Kafka lui-même. Mais Kafka n'est pas le seul jeu en ville.

Développé par Yahoo et maintenant un projet Apache Software Foundation, Apache Pulsar vise la couronne de la messagerie qu'Apache Kafka porte depuis de nombreuses années. Apache Pulsar offre le potentiel d'un débit plus rapide et d'une latence plus faible qu'Apache Kafka dans de nombreuses situations, ainsi qu'une API compatible qui permet aux développeurs de passer de Kafka à Pulsar avec une relative facilité. 

Comment choisir entre le vénérable fidèle Apache Kafka et le parvenu Apache Pulsar? Examinons leurs principales offres open source et ce que les éditions d'entreprise des principaux responsables apportent à la table.

Apache Kafka

Développé par LinkedIn et publié en open source en 2011, Apache Kafka s'est largement répandu, devenant à peu près le choix par défaut pour beaucoup lorsqu'ils envisagent d'ajouter un bus de service ou un système pub / sous à une architecture. Depuis les débuts d'Apache Kafka, l'écosystème Kafka s'est considérablement développé, ajoutant le Scheme Registry pour appliquer les schémas dans la messagerie Apache Kafka, Kafka Connect pour un streaming facile à partir d'autres sources de données telles que les bases de données vers Kafka, Kafka Streams pour le traitement de flux distribué, et plus récemment KSQL pour effectuer des requêtes de type SQL sur des sujets Kafka. (Un sujet dans Kafka est le nom d'un canal particulier.)

Le cas d'utilisation standard de nombreux pipelines en temps réel construits au cours des dernières années a été de pousser des données dans Apache Kafka, puis d'utiliser un processeur de flux tel qu'Apache Storm ou Apache Spark pour extraire des données, effectuer et traiter, puis publier sortie vers un autre sujet pour la consommation en aval. Avec Kafka Streams et KSQL, tous vos besoins en pipeline de données peuvent être traités sans avoir à quitter le projet Apache Kafka à tout moment, même si bien sûr, vous pouvez toujours utiliser un service externe pour traiter vos données si nécessaire.

Bien qu'Apache Kafka ait toujours été très sympathique du point de vue d'un développeur, cela a été quelque peu mélangé sur le plan opérationnel. Mettre en place et exécuter un petit cluster est relativement facile, mais maintenir un gros cluster est souvent semé d'embûches (par exemple, échange de partition leader après une défaillance du courtier Kafka).

En outre, l'approche adoptée pour prendre en charge la multi-location, via un utilitaire appelé MirrorMaker, a été un moyen infaillible d'amener les SRE à se tirer les cheveux. En effet, MirrorMaker est considéré comme un tel problème que des entreprises comme Uber ont créé leur propre système de réplication entre les centres de données (uReplicator). Confluent inclut Confluent Replicator dans le cadre de son offre d'entreprise d'Apache Kafka. Parlant en tant que personne qui a dû maintenir une configuration MirrorMaker, il est dommage que Replicator ne fasse pas partie de la version open source.

Cependant, ce ne sont certainement pas toutes de mauvaises nouvelles sur le plan opérationnel. Beaucoup de travail a été fait dans la série actuelle d'Apache Kafka 1.x pour réduire certains des maux de tête liés à l'exécution d'un cluster. Récemment, certains changements ont permis au système d'exécuter de manière plus rationalisée de grands clusters de plus de 200 000 partitions, et des améliorations telles que l'ajout de files d'attente «lettre morte» à Kafka Connect facilitent l'identification et la récupération des problèmes dans les sources de données et les puits Plus facile. Nous sommes également susceptibles de voir une prise en charge au niveau de la production de l'exécution d'Apache Kafka sur Kubernetes en 2019 (via des graphiques Helm et un opérateur Kubernetes).

En 2014, trois des développeurs originaux de Kafka (Jun Rao, Jay Kreps et Neha Narkhede) ont formé Confluent, qui fournit des fonctionnalités d'entreprise supplémentaires dans sa plateforme Confluent, telles que le réplicateur susmentionné, le centre de contrôle, des plug-ins de sécurité supplémentaires et les offres habituelles de support et de services professionnels. Confluent propose également une offre cloud, Confluent Cloud, qui est un service Confluent Platform entièrement géré qui s'exécute sur Amazon Web Services ou Google Cloud Platform, si vous préférez ne pas gérer vous-même une partie de la surcharge opérationnelle liée à l'exécution des clusters.

Si vous êtes verrouillé dans AWS et que vous utilisez les services Amazon, notez qu'Amazon a introduit un aperçu public d'Amazon Managed Streaming for Kafka (MSK), qui est un service Kafka entièrement géré au sein de l'écosystème AWS. (Notez également qu'Amazon MSK n'est pas fourni en partenariat avec Confluent, donc l'exécution de MSK ne vous offrira pas toutes les fonctionnalités de Confluent Platform, mais uniquement ce qui est fourni dans Apache Kafka open source.)

Apache Pulsar

Compte tenu de la prédilection de l'Apache Software Foundation pour sélectionner des projets qui semblent dupliquer les fonctionnalités (aimeriez-vous Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark ou Apache Storm pour vos besoins de traitement de données de graphes acycliques dirigés?) soyez pardonné de regarder juste après les annonces concernant Apache Pulsar devenant un projet Apache de haut niveau avant de sélectionner Apache Kafka comme option de confiance pour vos besoins de messagerie. Mais Apache Pulsar mérite un coup d'œil.

Apache Pulsar est né chez Yahoo, où il a été créé pour répondre aux besoins de l'organisation que d'autres offres open source ne pouvaient pas fournir à l'époque. En conséquence, Pulsar a été entièrement conçu pour gérer des millions de sujets et de partitions avec une prise en charge complète de la géo-réplication et de la multi-location.

Sous les couvertures, Apache Pulsar utilise Apache BookKeeper pour maintenir ses besoins de stockage, mais il y a une torsion: Apache Pulsar a une fonctionnalité appelée Stockage hiérarchisé qui est tout à fait quelque chose. L'un des problèmes des systèmes de journaux distribués est que, même si vous souhaitez que les données restent dans la plate-forme de journalisation le plus longtemps possible, les lecteurs de disque ne sont pas de taille infinie. À un moment donné, vous prenez la décision de supprimer ces messages ou de les stocker ailleurs, où ils peuvent potentiellement être rejoués via le pipeline de données si nécessaire à l'avenir. Ce qui fonctionne, mais peut être compliqué sur le plan opérationnel. Apache Pulsar, via le stockage hiérarchisé, peut automatiquement déplacer des données plus anciennes vers Amazon S3, Google Cloud Storage ou Azure Blog Storage, tout en présentant une vue transparente vers le client;le client peut lire depuis le début comme si tous les messages étaient présents dans le journal.

Tout comme Apache Kafka, Apache Pulsar a développé un écosystème pour le traitement des données (bien qu'il fournisse également des adaptateurs pour Apache Spark et Apache Storm). Pulsar IO est l'équivalent de Kafka Connect pour la connexion à d'autres systèmes de données en tant que sources ou puits, et Pulsar Functions fournit des fonctionnalités de traitement de données. L'interrogation SQL est fournie à l'aide d'un adaptateur pour le moteur Presto open-source de Facebook.

Une ride intéressante est que les fonctions Pulsar et Pulsar IO s'exécutent dans un cluster Pulsar standard plutôt que d'être des processus séparés qui pourraient potentiellement s'exécuter n'importe où. Bien qu'il s'agisse d'une réduction de la flexibilité, cela rend les choses beaucoup plus simples d'un point de vue opérationnel. (Il existe un mode d'exécution local qui pourrait être utilisé de manière abusive pour exécuter des fonctions en dehors du cluster, mais la documentation fait tout son possible pour dire «Ne faites pas ça!»)

Apache Pulsar propose également différentes méthodes d'exécution des fonctions à l'intérieur du cluster: elles peuvent être exécutées en tant que processus séparés, en tant que conteneurs Docker ou en tant que threads s'exécutant dans le processus JVM d'un courtier. Cela rejoint le modèle de déploiement d'Apache Pulsar, qui prend déjà en charge Kubernetes ou Mesosphere DC / OS en production. Une chose à savoir est que les fonctions Pulsar, Pulsar IO et SQL sont des ajouts relativement nouveaux à Apache Pulsar, alors attendez-vous à quelques arêtes vives si vous les utilisez.

Il existe également un wrapper d'API limité, uniquement Java et compatible Kafka, vous pouvez donc potentiellement intégrer des applications Apache Kafka existantes dans une infrastructure Apache Pulsar. C'est probablement mieux adapté aux tests exploratoires et à un plan de migration intermédiaire qu'une solution de production, mais c'est bien d'avoir!

De la même manière que Confluent, les développeurs d'Apache Pulsar chez Yahoo (Matteo Merli et Sijie Guo) ont formé une société dérivée, Streamlio, dont ils sont co-fondateurs avec les créateurs d'Apache Heron (Karthik Ramasamy et Sanjeev Kulkarni) . L'offre d'entreprise de Streamlio comprend les solutions habituelles de support commercial et de services professionnels, ainsi qu'une console de gestion à source fermée, mais des éléments tels que le support mutualisé efficace et durable font partie du produit open source de base.

Apache Kafka ou Apache Pulsar?

Apache Kafka est un produit mature, résilient et éprouvé au combat. Il a des clients écrits dans presque tous les langages courants, ainsi qu'une multitude de connecteurs pris en charge pour différentes sources de données dans Kafka Connect. Avec les services gérés offerts par Amazon et Confluent, il est facile de mettre en place, d'exécuter et de maintenir un grand cluster Kafka, beaucoup plus facilement que les années précédentes. Je continue à utiliser Apache Kafka dans de nouveaux projets, et je le ferai probablement pendant de nombreuses années.

Cependant, si vous envisagez de créer un système de messagerie qui doit être multi-locataire ou géo-répliqué dès le départ, ou qui a des besoins de stockage de données importants, ainsi que la nécessité d'interroger et de traiter facilement toutes ces données, peu importe comment il y a longtemps dans le passé, alors je suggère de botter les pneus d'Apache Pulsar. Cela correspond certainement à certains cas d'utilisation avec lesquels Apache Kafka peut avoir du mal, tout en fonctionnant bien en termes de fonctionnalités de base dont vous avez besoin à partir d'une plate-forme de journaux distribués. Et si cela ne vous dérange pas d'être à la fine pointe en termes de documentation et de réponses aux questions Stack Overflow, tant mieux!