Höhepunkte des Kafka Summits in London 2024

Etwas nervös war ich schon auf dem Weg nach London. Schliesslich würde ich am Kafka Summit 2024 gleich nicht nur viele alte Bekannte und Freunde, sondern auch echte Data-Streaming-Koryphäen treffen, zum Beispiel bei der Keynote von Jay Kreps, Mitgründer von Confluent. Zu Beginn der Veranstaltung werden die diesjährigen Highlights der Apache Kafka Community hervorgehoben. Das ist es, was Kafka so einzigartig macht: Die Anwender:innen, die sich als eine Art grosse Familie verstehen. Kein Wunder wurde nebst dem aktuellen Apache Kafka 3.7.0 Release im Februar sowie der Roadmap für Kafka 4.0 das Knacken der 1000er-Marke von Kafka Improvement Proposals (KIP) gefeiert: Es ist der Beweis, dass die Community lebt und wächst.

Eine Keynote, die Welten vereint

Endlich ist es so weit: Data-Streaming-Mastermind Jay Kreps stellt gemeinsam mit seinem Team die Confluent Data Streaming Vision vor. Dazu greifen sie zunächst ein altbekanntes Problem auf: Data Products gibt es zwar schon länger, allerdings sind sie bisher hauptsächlich in der analytischen und nicht in der operativen Welt verbreitet – geschweige denn miteinander verknüpft. Das Resultat: Statt eines «Data Meshs» entsteht meistens ein «Data Mess». Confluents Vision ist deshalb eine Verschmelzung der operationalen und der analytischen Welt zu einem Universal Data Product, wobei Data Streams mit Apache Kafka als offener Standard die Basis dieser Weltenvereinigung bilden. Apache Flink fungiert dabei sowohl für Batch als auch für Echtzeit-Use-Cases als Standard-Processing-Engine. Und das ist auch für die technisch nicht so versierten Leser:innen – die ich hoffentlich noch nicht alle vergrault habe – relevant: Dieses Zusammenspiel ermöglicht es, Daten als sogenanntes Data Product in verschiedenen Applikationen zu verwenden, ohne dieses jeweils separat zu implementieren. Das spart Zeit und Geld, vorausgesetzt, der Datenaustausch funktioniert zuverlässig und schnell.

Hier hat sich das hoch performante Apache-Iceberg-Format etabliert. Iceberg ermöglicht das effiziente Austauschen von Daten zwischen der operationellen und analytischen Welt. Daten im Iceberg-Format lassen sich via Confluent Tableflow zusammen mit Metadaten aus der Schema Registry für weitergehende Analysen mit analytischen Engines nativ zur Verfügung stellen. Das neue Data Portal – eine Art «Google Maps für Daten» – beinhaltet nebst Stream Catalog und Stream Lineage auch ein Modul für Data Governance mit entsprechenden Regeln und Freigabeprozessen.

Manche Leser:innen dieses Textes fragen sich jetzt vermutlich, weshalb ich deswegen solch einen Wirbel veranstalte – es sind ja schliesslich einfach ein Haufen Tools zum Data Streaming. Machen wir einen Schritt zurück und betrachten wir das Gesamtbild: Diese Kombination aus Apache Kafka für Data Streaming, Apache Flink für Stream Processing und Apache Iceberg als Tabellenformat bietet zusammen mit dem Data Portal die technologische Grundlage für das «Universal Data Product», dem heiligen Gral des Data Streamings.

Der passiv-aggressive Geschirrspüler-Event

Noch etwas geflasht von der Keynote und den sich dadurch eröffnenden Möglichkeiten gings für mich weiter zu den Sessions. Zu meinem Bedauern fanden viele davon parallel statt, sodass ich nicht alle besuchen konnte – wäre bei über 100 Sessions aber wohl auch etwas anstrengend gewesen. So besuchte ich zunächst Tim van Baarsen von ING, der die firmeneigenen Best Practices rund um AVRO Schema Management vorstellte und aufzeigte, wie ING so Backward- und Forward-Kompatibilität gewährleistet. Danach gings weiter zu Cedric Schaller. Er stellte anhand eines an TWINT angelehnten Beispiels vor, an welchen Stellen innerhalb einer verteilten Architektur häufig Fehler auftreten – und wie diese adressiert werden können. Besonders interessant war hier das Pattern für das Aussteuern von «Poison Pill Events» in einer Dead-Letter-Queue inklusive Aussteuerung nachfolgender Events mit dem gleichen Business Key, um so die Reihenfolge der Verarbeitung dieser Events weiterhin zu gewährleisten.

Bei Oscar Dudycz konnte ich mir den ein oder anderen Lacher nicht verkneifen: In einem äusserst amüsanten Vortrag stellte er eine ganze Reihe von «Event Modelling Anti-Patterns» vor. Da gab es zum Beispiel den «Clickbait Event», also ein spannender Event, jedoch ohne wirklichen Inhalt. Oder den «Passive-Agressive Events», welchen Dudycz mit einem Alltagsbeispiel veranschaulicht: Bei der Aussage «Schatz, der Geschirrspüler hat gepiept und ist glaube ich fertig», handle es sich eigentlich um einen «Command Event» und bedeute entsprechend «Schatz, warum hast du immer noch nicht den Geschirrspüler ausgeräumt». Ich fragte mich, ob meine Frau das wohl auch so lustig fände wie ich und ich sie beim nächsten Auftreten solcher Events darauf hinweisen sollte. Gottseidank lenkte mich Tom Bentley von Red Hat von solchen Gedanken ab, indem er verschiedene Varianten vorstellte, um Kafka-Umgebungen auch vor internen Attacken zu schützen. Hier spielt «Encryption-at-Rest» eine wichtige Rolle. Das Open-Source-Projekt kroxylicious.io bietet dazu einen transparenten Proxy inklusive Vault-Unterstützung fürs Key-Management an.

Intelligente Chatbots

Der nächste Vortrag von HelloFresh war etwas für echte Draufgänger, die schon mal das Bedürfnis hatten, Topics in Produktion umzubenennen. Md Nahidul Kibria erläuterte, wie dies mit dem MirrorMaker 2 Connector gemacht werden kann, ohne dabei Offsets oder Bezug zu Consumer Groups zu verlieren. Hier der Link zur Anleitung, um künftige Kamikaze-Aktionen zu vermeiden – speichert ihn jetzt, dankt mir später.

Natürlich durften an dieser Konferenz auch Vorträge zum Thema Data Streaming und künstliche Intelligenz (KI) nicht fehlen. Gerade das Zusammenspiel der beiden Ansätze ist faszinierend, da die mit Data Streaming gewonnenen Daten die Grundlage für Machine Learning und GenAI Use Cases bilden. Airy hat dazu eine Plattform entwickelt, die im Dialog mit einem Chatbot nicht nur Retrieval-augmented Generation (RAG) per Large Language Model (LLM) unterstützt, um auf unstrukturierte Daten über Vector Datenbanken zuzugreifen. Sie kann die so gewonnenen unstrukturierten Daten auch mit strukturierten Daten aus verschiedenen Quellen kombinieren. Die dazu notwendigen Apache-Flink-SQL-Statements werden automatisch per LLM generiert, um Business-Fragen zu beantworten und die Ergebnisse übersichtlich in Chat-Form darzustellen. Auf diese Art wird der Chatbot zu einer Art KI – und weiss auf (fast) jede Frage eine Antwort.

Apache Flink: Star der Veranstaltung

Trotz all dieser spannenden Vorträge und der anwesenden Data-Streaming-Prominenz: Der eigentliche Star der Veranstaltung war dieses Jahr eindeutig Apache Flink. Entsprechend wurden der Stream Processing Engine zahlreiche dezidierte Workshops gewidmet. Diese deckten das gesamte Spektrum ab: Von Einsteiger-Sessions und Trainings über Best-Practices bis hin zu Deep-Dives war für alle etwas dabei. Ich entschied mich für die Session «Flink 2.0: Navigating the Future of Unified Stream and Batch Processing» von Martijn Visser, Senior Product Manager bei Confluent. Dort erfuhr ich spannende Insights zur weiteren Entwicklung und Roadmap von Flink 2.0. So soll künftig sowohl das Mixen von Batch und real-time in der gleichen Query möglich sein als auch Time Travel unterstützt werden. Weiter fungiere die neue Storage-Architektur mit S3 als Primary Storage und lokale Disks lediglich als Cache. Last but not least werde eine Vereinheitlichung der APIs angestrebt – alles Dinge, welche Flink noch skalierbarer und einfacher verwendbar machen werden.

Müde mache ich mich nach zwei spannenden Tagen auf den Heimweg. Trotz der aufkommenden Erschöpfung schwirren mir immer noch zahlreiche Eindrücke durch den Kopf. Für mich hat der diesjährige Kafka Summit eindrucksvoll aufgezeigt, wie das Kafka-Data-Streaming-Ökosystem stetig weiterwächst. Dass mit Apache Flink und Apache Iceberg die analytischen und operationellen Welten nun verschmelzen und so Universal Data Products ermöglichen, hat mich echt fasziniert. Während der Heimreise döse ich langsam ein und träume von vereinten Datenwelten, in denen Data Products als Basis des Data Mesh fungieren und so dem Data Mess ein für alle Mal den Gar aus machen. Als ich in Zürich ankomme, wache ich auf und stelle erfreut fest: Das war kein Traum – sondern schon bald die Realität.