Das Thema KAFKA wird mit diesem Blog-Eintrag erneut aufgenommen, um einen etwas tieferen technischen Einblick zu vermitteln.

Apache Kafka hat sich mittlerweile zu einer der wichtigsten Plattformen für hochskalierbare Systeme sowie zur Verarbeitung großer Datenmengen entwickelt und ist sehr verbreitet in modernen IT-Systemen. Der Trend zur Nutzung von Kafka in Zusammenhang von Analytics und Data Hub Projekten steigt an.

Kafka ist eine Streaming Plattform und versendet Nachrichtenströme als einfache Abfolge von beliebigen Zeichen (Bytes). Dies können „quasi“-strukturierte oder vollkommen unstrukturierte Daten oder auch Bilder sein.

Kafka interessieren die Dateninhalte nicht. Sie werden ohne Prüfung eins-zu-eins übernommen. Die Überprüfung der Daten ist einzig und allein dem Consumer vorbehalten.

Der Kafka-Anwender kennt das Problem, wenn sich die Ursprungsdaten verändert haben und z.B. Felder hinzugefügt bzw. gelöscht wurden oder sich die Eigenschaften eines Feldes geändert haben. Ist die Kommunikation zwischen „Producer“ und „Consumer“ nicht hundertprozentig abgestimmt, treten Fehler beim Consumer auf, welche in einer produktiven Umgebung sehr schnell kritisch werden können.

Um den Daten ein gewisses Mindestmaß an Struktur zu geben, werden sie üblicherweise in einem der folgenden Formaten vom Producer erzeugt:

CSV - XML - JSON - AVRO

CSV

Comma Separated Values ist das wohl älteste Format für den Austausch von Daten. Der Begriff CSV ist seit ca. 1983 in Gebrauch, das Format allerdings schon seit Anfang der 70er Jahre. Eine CSV Datei ist eine Text-Datei, in der Werte durch ein Komma getrennt werden. Das CSV Format ist nicht standarisiert. Für die Übermittlung einfacher Daten wie Zahlen, Character Strings, etc. ist sie geeignet. Probleme können jedoch auftreten, wenn Zeichenketten Kommata, Apostrophe oder andere Sonderzeichen enthalten. Diese Werte können dann in Anführungszeichen gesetzt werden bzw., wenn der Wert ebenfalls Anführungszeichen enthält, werden ESCAPE Zeichen oder Escape Sequenzen zur Abgrenzung genutzt.

Für ein Streaming nach Kafka ist CSV geeignet, aber nicht die erste Wahl, da aus den oben genannten Gründen ein Parsing der Daten sehr komplex sein kann.

XML

Theoretisch auch eine Möglichkeit der Datenübergabe, aber nicht empfehlenswert, da das Parsing der XML-Daten sehr CPU aufwendig ist und nicht mehr dem heutigen Standard entspricht.

JSON

Das wohl beliebteste Protokoll für Kafka. JSON ist allgegenwärtig in fast jeder Programmiersprache und nahezu alle modernen Anwendungen nutzen es.

JSON basiert auf Schlüssel/Wert Paaren ohne externe Strukturinformationen. Dies ermöglicht es, problemlos neue Informationen abzulegen oder auch unter demselben Namen verschiedene Datentypen abzulegen.

Es bedeutet allerdings auch, dass die Anwendung, die die Daten weiter verarbeitet, beim Auslesen der Werte darauf achten muss, dass die gewünschten Felder existieren und die Daten im notwendigen Format vorliegen.

In manchen Fällen werden die Strukturinformationen in JSON mitgegeben. Dies bedeutet allerdings, dass aus einem Schlüssel/Wert Paar ein Dokument wird.

Zum Beispiel aus „Nummer“:1 wird {„Name“:“Nummer“, „Wert“:1, „Typ“:“Integer“, „Schlüsselposition“:0}

AVRO

Die anfangs angeführten Probleme, dass die Daten in JSON irgendwie aussehen können und es die Aufgabe des Consumers ist, die Daten zu überprüfen, kann zu Problemen führen, wenn an der Anwendung, die die Daten erzeugt, Änderungen vorgenommen werden ohne, dass es der Zielanwendung mitgeteilt wird.

Dies wird von AVRO zur Grundlage genommen. AVRO hat sehr an Popularität in der Big Data Community zugenommen.

Schemata in AVRO werden mittels JSON definiert. Vielfältige Datentypen sind unterstützt, jedes Feld kann dokumentiert werden, ein AVRO Objekt besteht IMMER aus einem Schema und den Daten.

Diese Schemata werden an einem zentralen Ort abgelegt und jedes Schema hat eine Kennnummer. Wenn sich die Version eines Schemas ändert, z.B. durch das Hinzufügen mehrerer Felder, ändert sich auch die Kennnummer.

Wenn eine AVRO Nachricht nach Kafka geschickt wird, ist die Kennnummer des verwendeten Schemas vorne in der Nachricht zu finden. Dadurch liegen jeder Nachricht alle Strukturinformationen bei.

tcVISION kommuniziert im Falle von AVRO mit der Schema Registry von unserem Partner Confluent bzw. der Schema Registry von Hortonworks.

Der Nachteil – wenn man von einem Nachteil sprechen kann – ist, dass der Entwicklungszyklus mit AVRO länger ist als mit JSON. Auf der anderen Seite hat man keine Probleme mit Datenformaten. AVRO wird binär gespeichert.

Unabhängig vom verwendeten Protokoll sehen die Ausgabetabellen für Kafka im tcVISION Repository aus wie jede andere Ausgabetabellen (z.B. Oracle, SQL-Server, etc).

Aber auch hier gilt der Grundsatz:

Änderungen an der Datenquelle sollten dem Datenziel auch zeitnah mitgegeben werden.

Sollte dies nicht passieren, fällt dies bei CSV, JSON oder XML erst auf, wenn dauerhaft Werte in der Ausgabe fehlen bzw. neue Werte ungenutzt bleiben.

Im Falle von AVRO ist die Strukturinformation notwendig, um die Nachricht lesen zu können. Wenn hier ein Feld nicht mehr auftaucht oder hinzugefügt wurde ohne das entsprechende Schema anzupassen, gibt es einen Fehler beim Parsen der Nachricht. Somit führen Änderungen direkt zu Fehlern und nicht nur ggf. zu fehlerhaften Ergebnissen.

Unsere tcVISION Lösung unterstützt die Kafka Protokolle CSV, JSON und AVRO. Für AVRO werden die Schema Registries von Confluent und Hortonworks unterstützt.