Realtime-Analytics: Architektur mit Kafka & Co.

Kaltstart: Ein Morgen im War Room

Die Lampen sind an. Das Dashboard zittert. P95 springt von 1,8 auf 7,2 Sekunden. Drei Teams rufen: Zahlungen stauen, Betrugserkennung hinkt, Kampagnen verlieren Budget. Wir prüfen Lags, Themen, Partitionen. Ein Rebalance lief nachts. Zwei Consumer hängen. Ein Index baut noch. Das ist Alltag, wenn Daten in Sekunden zählen. Diese Seite zeigt, wie man so ein System baut, betreibt und ruhig schläft.

Was „Echtzeit“ hier wirklich meint

Echtzeit ist kein Wort für Magie. Es gibt Stufen. „Hard Realtime“ braucht Millisekunden und harte Garantien. Das ist selten in Analytics. Meist reichen „Nahe-Echtzeit“ Ziele: P95 unter 2–5 Sekunden. Wichtiger ist: stabil, vorhersehbar, und klar gemessen.

Unterscheide drei Dinge: Latenz vom Event bis in Kafka, Latenz durch Verarbeitung, Latenz beim Abfragen. Miss jede Stufe. Überlege auch „Freshness“ im UI: Wie alt sind die Daten, die der Nutzer sieht? Ein guter Start sind die Streaming-Analytics-Grundlagen von Google Cloud. Dort steht nüchtern, wo Strom-Modelle glänzen und wo Batch reicht.

Zielbild: ein einfacher Fluss, klar geschnitten

Das Zielbild sieht so aus: Event-Quellen senden in Topics. Apache Kafka trennt Last mit Partitionen und schützt Daten mit Replikation. Danach verarbeitet ein Stream-Tool (Flink, Kafka Streams, ksqlDB) die Events. Aggregierte Daten landen in einem schnellen OLAP-Store (Druid, Pinot, ClickHouse). Serving-Schicht liefert API und BI. Dazwischen: Schema Registry für saubere Verträge. CDC oder Outbox, um aus Datenbanken zuverlässig Events zu holen.

Denke früh an Idempotenz und Transaktionen. So vermeidest du Doppelzählung. Lies zur „Genau-einmal“-Semantik in Kafka den tiefen Hintergrund auf dem Confluent Blog: Exactly-once in der Praxis. Du wirst sehen: Es ist machbar, aber nicht gratis.

Kappa statt Lambda? Weniger Teile, weniger Schmerz

Lambda trennt Batch und Stream. Das klingt sicher, macht aber oft doppelte Logik, doppelten Betrieb, doppelten Schmerz. Kappa nutzt einen Fluss für beides. Historie kommt aus dem Log, Replays sind normal, Code ist einmal da. Für viele Teams ist Kappa der einfachere Weg.

Die Diskussion hat Jay Kreps sauber aufgeschrieben: Questioning the Lambda Architecture. Lies das. Prüfe dann ehrlich deine Needs. Wenn du nicht strikte Backfills mit großem Batch brauchst, nimm Kappa.

Stores & Engines für Realtime-Serving: schnelle Übersicht

Kein Store kann alles. Du musst wählen: Latenz, Kosten, Upserts, Joins, SQL-Tiefe. Ein paar Systeme dominieren. Die Docs geben ein gutes Gefühl für Grenzen und Stärken, z. B. Apache Druid – Überblick.

Apache Druid	~0,5–2 s	~50–300 ms	Self-Hosted / Cloud	Roll-ups, Streaming+Batch, Approx	Komplexe Ops, Handoffs	Dashboards, Zeitreihen, AdTech
Apache Pinot	~0,2–1 s	~30–200 ms	Self-Hosted / Cloud	Realtime OLAP, StarTree, Upserts	Segment-Tuning, Index-Kosten	Produkt-Analytics, Feed-Ranking
ClickHouse	~0,5–3 s	~10 ms – 1 s	Self-Hosted / SaaS	MergeTree, MVs, Preis/Leistung	Upserts tricky, Skew/Hotspots	Breite Ad-hoc-Analysen, Logs
Elasticsearch	~1–5 s	~100 ms – 1 s	Self-Hosted / Cloud	Suche + Aggregationen	Reindex teuer, Heap-Tuning	Text+Metrik Mix, Observability
Rockset	~1–3 s	~50–500 ms	Managed (GB+Compute)	Converged Indexing, SQL	Kosten bei hohem Strom	Schnelle Prototypen, APIs
BigQuery (Streaming)	~1–10 s	~0,5–5 s	Pay per Scan / Slot	Einfach, serverlos	„Schwänze“, Kosten je Scan	Self-Service BI, wenig Ops

Mehr Tiefe zu den Engines: Apache Pinot – Realtime OLAP, ClickHouse Docs, Elasticsearch Guide, Rockset Blog, BigQuery Streaming. Werte sind Richtwerte. Deine Datenverteilung, Indexe und Joins können das stark ändern.

Dinge, die wir bewusst nicht bauen

Wir bauen keine Event-Schlange, wenn ein stündlicher Report reicht. Wir schalten Kafka nicht vor jede App, nur weil „Future Proof“ gut klingt. Wir fügen keine zweite Engine hinzu, wenn eine Engine + gutes Schema das Ziel trifft. Weniger Teile sind oft mehr Stabilität.

Die besten Basics zu Daten-Systemen erklärt Martin Kleppmann in Designing Data-Intensive Applications. Lies das Kapitel zu Logs, Replikation, Konsistenz. Danach entscheidest du nüchtern, was du wirklich brauchst.

Daten reinholen: CDC, Outbox, Schemas

Stabile Streams brauchen saubere Quelle. Für Datenbanken ist CDC Gold. Debezium liest den Binlog, wandelt in Events, sendet nach Kafka. Das ist robuster als Polling. Für App-Services ist Outbox Pattern klar: zuerst in Outbox schreiben, dann atomar publizieren.

Für Schemas nimm Avro oder Protobuf. Ein Schema Registry speichert Versionen. Ein Consumer weiß, was er liest. So geht Evolution ohne Brüche. Pflichtlektüre: Confluent Schema Registry – Konzepte.

Stream-Verarbeitung: Flink vs Kafka Streams vs ksqlDB

Du hast drei Klassiker. Kafka Streams: Library im Service, leicht zu deployen, gut für kleinere, fokussierte Topologien. ksqlDB: SQL-first, schnell für Filter, Enrichment, einfache Windows. Flink: mächtig für State, komplexe Joins, CEP, genaues Event Time Handling.

Event Time und Watermarks sind Kern. Ohne sie schiebst du Latenz hoch oder verlierst Events. Grundlagen stehen klar in Apache Flink – Time & Watermarks.

Für kleine, eingebettete Topologien ist die Kafka Streams Doku top. Du hast ein einfaches Deploy, keine extra Cluster, aber weniger Spielraum bei sehr großem State.

Betrieb: Backpressure, Rebalancing, Offsets, KRaft

Backpressure ist normal. Messe Lags pro Partition. Grenze durchsatzstarke Verbraucher ein. Nutze Quotas. Trenne Hot-Keys mit passendem Partition Key. Plane Rebalancing: Heartbeats, Session Timeouts, Sticky Assignor. Prüfe Commits und Idempotenz. Nutze Dead Letter Queues für Gifts.

Plane den Umstieg auf KRaft (Kafka ohne ZooKeeper). Das macht Betrieb einfacher, weniger Moving Parts, bessere Stabilität. Details in der Kafka KRaft Doku.

Lerne von großen Teams. Uber teilt oft harte Lessons zu Stream-Systemen, Metriken, Kosten und Zuverlässigkeit. Ein Einstieg ist der Uber Engineering Blog. Solche Postmorten helfen, eigene Lücken zu sehen, bevor sie dich treffen.

Monitoring & Kosten: sehen, steuern, senken

Metriken sind dein Frühwarnsystem. Exportiere Producer/Consumer-Lags, Bytes in/out, Request-Latenzen, GC, Flush-Zeiten, Segment-Größen. Baue Alerts auf Trend, nicht nur auf Peaks. Nutze Prometheus für Metriken. Gestalte Dashboards mit Sinn. Grafana Best Practices helfen bei Layout und Fokus. Für Traces und Logs nutze OpenTelemetry End-to-End.

Kosten kommen oft leise. Speicher wächst durch lange Retention und viele Indexe. Netzwerk kostet bei Egress. CPU steigt durch schlechte Keys und viele kleine Messages. Taktik: größere Batches, Kompression, saubere Partitionen, kalte Daten raus, Query-Patterns prüfen, Materialized Views nur dort, wo sie sparen.

Sicherheit & Recht: PII, DSGVO, Maskierung

Baue Schutz in jede Schicht. Pseudonymisiere früh. Hash statt Klarnamen. Trenne Rollen: Wer darf Rohdaten? Wer sieht nur Aggregate? Setze Retention für PII kurz. Schreibe ein Data Map. Richte einen Löschpfad ein.

Starte bei der Quelle: DSGVO erklärt Grundsätze klar, siehe EU-DSGVO. Für App-Risiken hilft die OWASP Top 10. Denke an Transportverschlüsselung, ACLs, Secret-Handling, Rotation, Audit-Logs.

Anwendungsfälle, die Echtzeit wirklich brauchen

• Betrugserkennung: Regeln + ML auf Session- und Zahl-Events. Ziel: P95 < 2 s vor Autorisierung.
• Dynamic Pricing: Klick- und Bestand-Events, Fenster von 30–60 s, sanfte Updates.
• IoT Telemetrie: Millionen Sensoren, Korrelation, Alarmierung < 5 s.
• AdTech: Kampagnensteuerung, Frequenz-Caps, Budget-Guard in Sekunden.

iGaming-Beispiel, transparent: In Affiliate-Analytics zählen Sekunden bei Risk-Checks und Live-Performance. Hier passt ein Strom wie folgt: Session-Events → Kafka → Flink (CEP für Muster) → Feature-Store → Pinot/ClickHouse → Echtzeit-Risiko und Live-Reporting. In so einem Kontext kann eine kuratierte Liste externer Plattformen helfen, Traffic-Qualität und Partner zu bewerten. Hinweis: Partnerlink – Online-Casino-Rankings. Wir verlinken als Beispiel für ein Review-Portal; keine Empfehlung zum Spielen. Fokus bleibt Technik: Events sauber, Latenz stabil, Transparenz hoch.

Mini-Postmortem: Das eine Mal, als P95 explodierte

Was passierte: Ein Flink-Job bekam eine neue Join-Bedingung. Der Key war kaum verteilt. Zwei Partitionen wurden heiß. Lag stieg, Rebalance traf zur vollen Stunde, dann Backlog. Was half: Hot-Key-Splitting, breiterer Partition Key (UserId + Hash), Async I/O für das Enrichment, State TTL enger. Ergebnis: P95 zurück auf 1,9 s, P99 auf 3,8 s. Lehre: Teste Keys mit echten Verteilungen. Setze Guardrails für Lags und für parallelism.

Checkliste & kleiner Entscheidungsbaum

• Ziel-Latenz klar? P95 unter 2 s oder reichen 5 s?
• Durchsatz bekannt? Events/s, Größe/Message, Peaks.
• Windowing nötig? Tumbling, Sliding, Session?
• Upserts/Deletes gebraucht? Ja → Pinot/CH prüfen.
• Ad-hoc-SQL wichtig? Ja → ClickHouse/Druid.
• Striktes Exactly-Once? → Kafka Transaktionen + Flink.
• Ops-Kapazität gering? → Managed Optionen erwägen.
• PII an Bord? → Pseudonymisieren + kurze Retention.

Baum in kurz: Wenn P95 < 2 s und viel Ad-hoc → ClickHouse oder Pinot. Wenn Approx reicht und Roll-ups gut sind → Druid. Wenn Serverless und wenig Ops, aber höhere Latenz ok → BigQuery Streaming. Für Streams mit starkem State und CEP → Flink; für leichte Pipes → Kafka Streams/ksqlDB.

FAQ

Brauche ich wirklich „Echtzeit“?

Wenn ein täglicher Job reicht, nimm Batch. Echtzeit lohnt sich, wenn Entscheidungen in Minuten oder Sekunden Geld sparen oder Verluste stoppen.

Wie teuer sind Realtime-Joins?

Teuer, wenn Keys schlecht verteilt sind und der State groß wird. Plane Keys, setze TTL, nutze Pre-Aggregate. Prüfe Bloom- oder Sketch-Strukturen.

Was ist mit Schemamigrationen?

Ändere scheibenweise. Nutze Schema Registry. Füge Felder hinzu, bevor du sie nutzt. Entferne spät. Teste Abwärtskompatibilität.

Wie behalte ich Kontrolle bei Rebalances?

Nutze Sticky Assignor, setze Timeouts passend, begrenze parallelism bei Deploys, miete Wartungsfenster.

Schluss: Trade-offs, mit denen du leben wirst

Echtzeit zahlt mit Komplexität, Betrieb und Geld. Du gewinnst Zeit-zu-Insight, Schutz vor Schaden, bessere Nutzer-Erfahrung. Ziele nüchtern setzen, messen, vereinfachen, wo es geht. Jag nicht jeder Sekunde nach. Ein stabiles P95 von 3–5 s schlägt ein wackliges 1 s Ziel fast immer.

Kurzleitfaden: Architektur auf einen Blick

• Ingest: CDC via Debezium oder Outbox → Kafka Topics (Partitionen planen, Keys prüfen).
• Processing: Flink für große State/CEP; Kafka Streams/ksqlDB für einfache Flows.
• Serving: Pinot/Druid/ClickHouse je nach Query-Muster und Upserts.
• Ops: Monitoring mit Prometheus + Grafana; Tracing via OpenTelemetry.
• Governance: Schema Registry, PII-Policy, DSGVO-konforme Retention.

Autor: Lea Krüger, Data Architect (8+ Jahre Streaming & OLAP). Bau von Kafka- und Flink-Stacks für E-Com, FinTech, AdTech. Speaker bei lokalen Meetups. GitHub/LinkedIn auf Anfrage.

Veröffentlichung: 2026-05-22 · Zuletzt aktualisiert: 2026-05-22

Transparenz: Der Link zu den Online-Casino-Rankings ist ein Partnerlink (rel="sponsored"). Keine Aufforderung zum Spielen. Inhalt bleibt technisch und sachlich.

Weiterführende Quellen (kuratiert)

• Streaming-Analytics-Grundlagen
• Apache Kafka – Dokumentation
• Exactly-Once in Kafka
• Kappa vs. Lambda
• Apache Druid · Apache Pinot · ClickHouse
• Elasticsearch Guide · Rockset Blog · BigQuery Streaming
• Designing Data-Intensive Applications
• Debezium – CDC · Schema Registry
• Flink – Event Time · Kafka Streams
• Kafka KRaft · Uber Engineering
• Prometheus · Grafana Blog · OpenTelemetry
• EU-DSGVO · OWASP Top 10