Das generelle Konzept, mit dem Kafka seine Datenströme verarbeitet, haben wir im ersten Teil dieser Beitragsserie betrachtet. Dabei ging es um die Unterschiede zwischen klassischem Queuing, PubSub und dem Kafka-Ansatz. Um die Frage zu beantworten, für welche Anwendungsfälle Kafka besonders gut geeignet ist und für welche eher weniger, befassen wir uns in diesem Teil mit einer generischen Lösungsarchitektur und der technischen Übertragung von Nachrichten.

Datenübertragung – Serialisierung und Deserialisierung
Eine der wichtigsten technischen Eigenschaften von Kafka-Lösungen ist, Datenströme zur Übertragung zu serialisieren. Das heißt, (strukturierte) Daten werden in einen sequenziellen Datenstrom überführt, der dann mittels eines Netzwerkes übertragen und durch Kafka persistiert wird. Die Aufgabe der Serialisierung übernimmt der so genannte Producer, also derjenige, der eine Nachricht in das Kafka-System einstellt. Kafka selbst bietet an dieser Stelle keinerlei Logik und kann als unfachliche Übertragungsschicht oder gar als Übertragungsframework bezeichnet werden. Software, die eine Serialisierung übernehmen kann, gibt es für die unterschiedlichsten Quellsysteme frei verfügbar oder gegen Lizenzgebühren bei diversen Anbietern. Aber Achtung: Hier handelt es sich nicht mehr um den eigentlichen Kafka-Kern, sondern um Software, die mehr oder weniger gut mit Kafka integriert ist – je nachdem was genau man verwendet. Bei Datenübertragungen ist das Avro-Format am häufigsten anzutreffen, aber auch Protobuf erfreut sich immer größerer Beliebtheit.

Wichtig ist, dass ein entsprechender Datenstrom innerhalb von Kafka nicht einfach auf der Empfängerseite konsumiert werden kann, sondern zuvor durch eine Deserialisierung wieder in ein technisch/fachlich sinnvoll nutzbares Objekt überführt werden muss. Dieses Zusammensetzen auf der Empfängerseite (bei Kafka die Seite des Konsumenten) erfolgt logischerweise auch durch den Konsumenten oder einer entsprechend vorgelagerte Instanz, die eine geeignete Software verwendet.

Stellen wir uns als Beispiel eine im .XML-Format strukturierte Datei vor. Soll solch eine Datei mit Kafka verarbeitet werden, wird das .XML zum Transport durch Kafka in einen schemalosen sequenziellen Datenstrom konvertiert (Serialisierung), der dann auf Empfängerseite wieder in ein lesbares Format übersetzt werden muss (Deserialisierung). Bei genauerer Betrachtung werden an dieser Stelle die ersten Stärken und Schwächen von Kafka sichtbar.

Sofern der Konsument den Datenstrom korrekt interpretieren kann, ist es ihm nicht nur möglich ein Abbild des Originals wiederherzustellen (also ein .XML), sondern er könnte nach Belieben den Datenstrom beispielsweise als JSON-Format weiterverarbeiten oder aber die Inhalte auch direkt via JDBC in eine Datenbank überführen. Der Konsument kann frei entscheiden, welches deserialisierte Format aus dem serialisierten Datenstrom des Datenproduzenten weiterverarbeitet werden soll. Insofern ist es möglich, dass ein einheitlicher Datenstrom von diversen Konsumenten, je nach Belieben in multiplen Verfahren weiterverarbeitet wird. Kafka bietet dadurch die Möglichkeit, von bestimmten Inputformaten zu abstrahieren – also gewissermaßen ein generischer API-Service von einer Datenquelle zu multiplen Datenabnehmern.

Eine Herausforderung gibt es an dieser Stelle aber doch: Da der Datenstrom bei der Übertragung schemalos ist, muss dieser beim Konsumenten zunächst in ein verwertbares, strukturiertes Format gebracht werden. Genau bei dieser Deserialisierung lauern aber Risiken, die nicht aus den Augen gelassen werden sollten. Entscheidend ist, auf welcher Basis ein Konsument in der Lage versetzt werden kann, korrekt zu deserialisieren. Um das zu können, benötigt er eine Beschreibung der Daten. Das klingt zwar logisch und banal, jedoch gibt es mindestens zwei Faktoren, die dabei dringend beachtet werden müssen.

Als erstes empfiehlt sich der Einsatz einer zentralen Schema-Registry, in der alle von Datenproduzenten verarbeiteten Schemas verfügbar sind. Denn ohne die Strukturvorgaben des originären Inputformates kann keine sinnvolle Deserialisierung auf der Konsumentenseite erfolgen. Wird auf diese Komponente verzichtet, wird immer eine zusätzliche und direkte Kommunikation zwischen Datenempfänger und Datenproduzenten erforderlich sein, um sicherzustellen, dass die verarbeiteten Daten auch auf der Empfängerseite richtig interpretiert werden können. Und Achtung: Eine zentrale Schemaverwaltung ist kein Bestandteil des Kerns der Kafka-Software. Will man eine nutzen, muss die Kafka-Infrastruktur entweder durch entsprechende Plugins erweitert werden oder die erforderlichen Komponenten sind Teil eines Lizenzpaketes einer erworbenen Enterprise-Distribution.

Mittels einer zentralen Schemaregistrierung können sich potenzielle Datennutzer immer über die zugrunde liegende Datenstruktur informieren und werden so in die Lage versetzt, einen beliebigen und schemalosen Datenstrom richtig zu interpretieren, ohne dabei mit dem Versender der Daten außerhalb vom Kafka-Kosmos sprechen zu müssen, um sich die Daten erläutern zu lassen. Es handelt sich somit um eine zentrale Stelle, an der ein Schnittstellenvertrag verwaltet wird.

So offensichtlich wie der erste Punkt ist der zweite leider nicht und wird deshalb auch häufig übersehen. Es ist nämlich zu beachten, dass Daten-Inputfelder bei der Serialisierung und Deserialisierung „hin und her übersetzt“ werden. Nehmen wir an, dass bei unserem Beispiel das gängige Avro-Format genutzt wird. Avro zeichnet sich vor allem dadurch aus, dass nicht alle Datentypen und Felder einer Strukturdefinition uneingeschränkt unterstützt werden. Es ist sogar so, dass ganz sicher nur die so genannten „Primitive Types“ und einige wenige „Complex Types“ unterstützt sind. Es gibt zwar die Möglichkeit so genannte „Logical Types“ zu verwenden, jedoch muss man wissen, dass diese unter der Haube alle in ein „Primitive Type“ umgewandelt werden. Insbesondere bei Datumsfeldern mit einem Zeitstempel oder auch Dezimalzahlen, kann es dabei zu Verarbeitungsungenauigkeiten in der Serialisierung oder der Deserialisierung kommen. Vor allem auch deshalb, weil die entsprechende (De-) Serialisierungssoftware eben genau nicht aufeinander abgestimmt ist (siehe erste Abbildung). Von daher schlummert an dieser Stelle ein typisches Fehler-Risiko, das nur durch intensive Tests eliminiert werden kann.

Typische Einsatzszenarien von Kafka
Durch sein technisches Übertragungskonzept eignet sich Kafka vor allem für den Transport kleiner strukturierter Datensätze. Durch die verteile Architektur (wird in einem späteren Beitrag noch im Detail behandelt) ist es besser, viele kleine, als wenige und eher große Nachrichten zu übertragen. Als Faustregel gilt: Wenn eine einzelne Message größer als 1 MB ist, sollte das Lösungsdesign überdacht werden. Wir würden sogar davon abraten, Nachrichten zu verarbeiten, deren Größe im Mittel mehr als 100 KB ist. Ideal sind max. 20 KB.

Kafka eignet sich also nicht, um beispielsweise große Dateien – Bilder oder Videos – zu verarbeiten. Durch die Serialisierung und Deserialisierung ist auch der Einsatz in stark reguliertem Compliance-Kontext mit Vorsicht zu betrachten. Erst recht, wenn es um Beweiswerterhaltung und Unveränderbarkeit von Daten geht. Wir werden diesbezüglich noch in einer weiteren Folge über Fehlerbehandlungen und Transportzusicherungen/Vollständigkeit sprechen.

Obwohl Kafka als Neartime-Messaging-Plattform beworben wird, kümmert sich Kafka eben genau nicht um die eigentliche Verwaltung der belieferten APIs. Kafka persistiert zwar in gewissem Maße übertragene Daten, ist aber ansonsten vollkommen unfachlich. Kommen Sie also besser nicht auf die Idee, Kafka als fachliche Datenbank zu „missbrauchen“, nur weil Nachrichten persistiert werden können. Dieser Aspekt sollte dringend bei jeder Planung berücksichtigt werden.

Hinweis: Einen Onlinekonverter für die Umwandlung von XSD/XML in ein Avro-Schema, können sie auf unserer Homepage ausprobieren: https://deepshore.de/avro-converter