Lambda-Architecture: Definition und Abgrenzung zu Kappa

Lambda-Architecture bezeichnet ein Muster für Datenarchitekturen, das denselben Strom eingehender Ereignisse (etwa Klicks, Sensormesswerte oder Transaktionen) auf zwei parallelen Wegen verarbeitet: einem Batch-Layer (langsame, aber vollständige Neuberechnung über alle historischen Daten) und einem Speed-Layer (schnelle, aber ungenauere Verarbeitung der jüngsten Ereignisse). Ein Serving-Layer legt beide Ergebnisse übereinander und beantwortet Abfragen aus dieser kombinierten Sicht. Nathan Marz prägte das Muster 2011, um den Zielkonflikt zwischen Vollständigkeit und Aktualität nicht in einer einzigen Engine, sondern durch zwei getrennte Pfade auf demselben Ereignisstrom aufzulösen.

Was ist Lambda-Architecture?

Die Architektur besteht aus drei Schichten. Der Batch-Layer speichert alle Rohdaten unverändert (append-only, also nur anhängen, nie überschreiben) und rechnet in regelmäßigen Abständen (etwa nächtlich) den kompletten Datenbestand zu einer neuen, präzisen Ergebnistabelle (dem sogenannten Master-View) zusammen. Der Speed-Layer liest parallel denselben Ereignisstrom, verarbeitet ihn Ereignis für Ereignis (inkrementell) und liefert Näherungswerte für die letzten Minuten oder Stunden, für die der Batch-Layer noch nicht neu gerechnet hat. Der Serving-Layer legt beide Ergebnisse übereinander und beantwortet Abfragen (Queries) aus dieser kombinierten Sicht.

Nathan Marz beschrieb das Muster 2011 zunächst als „Batch/Realtime-Architektur" in einem [Blogbeitrag zum CAP-Theorem](http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html) und formalisierte es später mit James Warren im Buch [Big Data](https://www.manning.com/books/big-data) (Manning, 2015). Sein Argument: Batch-Verarbeitung produziert deterministische, präzise Ergebnisse, ist aber langsam; Streaming ist schnell, aber (zum damaligen Stand) fehleranfälliger und approximativ. Zwei parallele Pfade kombinieren beide Stärken und begegnen dem Zielkonflikt aus dem CAP-Theorem auf Systemebene, statt ihn in einer Engine auflösen zu wollen.

Der zentrale Grundsatz ist die „eventual accuracy": Der Speed-Layer liefert schnelle, aber ungenauere Werte für die jüngste Zeitscheibe. Sobald der Batch-Layer über diesen Zeitraum neu berechnet hat, überschreibt der genaue Master-View die Näherung im Serving-Layer. Der Rohdaten-Speicher im Batch-Layer bleibt append-only, sodass sich jede Master-View bei geänderter Logik durch einen neuen Batch-Lauf rekonstruieren lässt.

Die klassische Baustein-Sammlung der Ur-Fassung sind Hadoop/HDFS mit MapReduce für den Batch-Layer, Apache Storm oder [Apache Spark](https://spark.apache.org/) Streaming für den Speed-Layer und NoSQL-Stores wie Apache HBase oder Apache Cassandra für den Serving-Layer. Der Preis dieses Aufbaus ist strukturell: zwei parallele Code-Basen mit unterschiedlicher Semantik (Batch-Job und Streaming-Job müssen dieselbe Kennzahl berechnen), doppelte Betriebs-Verantwortung und ein Merge-Layer, der bei Schema-Änderungen konsistent gehalten werden muss.

Abgrenzung: Kappa, Medaillon und moderne Lakehouse-Ansätze

Die Lambda-Architecture wird häufig mit benachbarten Konzepten verwechselt. Die folgende Tabelle klärt die vier zentralen Abgrenzungen.

Begriff	Verhältnis zur Lambda-Architecture
Kappa-Architecture	Streaming-only-Alternative (Kreps, 2014); ersetzt Batch- und Speed-Layer durch einen einzigen Streaming-Pfad, dessen Historie durch Log-Replay entsteht
Medaillon-Architektur	mehrstufiges Qualitäts-Schichtenmodell (Bronze, Silver, Gold) auf einem Lakehouse; orthogonaler Frame, orientiert am Verarbeitungsgrad statt an der Trennung Batch/Stream, mit Lambda- oder Kappa-Verarbeitung kombinierbar
Moderne Lakehouse-Ansätze mit Structured Streaming	eine einheitliche Engine verarbeitet Batch- und Stream-Workloads mit derselben API auf denselben Tabellen; das Lambda-Argument getrennter Pfade entfällt weitgehend
Klassische Batch-Analytics	geplante Läufe ohne Streaming-Komponente; Lambda ergänzt Batch um einen zweiten, kontinuierlichen Pfad statt ihn zu ersetzen

Die Abgrenzung zur Kappa-Architecture ist die wichtigste. Beide adressieren dasselbe Problem (Echtzeit und historische Wahrheit in einer Architektur), verteilen den Aufwand aber unterschiedlich: Lambda akzeptiert zwei Code-Basen für Batch und Stream und gewinnt die Freiheit, für jeden Pfad die technisch passende Engine zu wählen; Kappa verlangt lange Log-Retention und ausreichenden Replay-Durchsatz, spart dafür den Batch-Layer vollständig ein.

Beispiel: Ad-Tech-Impression-Analytik

Ein Betreiber einer Ad-Tech-Plattform verarbeitet Impression- und Click-Ereignisse zweigleisig. Der Batch-Layer aggregiert die kompletten Rohdaten der letzten 24 Stunden über einen nächtlichen MapReduce-Job zu tagesgenauen Kampagnen-Kennzahlen und schreibt sie in eine Serving-Tabelle. Parallel liest ein Storm- oder Spark-Streaming-Job denselben Ereignisstrom kontinuierlich und aktualisiert eine zweite Tabelle mit den Impressions der letzten Minuten.

Eine Query im Serving-Layer merged beide Tabellen: die Batch-Aggregate für alles bis Mitternacht plus die inkrementellen Streaming-Werte für den laufenden Tag. Wird die Kennzahl-Logik geändert, muss die neue Regel in beiden Codebasen (Batch und Streaming) parallel gepflegt und getestet werden. Weitere klassische Einsatzfelder sind Fraud Detection auf Zahlungsströmen, IoT-Telemetrie mit langer Retention und Netzwerk-Analytik im Telekommunikations-Umfeld, vor allem dort, wo bestehende Hadoop- und Storm-Landschaften bereits produktiv laufen.