Dies ist der erste Beitrag einer neuen Tech up! Serie über Apache Kafka und dessen Ökosystem. Benjamin Bühlmann berichtet.
Event-driven-Architecture ist aktuell, mehr denn je, wieder in aller Munde. Auch wenn die Konzepte, Technologien und Tools dahinter nichts Neues sind, gewinnen sie vor allem im Zusammenhang mit Microservice-basierten Architekturen an Relevanz. Eventstreaming und Processing ist in der Gesamtarchitektur von Firmen wie Linkedin, Uber, Netflix und Twitter ein fixer und zentraler Bestandteil. In diesem Zusammenhang wird Apache Kafka als Technologie und Plattform oft erwähnt und kommt bei 30% der Fortune 500 Companies zum Einsatz.
Wir werden im Rahmen dieser Tech up! Serie interessante Aspekte aus dem breiten und aktuellen Themengebiet rund um Kafka in Form von kompakten Posts vorstellen. Die Serie hat einen technischen Fokus und setzt teilweise ein Basiswissen über Kafka voraus. Für weitere Informationen empfehlen wir das frei verfügbare O’Reilly E-Book „Kafka: The Definitive Guide“. [1]
Als Einstieg in diese Serie werden die wichtigsten Begriffe von Kafka vorgestellt.
Cluster & Brokers
Kafka wird typischerweise als hochverfügbarer Cluster, bestehend aus mehreren Broker, betrieben. Ein Broker nimmt dabei Messages von Clients entgegen, persistiert diese und liefert sie an die Consumer aus. Ein Client kommuniziert dabei mit mehreren Brokern parallel, um Skalierungseffekte auszunutzen.
Clients
Clients werden in Producer und Consumer unterteilt. Diese schreiben und lesen Messages von Topics aus einem Kafka Cluster. Kafka verwendet für die Client-Broker und die inter-Broker Kommunikation ein offenes, binäres Protokoll [2]. Dieses Protokoll wird von diversen Clients in verschiedenen Sprachen implementiert [3] [4]. Die vom Feature-Umfang her vollständige Libraries existieren für die Sprachen Java, Python, C/C++, Go und .NET [5]. Stream Processing wird auf der Clientseite implementiert und bleibt heute Java und Scala basierten Clients vorbehalten.
Message
Eine Message (auch Record genannt) ist ein Key-Value Pair, bestehend aus jeweils einem Byte-Array, wobei der Key optional ist. Die Serialisierung und Deserialisierung von Key und Payload geschieht auf der Clientseite. Die Kafka Broker sind agnostisch gegenüber den Message-Inhalten. Eine Message ist innerhalb eines Kafka Clusters über den zusammengesetzten Schlüssel „Topic + Partition + Offset“ eindeutig adressierbar.
Messages sind in Kafka immutable. Das bedeutet, eine Message wird an einem spezifischen Offset einmalig geschrieben und nie mehr verändert. Wenn ein Consumer die Message liest, wird diese auf dem Broker nicht gelöscht. Die Message wird durch asynchrone Jobs auf dem Broker gelöscht sobald die Retention Policy erreicht ist. Die Policy kann entweder grössen- oder zeitbasiert definiert werden. Als weitere Option kann Log Compaction verwendet werden. Dabei wird jeweils nur die neuste Message für einen bestimmten Key vorbehalten [6].
Topics, Partitionen, Replicas und Logs
In Kafka werden Messages in Topics gruppiert und persistent abgelegt. Topics werden oft nach Fachlichkeit oder nach nicht-funktionalen Anforderungen geschnitten. Nicht-funktionale Anforderungen können z.B Durchsatz (Msg/sec, MB/sec), Garantien zu Verfügbarkeiten des Topics oder Qualitäten der Message-Zustellung sein.
Die Clients schreiben und konsumieren Messages von Topics. Eine Message wird einmalig geschrieben und kann durch die Consumer beliebig oft gelesen werden (write once, read many). Ein Topic kann über mehrere Broker im selben Kafka Cluster verteilt werden. Damit diese Verteilung möglich ist, werden Topics in Partitionen unterteilt, wobei ein Topic aus 1..n Partitionen besteht. Die Partitionen werden während des Erstellungszeitpunkts eines Topics durch Kafka gleichmässig nach Round-Robin auf den Broker im Cluster verteilt. Bei der Verteilung der Replicas (Kopien von Partitionen) wird berücksichtigt, dass sämtliche Replicas auf verschiedene Brokern liegen und die Rack-Awareness, wo möglich, eingehalten wird.
Ein Ordering der Messages wird durch Kafka nur innerhalb einer Partition garantiert. Da die Anzahl Partitionen massgebend für das Client-Seitige Loadbalancing sind, ist dies ein wichtiger Aspekt der beim Design von Topics berücksichtigt werden muss.
Die einer Partition zugrundliegende Struktur ist ein Log [7]. Logs sind eine einfache und effiziente Form, Daten persistent abzulegen. Daten werden sequentiell angehängt (append only) und sind immutable. Dies erlaubt eine hohe Datenrate für Disk I/O.
Fortsetzung folgt
Dieser Blogpost dient als Einstieg in unsere neue Tech up! Serie, in welcher wir vertieft über ausgewählte Aspekte im Kafka Universum schreiben.
1. Kafka: The Definitive Guide: https://www.confluent.io/resources/kafka-the-definitive-guide
2. Kafka protocol guide: https://kafka.apache.org/protocol
3. Java Client APIs: https://kafka.apache.org/documentation/#api
4. Client Libraries: https://cwiki.apache.org/confluence/display/KAFKA/Clients
5. Feature Support of Kafka Client libs: https://docs.confluent.io/current/clients/index.html#feature-support
6. Log Compaction: https://kafka.apache.org/documentation/#compaction
7. Jay Kreps about Logs: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying