Real-Time Analytics Architektur: Lambda vs Kappa

Deine Dashboards zeigen Zahlen von gestern. Dein Fraud-Team prüft Alerts eine Stunde nach der Transaktion. Dein Ops-Team sieht Incidents im Monitoring vor der Analytics-Plattform. Klingt vertraut? Du hast ein Real-Time-Analytics-Architektur-Problem — und die Lösung beginnt mit der Wahl zwischen zwei konkurrierenden Philosophien und dann der richtigen Query-Engine, die Ergebnisse schnell liefert.

TL;DR

Lambda-Architektur fährt Batch und Streaming parallel — präzise, aber operativ teuer. Kappa-Architektur vereint alles in einer einzigen Streaming-Pipeline — einfacher, aber anspruchsvoll. Für die OLAP-Serving-Schicht dominieren ClickHouse, Apache Druid und Apache Pinot je einen anderen Use-Case.

Das Kernproblem: Processing-Latenz

Klassische Data-Warehouses sind für Batch gebaut. Nightly Loads, stündliche Refreshes, mehrstündige Transformations-Pipelines. Das ist fine für Trend-Reporting, bricht aber, wenn dein Business braucht:

• Fraud-Detection zur Transaktionszeit
• Live-Dashboard-Updates bei Peak-Traffic
• Real-Time-Inventory über tausende SKUs
• Operatives Monitoring, das Anomalien in Sekunden fängt

Die Lücke zwischen "Event passiert im Source-System" und "Analyst sieht es im Dashboard" ist Processing-Latenz. Sie zu schließen heißt, sowohl Bewegung als auch Bereitstellung neu zu denken.

Lambda-Architektur: Batch + Speed-Layer

Lambda-Architektur, popularisiert von Nathan Marz um 2011, löst das Latenz-Problem durch zwei parallele Pipelines.

① Der Batch-Layer reprocessed das volle historische Dataset auf Zeitplan — präzise, handhabt späte Daten, aber langsam. ② Der Speed-Layer verarbeitet Events near-real-time, deckt die Lücke seit dem letzten Batch. ③ Der Serving-Layer merged beide Views zur Query-Zeit, gibt Analysten frische Daten mit eventueller Präzision.

Die Kern-Idee: der Speed-Layer toleriert Approximation, weil der Batch-Layer ihn regelmäßig mit präzisen Ergebnissen überschreibt. Du hast immer frische Daten. Du hast immer präzise Daten. Nur nicht beide zur gleichen Zeit.

Lambda-Trade-offs

Wann Lambda funktioniert: Du hast eine reife Batch-Pipeline und fügst Streaming dazu. Dein Team hat beide Skillsets. Deine Aggregationen sind komplex genug, um in reinem Streaming schmerzhaft zu sein.

Wann Lambda dich enttäuscht: Deine Business-Logic ändert sich oft (jetzt updatest du sie zweimal). Du startest neu. Du hast nicht die operative Kapazität für zwei Systeme.

Kappa-Architektur: Nur Streaming

Kappa-Architektur, vorgeschlagen von Jay Kreps (Kafka-Co-Creator) 2014, eliminiert den Batch-Layer komplett. Alles ist ein Stream, auch Reprocessing.

① Ein durable Message-Log (Kafka mit langer Retention oder S3-backed Log) ist das System-of-Record. ② Der Stream-Processor handhabt alle Transformations — Real-Time und historisch. ③ Reprocessing funktioniert durch Replay des Logs mit einer neuen Version deines Streaming-Jobs.

Eine Codebase. Eine Pipeline. Gleiche Logic für historische und Real-Time-Daten.

Kappa-Trade-offs

Wann Kappa funktioniert: Greenfield-Systeme. Teams mit echter Streaming-Skills. Sich oft ändernde Business-Logic. Konsistente Sub-Minute-Latenz-SLAs über alle Query-Typen.

Wann Kappa kämpft: Petabyte-Scale historisches Reprocessing — Replay durch Kafka ist schmerzhaft. Sehr komplexe Aggregationen (Full-Outer-Joins über unbounded Windows). Teams neu im Streaming.

Lambda vs Kappa: Direkter Vergleich

Der Branchen-Trend seit 2020 geht zu Kappa-artigen Architekturen. Stream-Processoren sind reifer geworden. Object Storage hat Long-Term-Log-Retention billiger gemacht. Und die meisten Teams entdecken, dass zwei parallele Codebases nicht nachhaltig sind. Aber Lambda bleibt valide, wenn du komplexe historische Queries oder große bestehende Batch-Investitionen hast, die du nicht aufgeben kannst.

OLAP-Engines: ClickHouse, Druid und Pinot

Sowohl Lambda als auch Kappa brauchen eine schnelle Serving-Schicht — ein System, das analytische Queries mit niedriger Latenz gegen große Datasets beantwortet. Die drei dominanten Wahlen sind ClickHouse, Apache Druid und Apache Pinot. Sie sehen von außen ähnlich aus, sind aber für unterschiedliches optimiert.

ClickHouse

ClickHouse ist eine column-oriented OLAP-Datenbank, ursprünglich bei Yandex gebaut, jetzt Open-Source und backed by ClickHouse Inc. Optimiert für scan-lastige analytische Queries mit starkem Fokus auf Raw-Query-Speed und SQL-Ausdrucksstärke.

Stärken:

• Außergewöhnliche Ad-hoc-Query-Performance — gewinnt oft Benchmarks gegen viel größere Systeme
• Vertrauter SQL-Dialekt — Analysten können direkt abfragen
• Effiziente Komprimierung und vektorisierte Ausführung reduzieren Storage- und Compute-Kosten
• Streaming-Ingestion via Kafka-Table-Engine
• Managed: ClickHouse Cloud (consumption-based pricing)

Schwächen:

• Joins sind relativ langsamer — funktioniert am besten mit denormalisierten Daten
• Streaming-Ingestion verfügbar, aber nicht so low-latency wie Druid/Pinot
• Bei extremem Scale braucht Cluster-Management Expertise

Am besten für: Ad-hoc-Analytics, Log-Analytics, Time-Series-Dashboards, Teams die schnelles SQL ohne hohe operative Komplexität brauchen. Der praktische Default für die meisten neuen Real-Time-Analytics-Setups 2026.

Apache Druid

Apache Druid ist ein verteilter Data-Store, von Grund auf für Sub-Second-OLAP-Queries auf Real-Time- und historischen Event-Daten gebaut. Es ingestiert direkt aus Kafka mit Daten in Sekunden sichtbar.

Stärken:

• Native Kafka-Ingestion — wirklich Real-Time, kein Micro-Batch
• Pre-Aggregation (Rollup) zur Ingestion-Zeit — speichert aggregierte Metriken, ermöglicht extrem schnelle Queries
• Automatisches Daten-Tiering: recent in Memory, älter in Deep-Storage (S3/GCS)
• Bei massivem Scale bewährt (Meta, Netflix, Lyft)

Schwächen:

• Operative Komplexität hoch — sechs verschiedene Node-Typen (Broker, Coordinator, Historical, MiddleManager, Overlord, Router)
• SQL-Support verbessert sich, aber weniger ausdrucksstark als ClickHouse
• Rollup zerstört Raw-Event-Granularität, außer explizit deaktiviert
• Steile Lernkurve

Am besten für: Large-Scale Event-Analytics, Sub-Second-Dashboards auf Streaming-Daten, Teams die interne Analytics in erheblichem Scale bauen. Wenn du nicht im Druid-relevanten Scale bist, ist der operative Aufwand es nicht wert.

Apache Pinot

Apache Pinot wurde ursprünglich bei LinkedIn gebaut, später bei Uber adoptiert. Design-Fokus: high-concurrency, low-latency Queries für user-facing Analytics-Produkte — denke "wer hat dein Profil angesehen" in LinkedIn-Scale.

Stärken:

• Exzellent bei hoher Query-Concurrency (tausende QPS)
• Native Kafka-Ingestion, ähnlich Druid
• Star-Tree-Index für pre-aggregierte Queries auf high-cardinality Dimensions
• Gute Tenant-Isolation — nützlich für Multi-Tenant-Produkte

Schwächen:

• Weniger reifes SQL-Support als ClickHouse
• Operative Komplexität vergleichbar mit Druid
• Optimiert für vordefinierte Query-Patterns — ad-hoc nicht seine Stärke
• Kleinere Community als ClickHouse

Am besten für: User-facing Analytics-Produkte in Apps. Wenn du ein Feature baust, das Usern ihre eigenen Analytics at Scale zeigt, ist Pinot purpose-built. Für interne Dashboards ist ClickHouse besser.

Engine-Vergleich

Der praktische Entscheidungspfad

Beim Design eines Real-Time-Analytics-Stacks arbeite diese Fragen der Reihe nach durch:

1. Was ist dein Latenz-SLA? Sub-Second, Sub-Minute oder Sub-Stunde? Das bestimmt, ob du Streaming-Ingestion brauchst oder Micro-Batch ok ist.

2. Was läuft schon in Production? Wenn du eine reife Spark-Batch-Pipeline hast, ist Lambda (Speed-Layer hinzufügen) weniger riskant als ein voller Kappa-Rewrite. Bei Greenfield: Kappa.

3. Was sind deine Query-Patterns? Ad-hoc-Exploration → ClickHouse. Time-Series-Event-Analytics at Scale → Druid. High-Concurrency User-facing → Pinot.

4. Was sind die Streaming-Skills deines Teams? Ehrlich. Kappa mit Flink in Production braucht echte Expertise. Operators, die nie ein Watermark-Issue debuggt haben, werden kämpfen.

Für die meisten Teams 2026 ist der pragmatische Default: Kafka → Flink (oder Spark Structured Streaming) → ClickHouse. Kappa-artige Architektur mit handhabbarem operativem Aufwand und exzellentem SQL-Tooling.

Real-Time-Daten erkunden, bevor die Infra steht

Nicht jedes Team hat einen Druid-Cluster bereit. Während du deine Real-Time-Infrastruktur baust, musst du oft Event-Daten schnell explorieren — aus API-Exports, CSV-Snapshots oder hochgeladenen Event-Samples. Harbinger Explorer lässt dich diese Daten direkt im Browser mit DuckDB WASM abfragen, mit Natural-Language-Queries, die SQL automatisch generieren. Es ersetzt keinen Production-OLAP-Engine, aber entfernt die Reibung bei explorativer Analyse, während die echte Architektur Form annimmt.

FAQ

Kann ich mit ClickHouse anfangen und später zu Druid wechseln? Schwierig. Die Datenmodelle (denormalisiert vs. rollup-zentriert) unterscheiden sich grundlegend. Wenn du heute nicht weißt, dass du Druid brauchst, fang mit ClickHouse an und akzeptiere, dass ein Wechsel ein Re-Engineering ist.

Warum nicht einfach Snowflake oder BigQuery für Real-Time? Beide haben verbesserte Streaming-Ingestion (Snowpipe, BigQuery Streaming), aber die Sub-Second-Query-Latenz für Event-Daten ist nicht ihre Stärke. Für klassisches OLAP-Reporting top, für Operational-Analytics oft zu langsam/teuer.

Brauche ich Kafka oder reicht Kinesis/PubSub? Funktional vergleichbar. Kafka hat das stärkste Ökosystem (Connect, Streams, ksqlDB). Bei AWS-only oder GCP-only spart die Cloud-Variante Ops-Aufwand.

Was kostet ein Real-Time-Stack realistisch? Selbst-gehostete Variante (Kafka + Flink + ClickHouse) auf EKS/AKS: ab ~3.000 €/Monat Compute + Engineer-Zeit. Managed (Confluent + Materialize + ClickHouse Cloud): ab ~8.000 €/Monat ohne Ops-Aufwand.

DACH-Hosting für Streaming-Daten? Confluent Cloud und ClickHouse Cloud bieten EU-Regionen. Hetzner mit selbst-gehostetem Stack ist die preisgünstige Variante, braucht aber Ops.

Die Architektur, die wirklich gebaut wird

Lambda vs Kappa ist eine echte Engineering-Wahl, keine Marketing-Debatte. Lambda ist niedriger Risiko, wenn du ein bestehendes System erweiterst. Kappa ist sauberer für Neues. Und deine OLAP-Engine-Wahl zählt mehr, als die meisten Teams realisieren — wähle basierend auf Query-Patterns, nicht Benchmarks aus einer anderen Firma.

Definiere dein Latenz-SLA. Audite die Streaming-Skills deines Teams ehrlich. Wähle dann die einfachste Architektur, die die Anforderung erfüllt — nicht die, die im Design-Doc beeindruckendsten klingt.

Weiterlesen

• Streaming vs Batch Processing
• Event-Driven Data Architecture
• Data Observability erklärt

Stand: 14. Mai 2026.