Zum Hauptinhalt springen

Lambda Architecture

Einleitung​

Lambda Architecture ist ein Datenverarbeitungsansatz, der zwei Ziele kombiniert:

  • Niedrige Latenz (Realtime)
  • Hohe Korrektheit (vollständige Recomputes)

Sie erreicht das durch zwei getrennte Verarbeitungspfade:

  • Batch Layer
  • Speed Layer

Lambda war eine Antwort auf eine Zeit,
in der Streaming-Systeme noch nicht ausgereift waren.

Einordnung

Lambda ist eine Daten- und Stream-Architektur mit dualer Pipeline.

Sie beschreibt:

  • wie große Datenmengen verarbeitet werden
  • wie Realtime und Korrektheit kombiniert werden
  • wie Ergebnisse aus zwei Pfaden zusammengeführt werden

Lambda ist kein Messaging-Pattern –
sondern ein vollständiges Datenplattform-Modell.

Ursprung

Popularisiert von Nathan Marz im Hadoop-Umfeld.

Problemstellung damals:

  • Batch-Systeme waren korrekt, aber langsam.
  • Streaming-Systeme waren schnell, aber unzuverlässig.

Lambda kombinierte beides.

Grundprinzip

Kernaussage:

  • Rohdaten sind immutable gespeichert
  • Zwei Verarbeitungspfade berechnen Ergebnisse
  • Serving Layer vereinigt beide

Architekturkomponenten

1️⃣ Batch Layer​

  • Verarbeitet vollständige Datenhistorie
  • Führt periodische Recomputes durch
  • Liefert korrekte, vollständige Views

Typisch: Hadoop, Spark

2️⃣ Speed Layer​

  • Verarbeitet neue Events sofort
  • Liefert Near-Realtime-Ergebnisse
  • Überbrückt Zeit bis zum nächsten Batch

Typisch: Storm, Flink, Kafka Streams

3️⃣ Serving Layer​

  • Aggregiert Ergebnisse aus Batch und Speed
  • Beantwortet Queries
  • Muss Inkonsistenzen handhaben

Warum Lambda attraktiv war

  • Toleranz gegen Datenfehler
  • Rebuild-Fähigkeit
  • Realtime ohne Verzicht auf Korrektheit
  • Gute Skalierbarkeit im Big-Data-Kontext

Lambda war pragmatisch.

Strukturelle Nachteile

1️⃣ Doppelte Logik​

  • Zwei Codepfade
  • Zwei Teststrategien
  • Zwei Fehlerquellen

Jede Business-Logik existiert faktisch doppelt.

2️⃣ Operative Komplexität​

  • Zwei Pipelines betreiben
  • Zwei Monitoring-Stacks
  • Zwei Skalierungsmodelle

Lambda ist infrastrukturell schwergewichtig.

3️⃣ Inkonsistenz-Risiko​

Batch- und Speed-Layer können:

  • unterschiedliche Ergebnisse liefern
  • unterschiedliche Bugs enthalten
  • unterschiedlich versioniert sein

Die Serving-Layer-Logik wird komplex.

Organisatorische Implikationen

Lambda erfordert Teams mit:

  • Batch-Kompetenz
  • Streaming-Kompetenz
  • Datenplattform-Know-how

Koordinationsaufwand ist hoch.

Lambda vs. Kappa

KriteriumLambdaKappa
VerarbeitungspfadeBatch + StreamNur Stream
Code-Komplexitäthochgeringer
ReprocessingBatch-RebuildLog-Replay
Infrastrukturschwergewichtigstreaming-zentriert
Typische NutzungBig Data AnalyticsEvent-Driven Analytics

Lambda priorisiert Robustheit. Kappa priorisiert Vereinfachung.

Eignung 2026

Geeignet bei:​

  • Sehr großen Datenmengen
  • Starkem Batch-Fokus
  • Periodischen Vollrecomputes
  • Data-Warehouse-nahen Workloads
  • Compliance-getriebenen Systemen

Weniger geeignet bei:​

  • Streaming-dominanten Systemen
  • Event-Driven-Plattformen
  • Teams mit begrenzten Ressourcen
  • Cloud-native Umgebungen mit starkem Log-Backbone

Heute wird Lambda selten neu aufgebaut – bestehende Systeme werden eher stabilisiert oder zu Kappa migriert.

Praxis-Check

Szenario 1: Log-Analytics im Big-Data-Umfeld​

Batch berechnet vollständige Reports, Speed liefert Near-Realtime-Dashboards.

Lambda passt.

Szenario 2: Realtime-Plattform mit Event-Backbone​

Streaming ist dominant, Replay genügt für Reprocessing.

Kappa ist einfacher.

Fazit

Lambda Architecture war eine elegante Lösung für ein historisches Problem.

Sie kombiniert:

  • Realtime
  • Rebuild-Fähigkeit
  • Robustheit

Aber:

Sie erkauft das durch doppelte Komplexität.

In modernen Streaming-Ökosystemen wird Lambda oft durch Kappa ersetzt – nicht weil Lambda falsch ist, sondern weil Streaming heute robuster geworden ist.