Apache Kafka gegen Apache Pulsar: Wie man wählt

Heutzutage ist massiv skalierbares Pub / Sub-Messaging praktisch gleichbedeutend mit Apache Kafka. Apache Kafka ist nach wie vor die erste Wahl für verteilte Streaming-Anwendungen, unabhängig davon, ob Sie Apache Storm oder Apache Spark für die Verarbeitung hinzufügen oder die von Apache Kafka selbst bereitgestellten Verarbeitungstools verwenden. Aber Kafka ist nicht das einzige Spiel in der Stadt.

Apache Pulsar wurde von Yahoo entwickelt und ist jetzt ein Projekt der Apache Software Foundation. Es strebt nach der Krone des Messaging, die Apache Kafka seit vielen Jahren trägt. Apache Pulsar bietet in vielen Situationen das Potenzial eines schnelleren Durchsatzes und einer geringeren Latenz als Apache Kafka sowie eine kompatible API, mit der Entwickler relativ einfach von Kafka zu Pulsar wechseln können. 

Wie sollte man sich zwischen dem ehrwürdigen, unerschütterlichen Apache Kafka und dem Emporkömmling Apache Pulsar entscheiden? Schauen wir uns ihre Open Source-Kernangebote an und was die Enterprise-Editionen der Core-Betreuer auf den Tisch bringen.

Apache Kafka

Apache Kafka wurde von LinkedIn entwickelt und 2011 als Open Source veröffentlicht. Es hat sich weit verbreitet und ist für viele zur Standardwahl geworden, wenn es darum geht, einer Architektur einen Servicebus oder ein Pub / Sub-System hinzuzufügen. Seit dem Debüt von Apache Kafka ist das Kafka-Ökosystem erheblich gewachsen. Es wurde die Scheme Registry hinzugefügt, um Schemas in Apache Kafka-Messaging zu erzwingen, Kafka Connect für das einfache Streaming von anderen Datenquellen wie Datenbanken zu Kafka, Kafka Streams für die verteilte Stream-Verarbeitung und zuletzt KSQL zum Durchführen einer SQL-ähnlichen Abfrage über Kafka-Themen. (Ein Thema in Kafka ist der Name für einen bestimmten Kanal.)

Der Standardanwendungsfall für viele Echtzeit-Pipelines, die in den letzten Jahren erstellt wurden, bestand darin, Daten in Apache Kafka zu übertragen und dann einen Stream-Prozessor wie Apache Storm oder Apache Spark zu verwenden, um Daten abzurufen, auszuführen und zu verarbeiten und dann zu veröffentlichen Ausgabe an ein anderes Thema für den nachgelagerten Verbrauch. Mit Kafka Streams und KSQL können alle Ihre Datenpipeline-Anforderungen bearbeitet werden, ohne das Apache Kafka-Projekt jederzeit verlassen zu müssen. Natürlich können Sie Ihre Daten bei Bedarf auch weiterhin über einen externen Dienst verarbeiten.

Während Apache Kafka aus Entwicklersicht immer sehr freundlich war, war es operativ eine gemischte Sache. Die Inbetriebnahme eines kleinen Clusters ist relativ einfach, die Wartung eines großen Clusters ist jedoch häufig mit Problemen behaftet (z. B. Austausch der Leader-Partition nach einem Kafka-Broker-Fehler).

Darüber hinaus war der Ansatz zur Unterstützung der Mandantenfähigkeit über ein Dienstprogramm namens MirrorMaker ein todsicherer Weg, um SREs dazu zu bringen, sich die Haare auszureißen. In der Tat wird MirrorMaker als solches Problem angesehen, dass Unternehmen wie Uber ein eigenes System für die Replikation über Rechenzentren hinweg erstellt haben (uReplicator). Confluent umfasst Confluent Replicator als Teil seines Unternehmensangebots von Apache Kafka. Als jemand, der ein MirrorMaker-Setup warten musste, ist es eine Schande, dass Replicator nicht Teil der Open Source-Version ist.

Es sind jedoch definitiv nicht alle schlechten Nachrichten im operativen Bereich. In der aktuellen Apache Kafka 1.x-Serie wurde viel Arbeit geleistet, um die Probleme beim Ausführen eines Clusters zu verringern. Vor kurzem gab es einige Änderungen, die es dem System ermöglichen, große Cluster mit mehr als 200.000 Partitionen effizienter zu betreiben, und Verbesserungen wie das Hinzufügen von Warteschlangen für "tote Buchstaben" zu Kafka Connect machen das Erkennen und Beheben von Problemen in Datenquellen und Senken so schwierig einfacher. Es ist auch wahrscheinlich, dass die Ausführung von Apache Kafka auf Kubernetes im Jahr 2019 auf Produktionsebene unterstützt wird (über Helm-Diagramme und einen Kubernetes-Operator).

Bereits 2014 gründeten drei der ursprünglichen Entwickler von Kafka (Jun Rao, Jay Kreps und Neha Narkhede) Confluent, das auf seiner Confluent-Plattform zusätzliche Unternehmensfunktionen wie den oben genannten Replikator, das Control Center, zusätzliche Sicherheits-Plug-Ins und die üblichen Support- und Professional Services-Angebote. Confluent bietet auch das Cloud-Angebot Confluent Cloud, einen vollständig verwalteten Confluent Platform-Dienst, der auf Amazon Web Services oder Google Cloud Platform ausgeführt wird, wenn Sie den Betriebsaufwand für die Ausführung von Clustern nicht selbst übernehmen möchten.

Wenn Sie an AWS gebunden sind und Amazon-Dienste verwenden, beachten Sie, dass Amazon eine öffentliche Vorschau von Amazon Managed Streaming für Kafka (MSK) eingeführt hat, einem vollständig verwalteten Kafka-Dienst innerhalb des AWS-Ökosystems. (Beachten Sie auch, dass Amazon MSK nicht in Zusammenarbeit mit Confluent bereitgestellt wird. Wenn Sie also MSK ausführen, erhalten Sie nicht alle Funktionen der Confluent Platform, sondern nur die Funktionen des Open Source-Apache Kafka.)

Apache Pulsar

Angesichts der Vorliebe der Apache Software Foundation, Projekte aufzunehmen, die scheinbar doppelte Funktionen aufweisen (möchten Sie Apache Apex, Apache Flink, Apache Heron, Apache Samza, Apache Spark oder Apache Storm für Ihre Anforderungen an die gezielte Verarbeitung azyklischer Diagrammdaten?), Würden Sie dies tun Verzeihen Sie, dass Sie direkt über die Ankündigungen hinausschauen, dass Apache Pulsar ein Apache-Projekt der obersten Ebene wird, bevor Sie Apache Kafka als vertrauenswürdige Option für Ihre Messaging-Anforderungen auswählen. Aber Apache Pulsar verdient einen Blick.

Apache Pulsar wurde bei Yahoo geboren, wo es entwickelt wurde, um die Anforderungen der Organisation zu erfüllen, die andere Open-Source-Angebote zu diesem Zeitpunkt nicht bieten konnten. Infolgedessen wurde Pulsar von Grund auf für die Bearbeitung von Millionen von Themen und Partitionen mit vollständiger Unterstützung für Georeplikation und Mandantenfähigkeit entwickelt.

Unter dem Deckmantel verwendet Apache Pulsar Apache BookKeeper, um seine Speicheranforderungen aufrechtzuerhalten, aber es gibt eine Wendung: Apache Pulsar hat eine Funktion namens Tiered Storage, die ziemlich viel ist. Eines der Probleme verteilter Protokollsysteme besteht darin, dass die Datenlaufwerke nicht unendlich groß sind, obwohl die Daten so lange wie möglich auf der Protokollplattform verbleiben sollen. Irgendwann treffen Sie die Entscheidung, diese Nachrichten entweder zu löschen oder an anderer Stelle zu speichern, wo sie möglicherweise bei Bedarf in Zukunft über die Datenpipeline wiedergegeben werden können. Was funktioniert, kann aber betrieblich kompliziert sein. Apache Pulsar kann über Tiered Storage ältere Daten automatisch in Amazon S3, Google Cloud Storage oder Azure Blog Storage verschieben und dem Client dennoch eine transparente Ansicht zurückgeben.Der Client kann von Anfang an so lesen, als ob alle Nachrichten im Protokoll vorhanden wären.

Genau wie Apache Kafka hat Apache Pulsar ein Ökosystem für die Datenverarbeitung aufgebaut (obwohl es auch Adapter für Apache Spark und Apache Storm bietet). Pulsar IO entspricht Kafka Connect für die Verbindung mit anderen Datensystemen als Quelle oder Senke, und Pulsar Functions bietet Datenverarbeitungsfunktionen. SQL-Abfragen werden mithilfe eines Adapters für die Open-Source-Presto-Engine von Facebook bereitgestellt.

Eine interessante Falte ist, dass Pulsar-Funktionen und Pulsar-E / A in einem Standard-Pulsar-Cluster ausgeführt werden und keine separaten Prozesse sind, die möglicherweise überall ausgeführt werden könnten. Dies ist zwar eine Verringerung der Flexibilität, macht die Dinge jedoch aus betrieblicher Sicht viel einfacher. (Es gibt einen lokalen Ausführungsmodus, der missbraucht werden könnte, um Funktionen außerhalb des Clusters auszuführen, aber in der Dokumentation wird nicht angegeben, dass dies nicht der Fall ist.)

Apache Pulsar bietet auch verschiedene Methoden zum Ausführen von Funktionen innerhalb des Clusters: Sie können als separate Prozesse, als Docker-Container oder als Threads ausgeführt werden, die im JVM-Prozess eines Brokers ausgeführt werden. Dies knüpft an das Bereitstellungsmodell für Apache Pulsar an, das Kubernetes oder Mesosphere DC / OS bereits in der Produktion unterstützt. Beachten Sie, dass Pulsar-Funktionen, Pulsar IO und SQL relativ neue Ergänzungen zu Apache Pulsar sind. Erwarten Sie daher einige scharfe Kanten, wenn Sie sie verwenden.

Es gibt auch einen eingeschränkten, nur Java-fähigen, Kafka-kompatiblen API-Wrapper, sodass Sie möglicherweise vorhandene Apache Kafka-Anwendungen in eine Apache Pulsar-Infrastruktur integrieren können. Dies ist wahrscheinlich besser für Erkundungstests und einen vorläufigen Migrationsplan geeignet als eine Produktionslösung, aber es ist schön zu haben!

Ähnlich wie bei Confluent haben die Entwickler von Apache Pulsar bei Yahoo (Matteo Merli und Sijie Guo) eine Spin-off-Firma, Streamlio, gegründet, in der sie zusammen mit den Machern von Apache Heron (Karthik Ramasamy und Sanjeev Kulkarni) Mitbegründer sind. . Das Unternehmensangebot von Streamlio umfasst den üblichen kommerziellen Support und professionelle Servicelösungen sowie eine Closed-Source-Verwaltungskonsole. Dinge wie effizienter und dauerhafter mandantenfähiger Support sind jedoch Teil des Open-Source-Kernprodukts.

Apache Kafka oder Apache Pulsar?

Apache Kafka ist ein ausgereiftes, belastbares und kampferprobtes Produkt. Es verfügt über Clients, die in fast jeder gängigen Sprache geschrieben sind, sowie eine Vielzahl unterstützter Konnektoren für verschiedene Datenquellen in Kafka Connect. Mit den von Amazon und Confluent angebotenen verwalteten Diensten ist es einfach, einen großen Kafka-Cluster einzurichten, auszuführen und zu warten - viel einfacher als in den Vorjahren. Ich verwende Apache Kafka weiterhin in neuen Projekten und werde dies wahrscheinlich noch viele Jahre tun.

Wenn Sie jedoch ein Messaging-System erstellen möchten, das von Anfang an mandantenfähig oder georepliziert sein muss oder einen großen Datenspeicherbedarf hat, sowie die Notwendigkeit, all diese Daten einfach abzufragen und zu verarbeiten, egal wie Vor langer Zeit, dann schlage ich vor, die Reifen von Apache Pulsar zu treten. Es passt definitiv zu einigen Anwendungsfällen, mit denen Apache Kafka zu kämpfen hat, und funktioniert auch gut in Bezug auf die Kernfunktionen, die Sie von einer verteilten Protokollplattform benötigen. Und wenn es Ihnen nichts ausmacht, in Bezug auf Dokumentation und beantwortete Fragen zum Stapelüberlauf auf dem neuesten Stand zu sein, umso besser!