Die Kappa-Architektur und NoETL

Intro

Mit der Lambda-Architektur wurde ein neuer skalierbarer Umgang mit großen Datenmengen entwickelt. Diese Architektur wurde in vielen Unternehmen umgesetzt, oft zusammen mit der Einführung eines Data Lakes.

Während ein solches Vorhaben fortschreitet, kristallisieren sich einige Schwierigkeiten heraus. Die Daten werden oft im ursprünglichen unstrukturierten Format in den Datensee regelrecht gekippt. Komplexe ETL- oder ELT-Prozesse werden nötig, um die Daten zu bereinigen1. In der Lambda-Architektur müssen alle Prozesse zwei mal implementiert werden, einmal für Batch und ein mal Realtime. Batch- und Realtime-Systeme haben unterschiedliche APIs und technische Anforderungen, so dass der Code früher oder später auseinander läuft und noch mehr Wartungsaufwand entsteht. Zu guter Letzt müssen auch schlicht zwei verschiedene Systeme betrieben werden, beide mit völlig unterschiedlichen Anforderungen an Hardware und Monitoring.

Jay Kreps, Mitentwickler von Apache Kafka, beschreibt das Problem der doppelten Komplexität in seinem Artikel Questioning the Lambda Architecture. Der Artikel stammt von 2014 und hier empfiehlt noch, je nach Anforderung an Latenz entweder ein Batch- oder ein Realtime-System zu verwenden.

Sein grundsätzlicher und in die Zukunft gerichteter Lösungsvorschlag ist jedoch die Kappa-Architektur.

Nach Lambda kommt Kappa

Eine der Innovationen der Lambda-Architektur ist die Bereitstellung der Ergebnisse mit niedriger Latenz, indem man große Datenmengen im Batchlayer vorverarbeitet, das fehlende Delta im Speedlayer in Nahechtzeit nachholt, und das Ganze im Serving Layer dann kombiniert. Doch wenn niedrige Latenz das Kriterium ist, warum nicht ausschließlich ein Realtime-System nutzen und alle Ergebnisse sofort verarbeiten?

Hier galt bisher als Gegenargument, dass Realtime-Daten nicht noch mal verarbeitet werden können. In der Lambda-Architektur werden Rohdaten dauerhaft vorgehalten, und falls ein Algorithmus einen Fehler enthält, können die Rohdaten im Batch-Layer neu verarbeitet werden, um falsche Berechnungen zu korrigieren. Doch auch einige Streaming-Systeme ermöglichen es, Daten zu persistieren und erneut durchzuspielen (sogenanntes replay).

In der Kappa-Architektur landen sämtliche Daten in einem zentralen Streaming-System (z.B. Apache Kafka, was auch schon im Speed-Layer der Lambda-Architektur genutzt wird) und werden dann mit einem Stream Processing Framework wie Spark Streaming, Flink, o.ä. verarbeitet. Die Streaming-Jobs schreiben die von ihnen produzierten Daten entweder zurück in das Streaming-System, oder wenn sie beispielweise auf einem Dashboard angezeigt werden sollen, in eine Datenbank.

Um bei einem Programmierfehler die Daten erneut zu verarbeiten, wird der korrigierte Streaming-Job parallel zum alten Job gestartet. Er lädt die gleichen Daten aus dem Streaming-System nochmal von Anfang an. Er schreibt die korrekten Werte in eine neue Tabelle, und sobald er zum aktuellen Stand aufgeholt hat, wird der alte Job gestoppt, und das Dashboard lädt seine Daten aus der neuen Tabelle. Kurzzeitig wird der Schreibbedarf in die Datenbank dadurch höher, aber insgesamt herrscht eine ausgeglichenere Last auf den Systemen, da die Batchverarbeitungen entfallen.

Ein persistentes Streaming-System hält die Daten üblicherweise nicht ewig vorrätig. Hier wählt man einen Zeitraum, der pro Use Case akzeptabel ist. Für die Langzeitdatenhaltung können die Daten weiterhin aus dem Streaming-System nach z.B. HDFS oder S3 geschrieben werden.

Kappa-Architektur

Stream Data Plattform

Ausgehend von der Kappa-Architektur wollen wir uns nun anschauen, wie so ein zentrales Streaming-System, oder eine Stream Data Platform2, aussehen und einen Datensee ersetzen könnte. Wir brauchen also eine Plattform, die alle Daten sammelt und als Ströme zur Verfügung stellt.

Jeder Datenstrom wird dabei zum Zeitpunkt des Auftretens und als Event modelliert erfasst. Das gilt auch für alle Datenbanken des Unternehmens, auch sie werden als Stream zur Verfügung gestellt. Dies kann durch einfaches Polling erreicht werden. Viele Datenbanken erlauben es zudem, über Änderungen an Tabellenzeilen zu benachrichtigen, so dass diese direkt in die Stream Data Plattform geschrieben werden können, z.B. das Oplog in MongoDB oder Golden Gate in Oracle.

Durch die Tatsache, dass wir ein zentrales System haben, werden die Eventströme zu einer Art Verbindungspunkt auf organisatorischer Ebene - Daten aus verschiedensten Quellen können miteinander kombiniert oder korreliert werden. Eine Silobildung gibt es nicht. Auf der anderen Seite werden die Systeme des Unternehmens voneinander entkoppelt. Wer Daten produziert, muss nichts über die Systeme wissen, die die Daten konsumieren. Umgekehrt interessieren sich auch die Konsumenten nur für Datenströme, nicht für andere Systeme, und alle Streams funktionieren nach dem gleichen Prinzip - ein kontinuierlicher Strom von Events.

Die Plattform selbst ist ebenfalls wie ein Strom aufgebaut. Im Gegensatz zu einem “Netz” von Systemen, das kreuz und quer Daten miteinander austauscht, fließen die Daten in eine Stream Data Plattform, werden dort verarbeitet, und fließen dann weiter in use-case-bezogene Datenbanken und Systeme.

Stream Data Platform

Am Beispiel von Apache Kafka lässt sich eine solche Plattform gut umsetzen.

Kafka ist ein persistenter Message-Broker, der in Topics aufgeteilt wird. Ein Producer schreibt in ein Topic, ein Consumer liest aus einem Topic. Die Position eines Consumers im Topic, der Offset, wird gespeichert, so dass bei einem Absturz von der gleichen Stelle weitergelesen wird. Verschiedene Consumer können an unterschiedlicher Stelle aus dem gleichen Topic lesen.

Frontends, Services, oder Sensoren schreiben ihre Events in Kafka-Topics, die Input-Topics genannt werden. Die Daten aus den Input-Topics werden dann von Streaming Systemen, je nach Use Case z.B. Kafka Streams oder Spark Streaming, gelesen, verarbeitet und wieder in abgeleitete Topics nach Kafka zurückgeschrieben. Die Input-Topics werden üblicherweise in Langzeitspeicher geschrieben. Die abgeleiteten Topics werden in Datenbanken geschrieben, die wiederum von Dashboards und sonstigen Apps ausgelesen werden. Beides kann über Kafka Connect geschehen, ein Tool zum Laden von Daten nach und von Kafka, das Connectoren zu vielen Datenbanken bietet.

Ein ausführliches Intro zu Apache Kafka folgt.

Mehr zum Thema Streams und Modellieren von Events findet sich in diesem vorherhigen Blogpost.

NoETL

Passend zu diesen Themen ist NoETL entstanden - der Name ist bewusst in Anlehnung an NoSQL gewählt, denn auch hier wird ein radikales Umdenken im Umgang mit Daten gefordert - ETL (oder ELT) soll abgeschafft werden.

Wie eingangs erwähnt, werden in vielen BigData-Projekten alle verfügbaren unstrukturierten Daten in Rohform in einen Datensee gekippt, in der Hoffnung, ein magischer Algorithmus wird daraus schon wertvolle Erkenntnisse gewinnen. Jedes System, das mit den Daten arbeiten will, muss also wieder Datenbereinigung betreiben. Dabei ist oftmals absehbar, welche Daten benötigt werden, um einen bestimmten Use Cases zu erfüllen. NoETL plädiert dafür, genau wie in Programmiersprachen eine “strenge Typisierung” der Daten vorzunehmen - das heißt klar zu definieren, in welchem Format die Daten eintreffen. Damit entfällt das E (die Extrahierung) und wir genügen auch den Anforderungen des Prinzips der Datensparsamkeit.

Landen diese klar definierten Daten nun direkt in einer zentralen Streaming Plattform, können unterschiedliche Dienste auf jeden ihnen erlaubten Strom zugreifen. Jeder Strom kann auch jederzeit in ein weiteres System überführt werden. Dies ist aber keine wesentliche Eigenschaft dieser Systeme und damit entfällt auch das L.

Als Ablösung für ETL wird CTP vorgeschlagen - consume, transform, produce. Die Datenströme der zentralen Streaming Plattform werden kontinuierlich von verschiedenen Modulen konsumiert, mit den Daten wird etwas getan (sie werden also in andere Daten transformiert), und das Ergebnis wird zurück in die Plattform oder ein Drittsystem produziert.

Datenformat

Es wird empfohlen, für die strenge Typisierung ein unternehmensweit einheitliches Datenformat zu wählen, mit dem die jeweiligen Streams modelliert werden. Jedem Stream wird dann ein festes Schema zugeordnet, damit jeder Konsument genau weiß, was für Datensätze ihn mit welchen Eigenschaften inklusive Datentypen und Pflichtfeldern erwarten. Wenn die Daten am Ursprungsort in diesem Format erzeugt werden, entfällt die Datenbereinigung. Wird eine Datenquelle in das feste Format überführt, wird die Datenbereinigung auf diese eine Stelle reduziert.

Dafür hat sich Apache Avro in meinen Projekten bewährt. Es bietet eine einfache Modellierungssprache, ein Serialisierungssystem, und unterstützt Schema-Evolution. Ein Blogpost, der Avro im Detail beschreibt, folgt.

Zusammenfassung

Die Kappa-Architektur ist die logische Weiterentwicklung der Lambda-Architektur und ersetzt Speed-, Batch- und Serving-Layer durch die zentrale Streaming-Plattform.

Benötigen Sie Unterstützung beim Aufbau einer Stream Data Platform? Kontaktieren Sie mich gerne.

  1. Es wird geschätzt, dass der Aufwand in vielen BigData-Projekten bis zu 90% aus Datenbereinigung besteht.

  2. So genannt in Putting Apache Kafka to Use: A Practical Guide to Building a Stream Data Platform

Diesen Post teilen

RSS-Feed

Neue Posts direkt im Newsreader.

RSS-Feed abonnieren

Newsletter

Neue Posts sowie Neuigkeiten rund um Big Data, Spark, und Scala. Maximal eine E-Mail im Monat.

Kommentare