
Apache Kafka ist eine der führenden Plattformen für Echtzeit-Daten-Pipelines und Streaming-Anwendungen. Bekannt für seine hohe Leistung, Skalierbarkeit und Zuverlässigkeit, wird Kafka häufig für kritische Aufgaben eingesetzt – von der Verfolgung von Website-Aktivitäten über die Verarbeitung von Bestellungen bis hin zur Analyse von Finanztransaktionen.
Immer mehr Branchen entdecken die Stärken von Kafka: Ob Einzelhandel, Gesundheitswesen oder Technologie – sie alle profitieren von den vielseitigen Einsatzmöglichkeiten der Plattform. Kafka bildet das Fundament moderner Daten-Infrastrukturen und fügt sich nahtlos in bestehende Systeme ein. Die Plattform unterstützt unterschiedliche Zustellgarantien, wie „at-least-once“ oder „exactly-once“, und lässt sich flexibel vor Ort oder in der Cloud betreiben – entweder selbstverwaltet oder als vollständig gemanagte Lösung.
Doch mit der wachsenden Verbreitung und neuen Anforderungen, etwa aus dem Bereich IoT, muss auch Kafka kontinuierlich weiterentwickelt werden. Eines der zentralen Themen bleibt dabei die Skalierbarkeit. Wie die Plattform mit neuen Releases genau diese Herausforderung meistert, zeigen wir im Folgenden.
Partitionen: Ein schneller Überblick
Apache Kafka ist eine vielseitige Plattform, die auf klar definierten Prinzipien sowie proprietären APIs und Protokollen basiert. Allerdings gibt es Bereiche, in denen die Anpassungsfähigkeit bisher begrenzt ist – insbesondere bei der Skalierung von Kafka-Consumern. Dennoch decken die standardmässigen Skalierungsmechanismen von Kafka rund 95 % aller Anwendungsfälle zuverlässig ab. Um die Funktionsweise besser zu verstehen, werfen wir einen Blick darauf, wie Kafka die Skalierung auf der Consumer-Seite umsetzt – ohne tief in die technische Architektur einzutauchen.
Das zentrale Element der Skalierbarkeit von Kafka ist die Partition. Jedes Topic wird in eine oder mehrere Partitionen unterteilt, wobei jede Nachricht einer spezifischen Partition zugewiesen wird – in der Regel basierend auf ihrem Schlüssel. Partitionen bilden die grundlegende Einheit der Skalierbarkeit in Kafka. Dieses Design bringt jedoch eine natürliche Obergrenze für die Verarbeitungskapazität mit sich. Gleichzeitig beeinflusst die Partitionsstruktur eines Topics direkt die Redundanz und die Leistung beim Konsumieren von Nachrichten.
Kurz gesagt: Die Anzahl der Instanzen in einer Consumer-Gruppe ist durch die Gesamtzahl der Partitionen eines Topics begrenzt. Das bedeutet, dass ein Topic mit zehn Partitionen auf maximal zehn Consumer-Instanzen skaliert werden kann.

Abbildung 1: In Abbildung 1 ist zu sehen, wie Nachrichten durch die Kafka-Producer an die Partitionen eines Topics verteilt werden. Dabei kommt meist ein Schlüsselpartitioner zum Einsatz, der die Nachrichten verteilt. Jede Partition wird dann einer Consumer-Instanz in der Consumer-Gruppe zugewiesen. Wichtig dabei: Innerhalb einer Partition kann jeweils nur eine Consumer-Instanz die Nachrichten konsumieren.
Partitionen dienen nicht nur als Skalierungseinheit, sondern auch als die einzigen logischen Container, die eine garantierte Nachrichtenreihenfolge gewährleisten. Die Architektur von Kafka, die auf Partitionen, Zuweisungsalgorithmen (Assignors) und Consumer-Gruppen basiert, bietet eine hohe Flexibilität bei der effizienten Lastverteilung. Diese enge Verknüpfung von Nachrichtenablage, Reihenfolge und Skalierung sorgt für eine zuverlässige Performance. Gleichzeitig kann sie in bestimmten Szenarien, wie bei stark schwankenden Datenströmen oder besonders grossen Anwendungen, zu begrenzten Anpassungsmöglichkeiten führen.
Einführung der Parallel Consumers von Confluent
Genau diese Skalierungsgrenze führte zur Entwicklung der Parallel Consumer Bibliothek von Confluent. Diese Bibliothek fügt eine zusätzliche Abstraktionsschicht hinzu, die die Standard-Kafka-Consumer-API umschliesst. Dadurch wird eine weitergehende Skalierung der Consumer-Instanzen innerhalb einer Consumer-Gruppe ermöglicht – und zwar mithilfe des sogenannten nicht-blockierenden, parallelen Architekturmodells Vert.x.

Abbildung 2: Die Skalierbarkeit von Kafka-Consumern mit Parallel Consumer von Confluent - Jede Instanz in der Consumer-Gruppe wird in mehrere parallele Verarbeitungsinstanzen skaliert (grüne Komponenten). Diese können Nachrichten gleichzeitig verarbeiten.
Der Parallel Consumer von Confluent überschreitet die Skalierungsgrenzen von Kafka, ohne das zugrunde liegende Protokoll oder die API zu verändern.Um diese Erweiterung zu nutzen, genügt es, die Standard-Kafka-Consumer-API mithilfe der Confluent-Bibliothek zu ergänzen. Mit den richtigen Einstellungen lässt sich der Consumer in eine leistungsstarke Lösung für massiv parallele Datenverarbeitung verwandeln.
Die genauen technischen Details sprengen den Rahmen dieses Artikels, doch es lohnt sich, einen Blick auf diese smarte Technologie zu werfen. Sie schafft eine ausgewogene Balance zwischen garantierter Nachrichtenreihenfolge, verbesserter Skalierbarkeit und flexiblen Zustellgarantien.
Spannende Neuerungen stehen bevor
Mit der kommenden Apache Kafka Version 4.0 wird eine weitere Möglichkeit zur Skalierung von Consumern eingeführt. Im Rahmen von KIP-932 wird das Konzept der „dauerhaften geteilten Partition“ (durable shared partition) im Bereich der Stream-Verarbeitung implementiert. Dieses neue Werkzeug stellt eine bedeutende Weiterentwicklung dar und eröffnet vielversprechende neue Einsatzmöglichkeiten.
Man könnte diese neue Funktion als „Warteschlangen für Kafka“ betrachten. Es könnte so wirken, als würden neue Entitäten zu den traditionellen Kafka-Topics hinzugefügt, aber das ist nicht der Fall. Die Struktur der Kafka-Broker bleibt unverändert, und die zusätzliche Komplexität wird auf die Clients verlagert. KIP-932 erweitert die Funktionalität der Consumer-Gruppen und führt die sogenannten Consumer Shared Groups neben den bestehenden Consumer Groups ein.
Wie der Confluent Parallel Consumer basiert auch dieses Upgrade auf fortschrittlicher Technologie. Allerdings waren in diesem Fall Änderungen am Kafka-Protokoll und der API erforderlich. Auch wenn auf den Brokern weiterhin nur Topics existieren, erfordert diese neue Funktionalität ein Upgrade sowohl auf der Broker- als auch auf der Client-Seite.

Abbildung 3: Mit dem neuen Consumer Shared Group-Protokoll ist die Anzahl der Instanzen in der Consumer-Gruppe vollständig von der Anzahl der Partitionen in einem Topic entkoppelt. Alle Consumer-Instanzen verarbeiten parallel einen gemeinsamen Nachrichtenstrom, als käme dieser aus einer einzigen Partition.
Erweiterung grundlegender Konzepte für verbesserte Skalierbarkeit
Trotz der klaren Architekturvorgaben von Kafka ist die Plattform in ihrer Skalierbarkeit bemerkenswert flexibel. Der ursprüngliche Ansatz zur Skalierung stiess in bestimmten Szenarien, wie etwa bei IoT-Verarbeitungsplattformen, an seine Grenzen. Doch Lösungen wie die Parallel Consumers von Confluent haben bereits gezeigt, wie diese Herausforderungen gemeistert werden können. Mit der kommenden Version Apache Kafka 4.0.0 wird zudem ein neuer Ansatz eingeführt, der diese speziellen Anwendungsfälle noch besser unterstützt.
Kafka entwickelt sich kontinuierlich weiter und wird immer leistungsfähiger. Diese Weiterentwicklung zeigt deutlich das Engagement von Kafka, den sich ständig verändernden Anforderungen moderner Streaming-Anwendungen gerecht zu werden. Durch die kontinuierliche Optimierung der Skalierungsmechanismen stellt die Plattform sicher, dass sie mit dem wachsenden Volumen und der steigenden Geschwindigkeit von Daten in der heutigen, datengesteuerten Welt Schritt halten kann. Mit den bevorstehenden Neuerungen in Apache Kafka 4.0.0 ist die Plattform bestens gerüstet, um künftige Skalierungsherausforderungen zu meistern und ihre Position als führende Lösung für Echtzeit-Daten-Streaming zu behaupten.
Pawel Wasowicz
Pawel lebt in Bern und ist Lead Data Engineering in Digital Foundation. Er hilft unseren Kunden, durch optimale Nutzung der neuesten Trends, bewährter Technologien und seiner jahrelangen Erfahrung auf diesem Gebiet das meiste aus Ihren Daten zu machen.