© GreenFlash/Shutterstock.com
Einführung in Apache Pulsar - Teil 2

Das Persistenzmodell von Pulsar


Egal, ob es sich um ein Event-getriebenes System oder um die Verteilung von Massendaten handelt: Robuste, performante und skalierfähige Datenhaltung ist für eine hochperformante Messaging-Lösung von elementarer Bedeutung. Im zweiten Teil unserer Artikelreihe zum Thema Apache Pulsar möchten wir daher unser Augenmerk auf das Persistenzmodell legen, das Pulsar mit Hilfe von Apache BookKeeper zur Verfügung stellt, und die grundlegenden Konzepte sowie einige mögliche Anwendungsfälle und Beispiele vorstellen.

In unserem Einführungsartikel zu Apache Pulsar haben wir uns bereits mit grundlegenden Konzepten der Messaging-Lösung vertraut gemacht. Dabei haben wir gelernt, dass eine publizierte Nachricht stets einem Topic zugeordnet ist, das entweder eine flüchtige Halde darstellt oder Nachrichten persistent vorhält. Topics setzen sich in der Standardkonfiguration aus einer einzigen Partition zusammen. Eine Partition kann ausschließlich von einem einzelnen Pulsar Broker bedient werden. Das heißt, dass der zugehörige Pulsar Broker sämtliche Lese- und Schreibanfragen an das Topic übernimmt und Apache BookKeeper für die entsprechende Koordination mit der unterliegenden Persistenzlösung sorgt. Bei hohem Anfragevolumen kann das zu einem Bottleneck auf Ebene des Pulsar Brokers führen. Um dieses Problem zu umgehen, ermöglicht Apache Pulsar die Partitionierung eines Topics in mehrere Partitionen. Jede dieser Partitionen ist einem dedizierten Pulsar Broker zugeordnet, was über der Menge an verfügbaren Pulsar Brokers für eine Gleichverteilung des Anfragevolumens sorgt.

Für die weitere Betrachtung vereinfachen wir den Anwendungsfall, indem wir uns auf reguläre Topics beschränken, die über eine einzige Partition verfügen. Grundsätzlich lassen sich die diskutierten Konzepte jedoch unmittelbar auf partitionierte Topics übertragen.

Ledgers und Fragments

Apache BookKeeper ist eine von Apache Pulsar unabhängige, Log-strukturierte Persistenzlösung. BookKeeper verteilt Daten auf einzelne Knoten, sogenannten Bookies, eines BookKeeper-Clusters. Für die Ablage von Verwaltungsinformationen und zum Überwachen der Knotenverfügbarkeit benutzt BookKeeper – ebenso wie Apache Pulsar – Apache ZooKeeper als Prozesskoordinator.

Topics und Partitionen stellen die logische Sicht aus der Perspektive von Apache Pulsar auf unsere Daten dar (Abb. 1). Topics folgen einer Log-orientierten Struktur. Das heißt, dass sich ein Topic aus einer fortlaufenden Sequenz kleinerer Einheiten zusammensetzt. Diese Einheit stellt Apache BookKeeper mit sogenannten Ledgers (dt. Register) zur Verfügung. Ein Ledger ist ebenfalls Log-strukturiert und gliedert sich in einzelne Fragments (dt. Fragmente), die wiederum der gleichen Struktur folgen und einzelne Datensätze in Form von Records in einer Append-Only-Schreibweise anhängen.

fresow_guenther_pulsar_2_1.tif_fmt1.jpgAbb. 1: Topics, Ledgers und Fragments als logische Einheiten der Komposition

Apache BookKeeper repliziert Fragments innerhalb eines Clusters an die verfügbaren Bookies, bzw. je nach Ledger-Konfiguration an eine Teilmenge derselben. Dabei sorgt BookKeeper dafür, dass nicht alle Fragments eines Ledgers auf dieselbe Menge von Bookies verteilt werden, sondern wählt für jedes Fragment eine potenziell andere Menge zuständiger Knoten aus. Über die Konfiguration eines Ledgers kann man auf drei wesentliche Größen zur Steuerung der Replikationseigenschaften dieses Mechanismus Einfluss nehmen. Grundsätzlich muss man sich dabei für einen Trade-off zwischen Latenz, Durchsatz und der Beständigkeit der Daten entscheiden.

  • Ensemble Size (E): die Anzahl von Knoten bzw. Bookies, auf die BookKeeper das Ledger verteilt. Die partizipierenden Bookies bezeichnet man als Ensemble.

  • Write Quorum Size (Qw): die Anzahl von Knoten, auf die ein Record geschrieben wird. Die Größe des Write Quorums ist gleichbedeutend mit dem maximalen Replikationsfaktor eines Records.

  • Ack Quorum Size (Qa): die Anzahl von Knoten, die das Durchschreiben eines Records bestätigen müssen, bevor Pulsar den Schreibvorgang erfolgreich gegenüber dem Aufrufer quittiert. Die Größe des Ack Quorums ist gleichbedeutend mit dem minimalen Replikationsfaktor eines Records.

Für diese Stellgrößen ist E ≥ Qw ≥ Qa invariant. Die Parametrierung nimmt man auf Topic-Ebene vor. Apache Pulsar sorgt dann für die entsprechende Konfiguration des Ledgers. Quorum-basierte Ansätze haben den Vorteil, dass man auf einer angemessenen Granularitätsebene Einfluss auf die Dienstgüte des Systems nehmen kann. Diesbezüglich wollen wir uns im Folgenden die Relation zwischen den Parametern E und Qw sowie Qw und Qa ansehen.

fresow_guenther_pulsar_2_2.tif_fmt1.jpgAbb. 2: Fragment mit vier Records repliziert an alle Bookies des Ensembles

Ist E = Qw, sorgt BookKeeper für die Replikation eines Records an jeden Bookie des Ensembles (Abb. 2).

fresow_guenther_pulsar_2_3.tif_fmt1.jpgAbb. 3: Fragment mit vier Records repliziert über eine Teilmenge aller Bookies des Ensembles

Ist E ≥ Qw, forciert man Striping (Abb. 3). Das heißt, dass BookKeeper das Write Quorum über einer zufälligen Teilmenge der Bookies eines Ensembles wählt. Die Größe dieser Teilmenge entspricht dem Parameter Qw. Striping erhöht potenziell den Durchsatz und sorgt gleichzeitig für eine niedrigere Latenz in den Antwortzeiten, da ein dedizierter Bookie nur noch für eine Teilmenge der eingehenden Lese- und Schreibanfragen zuständig ist.

Schlussendlich erhält jeder Bookie, der am Write Quorum partizipiert, ein Replikat des zu schreibenden Records. Man kann durch den Parameter Qa allerdings steuern, ab wann das Persistieren eines Records als Erfolg angesehen wird. Typischerweise ist es Qw = Qa, das uns die höchste Garantie für die Beständigkeit des geschriebenen Records gibt, da jeder Bookie den Schreibvorgang abgeschlossen haben muss, um diesen als Erfolg quittieren zu können. Das ist je nach Größe des Ack Quorums ein potenziell teurer Vorgang, da die Schreiblatenz stets durch den langsamsten Bookie bestimmt ist. Alternativ kann man beispielsweise Qa = Qw - 1 konfigurieren und schließt somit den langsamsten Schreiber aus dem Ack Quorum aus, was insbesondere zu Zeiten von Lastspitzen auf einzelnen Knoten trotzdem für vorhersagbare Latenzen sorgt.

Apache Pulsar stößt das Erzeugen eines Ledgers mit der Anlage eines neuen Topics an. Erreicht das aktive Ledger ein Zeitlimit oder überschreitet es eine Größenbeschränkung, wird das Ledger geschlossen und ein neues angelegt. Alle subsequenten Records wandern damit in das neue, aktive Ledger. Ähnlich verhält es sich mit Fragments. Ein Fragment wird mit der Anlage eines Ledgers erzeugt und immer dann geschlossen, wenn ein Bookie des Ensembles nicht in der Lage ist, den Schreibvorgang erfolgreich zu quittieren – unabhängig davon, ob es sich um einen tatsächlichen Fehler handelt oder der Bookie in einen Timeout gelaufen ist. In diesem Fall stößt Pulsar die Erzeugung eines neuen Fragments an. Das hat zur Folge, dass ein neues Ensemble der Größe Qw gebildet wird. Dieser Vorgang wiederholt sich so lange, bis BookKeeper eine Quittierung von Qa Bookies verzeichnen kann.

Ein neues Ledger wird auch dann erzeugt, wenn die Zugehörigkeit des umschließenden Topics auf einen anderen Pulsar Broker wechselt – beispielsweise, weil der vorher zuständige Pulsar Broker ausgefallen oder durch eine Netzwerkpartition nicht mehr erreic...

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