Was wäre, wenn wir Kafka von Grund auf neu bauen könnten?

• Durch KIP-1150 (Kafka ohne Festplatte) und das Kafka-Fork-Projekt von AutoMQ wird intensiv über ein für die Cloud optimiertes Kafka diskutiert
• Würde man Kafka neu bauen, könnte man die bestehende Partitionsstruktur abschaffen und einen schlüsselzentrierten Ansatz vorschlagen
• Es besteht Bedarf an Funktionen für Nebenläufigkeitskontrolle und brokerseitige Schema-Unterstützung
• Zudem wird betont, dass moderne Systemeigenschaften wie Skalierbarkeit, Snapshots und Multi-Tenancy integriert werden sollten
• Ausgehend von Kafka entsteht die Vorstellung eines wirklich Cloud-native Event-Log-Systems, das über die Grenzen des bisherigen Kafka hinausgeht

---

Wenn man Kafka neu bauen würde

• Kürzlich wurden KIP-1150 (Kafka ohne Festplatte) und der Kafka-Fork von AutoMQ vorgestellt. Ziel ist es, Kafka mit Objektspeichern wie S3 zu integrieren, um in Cloud-Umgebungen die Elastizität zu verbessern und Kosten zu senken
• Der Text entwirft ein Cloud-native Event-Log-System, das über die Grenzen des bestehenden Kafka hinausgeht, und schlägt verschiedene Verbesserungen vor

Vorschlag für eine partitionlose Struktur

• Da Cloud-Objektspeicher wie praktisch unbegrenzter Speicher wirken, sinkt die Notwendigkeit von Topic-Partitionen
• Häufig ist entweder die globale Nachrichtenreihenfolge oder nur die Reihenfolge von Nachrichten mit demselben Schlüssel wichtig
• Das Partitionskonzept könnte vor Nutzer:innen verborgen werden, was die Nutzung vereinfacht

Schlüsselzentrierter Ansatz

• Statt Partitionen zu scannen, wird ein Design vorgeschlagen, das schnellen Zugriff auf alle Nachrichten eines bestimmten Schlüssels und deren Replay ermöglicht
• Es könnte Streams auf Ebene von Millionen von Entitäten unterstützen und so die Zahl der Consumer je nach Bedarf flexibel anpassen
• Da Fehler auf Schlüssel-Ebene isoliert werden, steigt die Verarbeitungseffizienz des Gesamtsystems
• Die Struktur ist ideal für Event Sourcing oder Actor-Model-Systeme

Unterstützung für Topic-Hierarchien

• Ähnlich wie in Systemen wie Solace sollte ein Teil der Message-Payload zu einer strukturierten, pfadartigen Topic-Kennung erhoben werden, um patternbasierte Subscriptions zu ermöglichen
• Der Broker könnte dadurch Subscription-Filter effizient unterstützen, ohne die komplette Nachricht parsen zu müssen

Funktionen zur Nebenläufigkeitskontrolle

• Das heutige Kafka bietet keine Möglichkeit, Konflikte bei gleichzeitigen Schreibvorgängen zu verhindern
• Wenn optimistisches Locking pro Schlüssel unterstützt würde, ließe sich prüfen, ob eine Nachricht nach Sicht auf den neuesten Zustand geschrieben wurde
• So ließe sich das Problem verlorener Updates verhindern

Brokerseitige Schema-Unterstützung

• Kafka behandelt Nachrichten derzeit nur als einfache Byte-Arrays und ist daher auf externe Schema-Registries angewiesen
• Um Schema-Konsistenz sicherzustellen, wird vorgeschlagen, Schema-Informationen wie AsyncAPI-Metadaten standardmäßig auf Broker-Ebene zu unterstützen
• Dadurch ließe sich auch leichter an Open-Table-Formate wie Apache Iceberg anbinden

Skalierbarkeit und Plugin-Struktur

• Vorgeschlagen wird eine Struktur mit Erweiterbarkeit und Plugin-Fähigkeit wie bei Postgres oder Kubernetes
• Brokerseitige Filter oder Transformationen sollten sich leicht umsetzen lassen, ohne protocol-aware Proxys (wie Kroxylicious) zu benötigen
• Funktionen wie Rate Limiting, Topic-Verschlüsselung oder Backend-Unterstützung auf Basis von Iceberg-Tabellen sollten als Plugins implementierbar sein

Synchrone Commit-Callbacks

• Das aktuelle Kafka garantiert nur eventuelle Konsistenz
• Vorgeschlagen wird eine Struktur, in der Producer nach dem Senden einer Nachricht sofort prüfen können, ob die daraus abgeleiteten Daten aktualisiert wurden
• Mit Unterstützung für Read-your-own-writes-Garantien könnte Kafka als echtes Datenbank-Log genutzt werden

Snapshot-Funktion

• Die aktuelle Kompaktierung (compaction) in Kafka behält nur die letzte Nachricht, was nur dann sinnvoll ist, wenn diese den vollständigen Zustand enthält
• Werden nur Änderungen protokolliert, müssen sonst alle Events pro Schlüssel erneut abgespielt werden, was mehr Zeit kostet
• Daher wird eine logische Kompaktierung benötigt, die Events pro Schlüssel in Snapshots zusammenfasst

Native Unterstützung für Multi-Tenancy

• Jedes moderne Datensystem sollte Multi-Tenancy von Grund auf mitdenken
• Neue Tenant-Umgebungen sollten günstig und sofort erzeugbar sein, während Ressourcen, Sicherheit und Zugriffskontrolle strikt getrennt bleiben müssen

Weitere Hinweise

• Einige Funktionen werden bereits von Systemen wie S2 (Streams mit hoher Kardinalität), Waltz (optimistisches Locking) und Apache Pulsar (Multi-Tenancy) unterstützt
• Ein Open-Source-System, das alle vorgeschlagenen Funktionen gleichzeitig unterstützt, gibt es jedoch nicht
• Der Text gibt die persönliche Ansicht eines bei Confluent beschäftigten Autors wieder und ist keine offizielle Position
• Theoretisch wird erwähnt, dass eine LSM-Tree-basierte Architektur eine naheliegende Wahl wäre

[kaydash]

Wir nennen das bereits Redis.

[GN⁺]

Hacker-News-Kommentare

• Stimme zu. Für bestimmte Anwendungsfälle lohnt es sich, das Head-of-Line-Problem zu lösen

  • Allerdings verursachen heute alle Streaming-Systeme (oder Workarounds) O(n^2)-Kosten für Acknowledgements pro Message Key
  • Systeme wie Pulsar werden für diese Funktion häufig verwendet
  • Diese Komplexität zeigt sich vielleicht nicht jeden Tag, aber wenn sie auftritt, muss man darauf warten
  • Nach langer Untersuchung dieses Problems mit Kollegen kamen wir zu dem Schluss, dass grundlegende Architekturänderungen nötig sind, um skalierbare Acknowledgements pro Message Key zu unterstützen
  • Die Architektur benötigt einen sortierten Index, was bedeutet, dass n Nachrichten in O(n log n) verarbeitet werden
  • Ich wollte zu diesem Thema einen Blogpost schreiben, hatte aber keine Zeit
  • Wenn man sich auf Acknowledgements pro Message Key verlassen will, sollte man mit sporadischen Ausfällen oder Verzögerungen rechnen

• NATS.io ist einfacher zu nutzen als Kafka und hat mehrere Punkte bereits gelöst, etwa die Abschaffung von Partitionen, die Unterstützung keybasierter Streams und eine flexible Themenhierarchie

• Meine Reise mit Kafka war größtenteils ähnlich

  • Zuerst denkt man: "Oh, ein skalierbares Append-only-Log, großartig und einfach"
  • Aber wenn man es benutzt, merkt man, dass es sehr komplex ist

• Für bestimmte Anwendungsfälle wäre es nützlich, garantieren zu können, dass abgeleitete Datenansichten aktualisiert wurden, wenn ein Create-Request bestätigt wird

  • Dann sollte man Kafka nicht verwenden, sondern direkt in den zugrunde liegenden Datenspeicher schreiben
  • Dann weiß man, dass die Daten committet wurden, und hat eine Datenbank, die man abfragen kann

• Ich habe diese Frage vor 6 Jahren gestellt

  • Wie wäre es, wenn man es in Rust schreibt und WASM nutzt
  • Ich arbeite seit den letzten 6 Jahren daran
  • In den letzten 2 Jahren habe ich mit Rust und WASM Flink gebaut

• Kafka auf Object Storage? Das würde Latenz und Kosten um das Zehnfache erhöhen

  • Kafka ist ein Opfer seines Erfolgs
  • Das Design ist einfach und elegant, weshalb es für viele Zwecke verwendet wird, für die es ursprünglich nicht gedacht war
  • Natürlich ist es für diese Anwendungsfälle nicht perfekt

• Zu "Abschaffung von Partitionen" und "Streams auf Schlüssel-Ebene"

  • Wenn das Storage-Backend auf physischer Partitionierung beruht, ist das letztlich nur ein Umbenennen von Partitionen in Keys und von Keys in Events

• Man sollte Northguard im Auge behalten

  • Das ist der Name von LinkedIns Kafka-Neuschreibung, die vor etwa einer Woche bei einem Stream-Processing-Meetup vorgestellt wurde

• Ich frage mich, wie viele der Probleme von Apache Kafka sich durch einen Wechsel zu Apache Pulsar lösen lassen

  • Ich habe das Kafka-Lernen übersprungen und direkt Pulsar verwendet
  • Es passt gut zu unserem Anwendungsfall
  • Keine Beschwerden
  • Ich frage mich allerdings, warum es so wenige Leute nutzen

• Ein nützliches Gedankenexperiment

  • Auffällig ist, wie still die Antworten sind, die nahelegen, Kafka durch etwas Neues zu ersetzen
  • Kafkas größte Stärke ist das breite und nützliche Ökosystem, das darauf aufgebaut wurde
  • Das ist zugleich auch seine Schwäche
  • Man muss einige Designentscheidungen beibehalten, die man heute nicht mehr so treffen würde, wenn man ganz von vorn anfangen würde
  • Oder man gibt die Abwärtskompatibilität auf und muss das bereits vorhandene Ökosystem neu aufbauen