© Excellent backgrounds/Shutterstock.com
Java Magazin
Massive Datenströme mit Apache Kafka

Kafka 101

Apache Kafka ist ein verteilter, partitionierender und replizierender Service für Datenströme. Er stellt seine Funktionen wie ein klassischer Messaging Broker zur Verfügung, allerdings unter der Verwendung von Konzepten, die sich von den bisher gängigen deutlich unterscheiden. Im Rahmen dieses Artikels werden wir die wichtigsten dieser Konzepte und den Grund für deren effektive Performance beleuchten und mithilfe von Anwendungsbeispielen veranschaulichen.

Frank Wisniewski, Lars Pfannenschmidt


Kafka wird in der Regel in einem Cluster betrieben, bei dem jeder einzelne Knoten Broker genannt wird. Datenströme innerhalb des Clusters können in so genannte Topics kategorisiert werden. Ferner unterscheidet man zwischen Prozessen, die Nachrichten erzeugen (Producer), und Prozessen, die Nachrichten konsumieren (Consumer) (Abb. 1). Die Kommunikation zwischen Producer, Broker und Consumer findet mithilfe eines sprachenunabhängigen TCP-Protokolls statt. Durch diese Abstraktionsschicht werden Clientbibliotheken für unterschiedliche Programmiersprachen ermöglicht.

Abb. 1: Topologische Übersicht: Producer, Broker, Consumer nach [1]

Topics und Partitionen

Nachrichten werden auf Topics veröffentlicht, wobei eine Nachricht aus einem optionalen Schlüssel und dessen Wert besteht. Kafka erstellt für jedes Topic konfigurierbar viele Partitionen, die jeweils ein sortiertes und unveränderliches Protokoll darstellen, an das kontinuierlich Nachrichten angehängt werden, das Commit Log (Abb. 2). Jeder Nachricht in einer Partition wird ein sequenzieller Schlüssel zugewiesen, das Offset. Dieses Offset ist die einzige Metainformation, die zusätzlich zur eigentlichen Nachricht gespeichert wird.

Abb. 2: Die Anatomie eines Topics nach [1]

Das Aufteilen von Topics auf n Partitionen ermöglicht es, dass ein Server nicht den Platz für ein gesamtes Topic bereitstellen muss, sondern nur für dessen n-ten Teil. Zusätzlich kann die Last von Producern und Consumern im Broker-Cluster verteilt und jede Partition für den Fehlerfall repliziert werden.

Ein Broker behält jede veröffentlichte Nachricht für einen konfigurierbaren Zeitraum vor, standardmäßig sieben Tage, oder bis eine definierbare Maximalgröße erreicht ist, unabhängig davon, ob diese bereits konsumiert wurde oder nicht. Nach Ablauf dieses Zeitfensters wird die Nachricht gelöscht. Da Kafkas Performance unabhängig von der Größe des commit logs konstant bleibt, kann eine große Nachrichtenmasse problemlos gespeichert werden.

Offset-Management

Das Offset, das definiert, welche Nachricht gelesen werden soll, wird anders als beim klassischen Messaging vom Consumer selbst gesteuert. Da außerdem das Commit Log kontinuierlich erweitert wird, können so Lese- und Schreibzugriffe auf der Festplatte größtenteils sequenziell erledigt werden. Diese Art der Persistierung von Daten ist in einem solchen verteilten System deutlich leistungsfähiger als der klassische Ansatz.

In der Regel wird beim Empfang von Nachrichten das Offset kontinuierlich erhöht, um...

Java Magazin
Massive Datenströme mit Apache Kafka

Kafka 101

Apache Kafka ist ein verteilter, partitionierender und replizierender Service für Datenströme. Er stellt seine Funktionen wie ein klassischer Messaging Broker zur Verfügung, allerdings unter der Verwendung von Konzepten, die sich von den bisher gängigen deutlich unterscheiden. Im Rahmen dieses Artikels werden wir die wichtigsten dieser Konzepte und den Grund für deren effektive Performance beleuchten und mithilfe von Anwendungsbeispielen veranschaulichen.

Frank Wisniewski, Lars Pfannenschmidt


Kafka wird in der Regel in einem Cluster betrieben, bei dem jeder einzelne Knoten Broker genannt wird. Datenströme innerhalb des Clusters können in so genannte Topics kategorisiert werden. Ferner unterscheidet man zwischen Prozessen, die Nachrichten erzeugen (Producer), und Prozessen, die Nachrichten konsumieren (Consumer) (Abb. 1). Die Kommunikation zwischen Producer, Broker und Consumer findet mithilfe eines sprachenunabhängigen TCP-Protokolls statt. Durch diese Abstraktionsschicht werden Clientbibliotheken für unterschiedliche Programmiersprachen ermöglicht.

Abb. 1: Topologische Übersicht: Producer, Broker, Consumer nach [1]

Topics und Partitionen

Nachrichten werden auf Topics veröffentlicht, wobei eine Nachricht aus einem optionalen Schlüssel und dessen Wert besteht. Kafka erstellt für jedes Topic konfigurierbar viele Partitionen, die jeweils ein sortiertes und unveränderliches Protokoll darstellen, an das kontinuierlich Nachrichten angehängt werden, das Commit Log (Abb. 2). Jeder Nachricht in einer Partition wird ein sequenzieller Schlüssel zugewiesen, das Offset. Dieses Offset ist die einzige Metainformation, die zusätzlich zur eigentlichen Nachricht gespeichert wird.

Abb. 2: Die Anatomie eines Topics nach [1]

Das Aufteilen von Topics auf n Partitionen ermöglicht es, dass ein Server nicht den Platz für ein gesamtes Topic bereitstellen muss, sondern nur für dessen n-ten Teil. Zusätzlich kann die Last von Producern und Consumern im Broker-Cluster verteilt und jede Partition für den Fehlerfall repliziert werden.

Ein Broker behält jede veröffentlichte Nachricht für einen konfigurierbaren Zeitraum vor, standardmäßig sieben Tage, oder bis eine definierbare Maximalgröße erreicht ist, unabhängig davon, ob diese bereits konsumiert wurde oder nicht. Nach Ablauf dieses Zeitfensters wird die Nachricht gelöscht. Da Kafkas Performance unabhängig von der Größe des commit logs konstant bleibt, kann eine große Nachrichtenmasse problemlos gespeichert werden.

Offset-Management

Das Offset, das definiert, welche Nachricht gelesen werden soll, wird anders als beim klassischen Messaging vom Consumer selbst gesteuert. Da außerdem das Commit Log kontinuierlich erweitert wird, können so Lese- und Schreibzugriffe auf der Festplatte größtenteils sequenziell erledigt werden. Diese Art der Persistierung von Daten ist in einem solchen verteilten System deutlich leistungsfähiger als der klassische Ansatz.

In der Regel wird beim Empfang von Nachrichten das Offset kontinuierlich erhöht, um...

Neugierig geworden?


    
Loading...

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