Lambda Architecture
Schnelle Zwischenstände mit regelmäßiger Neuberechnung verbinden
Die Idee und ihr Nutzen
Eine Versicherung zeigt die Zahl der Schadenmeldungen seit Jahresbeginn in einer Übersicht namens „Anzeige“. Um 10 Uhr sollen auch die Meldungen sichtbar sein, die seit Mitternacht eingetroffen sind. Zugleich sollen Korrekturen an älteren Meldungen, etwa die Rücknahme einer Meldung vom Vortag, in einen verlässlichen Jahresstand eingehen. Dafür arbeiten zwei Berechnungen nebeneinander: Ein Nachtlauf berechnet den Jahresstand jede Nacht aus allen gespeicherten Meldungen und Korrekturen neu, und eine schnelle Berechnung zählt jede Meldung seit Mitternacht sofort mit. Die „Anzeige“ setzt beide Zahlen zusammen und kennzeichnet die Zahl der schnellen Berechnung als vorläufig. Diese Bauweise heißt Lambda Architecture. Den Namen hat ihr Nathan Marz gegeben.
Wie funktioniert es?
Der Meldedienst der Versicherung nimmt Schadenmeldungen und spätere Korrekturen an. Eine solche Korrektur ist das Storno, die Rücknahme einer Meldung. Der Meldedienst legt jede Meldung und jedes Storno in einem Datenbestand ab, den gespeicherten Ausgangsdaten. In der Nacht von Montag auf Dienstag liest der Nachtlauf alle gespeicherten Ausgangsdaten bis Ende Montag. Der Nachtlauf ermittelt daraus 10.000 Meldungen seit Jahresbeginn und übergibt diesen Stand der „Anzeige“. Bis Dienstag um 10 Uhr speichert der Meldedienst weitere 20 Meldungen und gibt sie zugleich an die schnelle Berechnung weiter. Die schnelle Berechnung zählt nur Meldungen, die nach dem Ende des Montags eingetroffen sind. Dann übergibt die schnelle Berechnung der „Anzeige“ den Zwischenstand „+20 vorläufig“. Die „Anzeige“ zeigt 10.020 und kennzeichnet die 20 Meldungen vom Dienstag als vorläufig. Danach speichert der Meldedienst das Storno einer Meldung vom Montag. Verarbeitet die schnelle Berechnung diese rückwirkende Korrektur nicht, zeigt die „Anzeige“ bis zur nächsten Nacht eine Meldung zu viel. In der nächsten Nacht liest der Nachtlauf alle gespeicherten Ausgangsdaten bis Ende Dienstag und berücksichtigt dabei das Storno. Sein neuer Jahresstand ersetzt in der „Anzeige“ den Zwischenstand der schnellen Berechnung für denselben Zeitraum.
Der Zeitpunkt, bis zu dem der Nachtlauf die gespeicherten Ausgangsdaten liest, heißt Stichtag. Der Nachtlauf ist eine Stapelverarbeitung: Er verarbeitet viele gespeicherte Datensätze in einem geplanten Lauf, und sein Ergebnis gilt zum Stichtag. Die schnelle Berechnung ist eine fortlaufende Verarbeitung: Sie zählt jede Meldung nach dem Stichtag, sobald der Meldedienst die Meldung weitergibt. So liefert sie rasch einen Zwischenstand. Das Team, das beide Berechnungen entwickelt, muss festlegen, wie die schnelle Berechnung mit Korrekturen umgeht, etwa ob sie das Storno einer Meldung vom Montag abzieht. Weil die schnelle Berechnung ältere Korrekturen nicht immer erfasst, ist ihr Zwischenstand nur vorläufig. Die „Anzeige“ verwaltet, welcher Stichtag gerade gilt, und addiert den Stand des Nachtlaufs bis zum Stichtag und den Zwischenstand der schnellen Berechnung ab dem Stichtag. Die beiden Zeiträume dürfen sich nicht überschneiden, sonst zählt die „Anzeige“ Meldungen doppelt. Zu jeder Zahl nennt die „Anzeige“ den Zeitpunkt und den Status, also ob die Zahl verlässlich oder vorläufig ist. So erkennen die Leser der „Anzeige“, welcher Teil der Zahl sich noch ändern kann.
Fällt ein Nachtlauf aus, bleibt der alte Stichtag gültig. Die schnelle Berechnung muss dann weiter ab diesem alten Stichtag zählen, damit keine Meldungen fehlen.
Lambda: Nachtlauf plus schneller Zwischenstand
Wann ist es sinnvoll und wann nicht?
Die Lambda Architecture lohnt sich
- Ein verlässlicher Nachtlauf besteht bereits und soll erhalten bleiben. Ohne schnelle Berechnung zeigt die „Anzeige“ um 10 Uhr einen zehn Stunden alten Stand, in dem die Meldungen vom Morgen fehlen.
- Korrekturen an älteren Meldungen sollen in einen vollständig neu berechneten Stand eingehen. Der Nachtlauf berücksichtigt zum Beispiel das Storno einer Meldung vom Montag, auch wenn die schnelle Berechnung das Storno nicht verarbeitet hat. Ohne Nachtlauf bliebe die zurückgenommene Meldung in der „Anzeige“, bis jemand den Fehler bemerkt.
- Ein Programm, das jede Meldung sofort mitzählt, müsste ohne Nachtlauf allein mit verspäteten Meldungen, Stornos und anderen Korrekturen richtig umgehen. Mit dem Nachtlauf daneben verfälscht ein Fehler in der schnellen Berechnung die „Anzeige“ nur bis zur nächsten Nacht.
- Das Team kann sicherstellen, dass der Nachtlauf und die schnelle Berechnung am Stichtag genau aneinander anschließen. Dann zählen die beiden Berechnungen keine Meldung doppelt und lassen keine aus. Gelingt das nicht, zählt die „Anzeige“ Meldungen am Stichtag doppelt oder lässt welche aus.
Die Lambda Architecture ist nicht das Richtige
- Eine einzige fortlaufende Verarbeitung kann auch verspätete Meldungen und Korrekturen richtig zählen, und die Meldungen und Korrekturen lassen sich lange genug aufbewahren. Mit Lambda Architecture stünde die Zählregel dann ohne Grund in zwei Programmen. Stattdessen baut das Team eine Kappa Architecture: Das Programm, das neue Meldungen fortlaufend zählt, verarbeitet die gespeicherten Meldungen und Korrekturen noch einmal von vorn, wenn ein Stand neu berechnet werden muss. Das Team pflegt die Zählregel dann nur in einem Programm, und der Nachtlauf entfällt.
- Das Team hat nicht genug Leute, um die Zählregel dauerhaft im Nachtlauf und in der schnellen Berechnung zu pflegen und jede Änderung in beiden auf Übereinstimmung zu prüfen. Dann betreibt das Team entweder nur den Nachtlauf oder nur eine einzige fortlaufende Verarbeitung nach der Kappa Architecture, und die Zählregel steht nur in einem Programm. Läuft nur der Nachtlauf, fehlen in der „Anzeige“ die Meldungen seit Mitternacht. Läuft nur die fortlaufende Verarbeitung, muss diese Verarbeitung auch Stornos und verspätete Meldungen selbst richtig zählen.
- Ein Stand vom Vortag reicht, und niemand braucht Zwischenstände. Die schnelle Berechnung würde dann Zwischenstände liefern, die niemand liest. Stattdessen betreibt das Team nur den Nachtlauf, wie es Batch Processing beschreibt. Die schnelle Berechnung, ihr Betrieb und das Zusammensetzen der beiden Stände in der „Anzeige“ entfallen.
Nachteile und typische Fehler
Die Zählregel ist zweimal programmiert, im Nachtlauf und in der schnellen Berechnung. Jede fachliche Änderung muss in beiden umgesetzt und auf Übereinstimmung geprüft werden. Beide Programme brauchen Betrieb, Überwachung und Fehlersuche, und das Team braucht Kenntnisse in zwei verschiedenen Arten der Verarbeitung. Die gespeicherten Ausgangsdaten müssen vollständig aufbewahrt werden, damit der Nachtlauf den Jahresstand jede Nacht neu berechnen kann. Mit jedem Monat wächst die Datenmenge, die der Nachtlauf liest.
Typische Fehler und woran man sie erkennt:
- Fehler am Stichtag: Der Nachtlauf zählt alle Meldungen bis Montag 24 Uhr. Die schnelle Berechnung zählt dagegen schon ab Montag 23 Uhr, weil ihr Stichtag eine Stunde zu früh eingestellt ist. Die Meldungen zwischen 23 und 24 Uhr zählt die „Anzeige“ dann doppelt. Beginnt die schnelle Berechnung umgekehrt erst nach dem Stichtag, fehlen die Meldungen dazwischen. Erkennbar ist das an einem Sprung der „Anzeige“ direkt nach dem Nachtlauf, den keine Korrektur erklärt.
- Abweichende Zählregeln: Die Fachabteilung legt fest, dass Meldungen ohne Vertragsnummer nicht mehr zählen. Das Team setzt die Änderung nur im Nachtlauf um. Die schnelle Berechnung zählt solche Meldungen weiter, und der Nachtlauf zieht sie in der folgenden Nacht wieder ab. Erkennbar ist das an Zwischenständen, die nach jedem Nachtlauf in dieselbe Richtung korrigiert werden.
- Fehlende Kennzeichnung: Die „Anzeige“ kennzeichnet den Zwischenstand nicht als vorläufig. Ändert der nächste Nachtlauf die Zahl wegen verspäteter Meldungen oder Korrekturen, sieht das wie ein unerklärlicher Zahlensprung aus. Erkennbar ist das an Rückfragen, warum die Zahl über Nacht gesunken ist.
- Ausgefallener Nachtlauf: Der Nachtlauf in der Nacht auf Mittwoch scheitert, und die „Anzeige“ behält den Stand bis Ende Montag. Die schnelle Berechnung zählt trotzdem erst ab Ende Dienstag, dem Stichtag, den der ausgefallene Nachtlauf gesetzt hätte. Die Meldungen vom Dienstag fehlen dann in der „Anzeige“. Erkennbar ist das an einem Stand, der am Morgen niedriger ist als am Vorabend.
Weiterführend
Verwandte Ansätze
- Stream Processing: die fortlaufende Verarbeitung neuer Datensätze, nach der die schnelle Berechnung arbeitet.
- Data Lake: ein möglicher Speicherort für die gespeicherten Ausgangsdaten, aber keine Voraussetzung.
Werkzeuge und Umsetzungen
- Apache Spark: kann den Nachtlauf umsetzen und mit Structured Streaming auch die schnelle Berechnung.
- Apache Flink: verarbeitet eintreffende Daten fortlaufend. Ob Flink auch den Nachtlauf übernimmt, hängt vom Entwurf ab.
- Apache Kafka: kann neue Meldungen an beide Berechnungen liefern.
- Apache Druid: kann vorberechnete und neue Daten für eine Abfrage bereitstellen. Die genaue Grenze zwischen den Zeiträumen muss das Team selbst festlegen.
Quellen
- Nathan Marz, James Warren: Big Data. Principles and best practices of scalable realtime data systems: Buch von 2015, in dem Nathan Marz die Lambda Architecture darstellt.
- Jay Kreps: Questioning the Lambda Architecture: Aufsatz von 2014, der den Aufwand kritisiert, dieselbe Berechnung in zwei Programmen übereinstimmend zu halten, und die Neuberechnung mit einer einzigen fortlaufenden Verarbeitung vorschlägt.