In the Code: Griechische Architekturen - alles Lambda, oder was?

Um aus Daten Wert zu schaffen, sind Qualität und Geschwindigkeit wichtig. Simon Hefti von D-One vergleicht die drei aktuellen Architektur-Ansätze.
 
Es ist bereits wieder eine Weile her, dass der slogan “data is the new black” die Runde gemacht hat. Damit wurden - nebst der Andeutung von unermesslichem Reichtum - die Themen wertvoller Rohstoff, clevere Suche (Mining) und die Notwendigkeit der Veredelung (Raffinerie) angedeutet. Es ist klar: die Analogie ist so verlockend wie sie hinkt.
 
Die klassische Architektur von Datensystemen (die klassische Data-Pipeline) enthält aber tatsächlich eine Raffinerie - dort geht es darum, Daten aus verschiedenen Quellsystemen zusammenzuführen, zu “reinigen” und zu vernetzen - also mit den anderen Daten in Kontext zu setzen. Auf diese Weise entsteht eine Datengrundlage, die für verschiedene Anwendungen vom Reporting über Analytics bis zum Forecasting verwendet werden kann.
 
Das Problem ist nur: das Durchlaufen der Daten durch diese Raffinerie braucht Zeit. Nicht wahnsinnig viel Zeit - einige Stunden typischerweise - aber doch mehr Zeit, als in modernen Anwendungen zur Verfügung steht. "Near Realtime" heisst die Anforderung der Stunde.
 
(Die Begründung liegt in der Geschwindigkeit der Geschäftsprozesse - soll beispielsweise ein Verkauf mit Daten unterstützt werden, so kann das nur während dem Verkaufsprozess erfolgen. Wir überlassen die Herleitung der Begründung dem Leser als Übung … ;))
 
Das heisst, es stehen sich zwei widersprüchliche Anforderungen gegenüber: die Daten sollen sowohl möglichst “frisch” wie auch möglichst hoch in der Qualität sein.
 
Unterschiedliche Architekturen im Vergleich
 
Das hat zu verschiedenen Architektur-Ansätzen geführt, die hier kurz erläutert werden: die Lambda-Architektur, die einen batch- und einen stream-Bereich bereitstellt, die Kappa-Architektur, die alles über Streaming abwickelt sowie die Datenfluss-Architektur, die den Widerspruch auf der Ebene Datenzugriff löst.
 
Beginnen wir mit der Lambda-Architektur.
 
Hier wird der klassischen Raffinerie eine zweite Datenstrecke zur Seite gestellt.
 
Über diesen zusätzlichen “Fast Track” werden Daten untertags verarbeitet und zur Verfügung gestellt. Am Ende des Tages (oder allgemeiner: einer bestimmten Periode) werden diese Daten dann typischerweise verworfen, da sie nun in guter Qualität auch über die “alte” Datenstrecke zur Verfügung stehen.
 
Nun fragen Sie sich vielleicht, warum die Datenqualität auf der Batch-Strecke besser sei als auf der Speed-Strecke? Grundsätzlich dürfte es ja zwischen den beiden keinen Unterschied geben. Die Antwort ist recht einfach: die Speed-Strecke fokussiert sich darauf, die Daten schnell bereitzustellen. Sollte zwischendurch ein Datenelement, so hält das die Verarbeitung nicht auf. Das zeigt sich etwas im Ansatz “eventually consistent”. Das ist auf der Batch-Strecke anders: hier liegt das Primat auf der Qualität, was bedeutet, dass die Verarbeitung erst abgeschlossen wird, wenn alle 6 C (Clean, Consistent, Complete, Current, Compliant, Collaborative) erfüllt sind.
 
Der Vorteil der Lamdba-Architektur ist, dass sie die Anforderung von Near-Realtime erfüllt. Der Nachteil ist zum Einen die zusätzliche Komplexität (der Speed Layer besteht typischerweise aus einer beträchtlichen Anzahl Maschinen und die Daten fliessen nun über 2 unabhängige Wege, was der Anforderung der Konsistenz nicht förderlich ist), und zum Anderen, dass die Anforderungen an den Serving Layer gestiegen sind. An jene Komponente also, die dem Benutzer die Daten in guter Qualität und verständlicher Form bereitstellt - denn nun müssen die beiden Datenstrecken an dieser Stelle wieder zusammengeführt werden.
 
Vor- und Nachteile der Kappa-Architektur
Die Kappa-Architektur ist eine radikale Weiterentwicklung des Gedankens, eine zweite, schnelle Datenstrecke einzuführen. Hier wird ganz auf die Batch-Verarbeitung verzichtet, man arbeitet nur noch mit dem Speed Layer.
 
Voraussetzung dafür ist, dass alle ankommenden Daten unveränderbar abgelegt werden (insert-only).
 
Dieser Ansatz hat verschiedene Vorteile. Auch hier wird die Near-Realtime Anforderung erfüllt, und die Architektur ermöglicht, den gesamten Datenbestand zu jedem Zeitpunkt neu zu prozessieren. Denn ab und zu schleichen sich Fehler in die Datenverarbeitung ein. Da alle Daten in Rohform gespeichert sind, ist es möglich, solche Fehler zu korrigieren - das einzige, was man investieren muss, ist die Zeit, die die erneute Datenverarbeitung in Anspruch nimmt.
 
Auf der anderen Seite ist die Aufgabe des Serving Layer nicht leichter geworden - denn auch in dieser Architektur erfolgt das Zusammenführen der Daten aus verschiedenen Quellen zur Abfragezeit.
 
Das heisst, die Kappa-Architektur vereinfacht zwar die Lambda-Architektur, verschiebt aber einen wichtigen Teil der Raffinerie-Arbeit sozusagen an die Tankstelle.
 
Mix als dritte Variante
Eine weitere Variante ist die Data Flow Architecture ("rheo architecture"). Diese wurde unseres Wissens bisher nicht beschrieben. Es handelt es sich eine Mischung der drei Ansätze (klassische Raffinerie, Lambda und Kappa). Dabei wird die klassische Raffinerie um zwei Elemente ergänzt: den Data Lake, der wie bei der Kappa Architecture dafür sorgt, dass das System nie vergisst, und ein Zugriffs-API.
 
Der Trick ist die Anreicherung der hoch-qualitativen Daten mit frischen Daten. Das Zugriffs-API hat die Aufgabe, die jeweils bestmögliche Datenqualität zu liefern. Das bedeutet, dass der Datenabgriff entlang der Verarbeitungsstrecke erfolgt. Im Normalfall erfolgt der Abgriff am Ende der Kette (wie im klassischen Bild), andernfalls im jeweils besten Verarbeitungsstand. Mit anderen Worten: die Raffinerie wird geöffnet, und Zwischenprodukte werden nutzbar.
 
Eine Architektur gehört ins Geschichtsbuch
Um aus Daten Wert zu schaffen, ist beides wichtig - Qualität und Geschwindigkeit. Es ist deshalb folgerichtig, dass Architekturen entwickelt werden, die diese Anforderungen abdecken. Die Herausforderung, diese widersprüchlichen Anforderungen unter einen Hut zu bringen, ist gross. Entsprechend wird die Suche nach der richtigen Architektur noch ein zwei Iterationen durchlaufen. Eines ist klar: der klassische Ansatz der monatlichen (oder täglichen) Beladung gehört der Vergangenheit an.
 
Über den Autor:
Simon Hefti ist Gründer und Verwaltungsrats-Präsident von D-One, einer Beratungsfirma für datenbasierte Wertschöpfung.