© MSSA/Shutterstock.com
Einführung in Apache Pulsar - Teil 1

Technisch-konzeptionelle Annäherung


Messagingsysteme sind in aller Munde, und während sich in den letzten Jahren besonders Apache Kafka sehr großer Beliebtheit erfreute, gibt es mit Apache Pulsar jetzt einen neuen Konkurrenten. Angetreten ist der mit dem selbstbewussten Versprechen, die Stärken des hochperformanten Streamingansatzes von Kafka mit zusätzlichen Garantien und Funktionen abzurunden. Zum Auftakt der Artikelreihe werden wir uns Pulsar von der technisch-konzeptionellen Seite nähern und mit praktischen Beispielen zeigen, wie Pulsar in einem Projekt eingesetzt werden kann.

Pulsar blickt auf eine Entwicklungsgeschichte von inzwischen sieben Jahren zurück und wurde zunächst als internes Projekt bei Yahoo entwickelt, um den Eigenbedarf an einer skalierenden, hochperformanten Messaginglösung zu decken. Der Schritt in Richtung Open Source und damit zur allgemeinen Verfügbarkeit erfolgte im September 2016 [1]. Knapp neun Monate später wurde bereits der Weg geebnet, Pulsar zu einem Apache-Projekt zu machen [2]. Den Status als Top-Level-Apache-Projekt hat Pulsar seit dem 19. September 2018 inne und firmiert seitdem unter dem Namen Apache Pulsar [3].

Konzeptionell erscheint Pulsar auf den ersten Blick ähnlich dem Schwesterprojekt Apache Kafka. Beide Systeme bieten ein Pub-Sub-Messagingmodell mit Topics, die intern in Partitionen unterteilt und somit skalierbar sind, und setzen auf Apache ZooKeeper zur Koordination der einzelnen Knoten. Doch schon bei einem kurzen Blick hinter die Kulissen sieht man starke architekturelle Unterschiede. Während Kafka eine Partition in Form eines segmentierten Append-only-Logs auf den Knoten abbildet, haben Segmente in Pulsar-Partitionen eine zusätzliche Bedeutung. Pulsar-Segmente folgen zwar ebenso einer Append-only-Semantik, aber mit Apache BookKeeper wird ein weiteres externes System genutzt, das sich um die Verteilung und Speicherung der Daten kümmert. Abbildung 1 zeigt auf Systemebene, welche Komponenten bei einem Pulsar-Cluster beteiligt sind.

guenther_fresow_pulsar_1.tif_fmt1.jpgAbb. 1: Übersicht über die Systemkomponenten von Apache Pulsar

Die Segmentierung der Partitionen unter Verwendung von BookKeeper ermöglicht es Pulsar, interessante Features und Garantien zu bieten, da die Persistenz von den Broker-Knoten entkoppelt ist – die Speicherung übernehmen einzelne „Bookies“. Als Folge ist zum einen die Skalierung der Persistenz unabhängig von der Anzahl der Broker, was theoretisch beliebig große Topics erlaubt und nicht mehr vom lokal verfügbaren Festplattenspeicher abhängt. Zum anderen ermöglicht es Tiered Storage ab Werk und macht ein – in der Regel teures – Rebalancing bei Änderung der Clustergröße ebenfalls unnötig. Abbildung 2 gibt einen groben Überblick über das Persistenzmodell von Pulsar, die Details und Feinheiten von BookKeeper würden den Rahmen dieses Artikels sprengen.

guenther_fresow_pulsar_2.tif_fmt1.jpgAbb. 2: Pulsar-Persistenzmodell

Wie bei allen verteilten, zustandsbehafteten Systemen darf auch bei Apache Pulsar ein Blick hinsichtlich der logischen Limitierung im Falle einer Netzwerkpartitionierung nicht fehlen. Nach dem CAP-Theorem muss ein System, das partitionstolerant ist, sich zwischen Verfügbarkeit der Anwendung und Konsistenz der Daten entscheiden. Hier schlägt sich Pulsar – ähnlich wie ZooKeeper und BookKeeper – auf die Seite der Datenkonsistenz. Mit dem Selbstanspruch, Datenverlust auszuschließen sowie starke Ordnungsgarantien und eine vorhersagbare Latenz für Lese- und Schreiboperationen zu bieten, gewichtet Pulsar die Konsistenz höher als eine höchstmögliche Verfügbarkeit.

Konzepte

Nachrichten: Eine Nachricht ist die Einheit des Datenaustauschs einer Pulsar-gestützten Architektur. Neben den Nutzdaten (Payload) kapselt eine Nachricht Metadaten wie bspw. den Zeitstempel der Publikation oder einen optionalen Nachrichtenschlüssel. Pulsar-Nachrichten unterstützen eine bitemporale Zeitstempelung, sodass man bspw. die Event-Zeit zusätzlich mitführen kann. Das ist insbesondere für Anwendungen interessant, die eine Stream-orientierte Verarbeitungssemantik implementieren. Zu einer Nachricht kann man weitere, anwendungsspezifische Key-Value-Paare hinzufügen. Apache Pulsar betrachtet eine Nachricht als Teil einer geordneten Sequenz innerhalb des korrespondierenden Topics. Dadurch ist Apache Pulsar in der Lage, bei Zustellung von Nachrichten eine Ordnungsgarantie zu gewährleisten. Auf Transportebene implementiert Apache Pulsar ein Binärprotokoll zum Austausch von Nachrichten.

Topics: Publizierte Nachrichten sind stets einem Topic zugeordnet. Apache Pulsar unterscheidet zwischen persistenten und nichtpersistenten Topics. Erstere sorgen dafür, dass ein Pulsar Broker alle Nachrichten dauerhaft auf ein Storage-Device schreibt. Dagegen sind Nachrichten, die in ein nichtpersistentes Topic geschrieben werden, flüchtig und bspw. nach einem Ausfall des Pulsar-Clusters verloren.

Apache Pulsar ist auf Topic-Ebene mandantenfähig und erlaubt eine zusätzliche Gruppierung in Namespaces innerhalb eines Mandanten. Dadurch kann man eine feingranulare, logische Sicht auf die Daten innerhalb eines Pulsar-Clusters über das Admin-API von Apache Pulsar definieren und behält auch bei umfangreichen datenzentrischen Architekturen den Überblick.

Die Identifikation eines Topics folgt den Konventionen des RFC 1738 (Uniform Resource Locators) und ist damit syntaktisch ein URL. Dabei lassen sich diverse Charakteristiken eines Topics bereits über dessen Topic URL ableiten. Als Beispiel sei der Topic URL non-persistent://my-tenant/my-namespace/my-topic genannt. Hieraus ist ersichtlich, dass es sich bei dem Topic mit dem Namen my-topic um ein nichtpersistentes Topic handelt, das dem Mandanten my-tenant zugeordnet ist und innerhalb dieses Mandanten im Namespace my-namespace lebt. Es mag zunächst widersprüchlich erscheinen, aber logisch konsequent bedeutet das, dass persistent://my-tenant/my-namespace/my-topic ein anderes, als das vorher gewählte Topic bezeichnet.

Apache Pulsar bietet zusätzliche Konfigurationsmöglichkeiten für Topics an. Topic-Konfigurationen nimmt man dabei üblicherweise auf der Ebene von Namespaces vor, dementsprechend gelten diese Konfigurationen für alle in diesem Namespace enthaltenen Topics.

Partitionierte Topics: Ein reguläres Topic besteht aus einer einzigen Partition und kann daher ausschließlich von einem einzelnen Pulsar Broker bedient werden. Für viele Anwendungsfälle mag das in Ordnung sein, aber insbesondere in Szenarien, in...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang