Stream vs Batch-Analyse
1) Kurze Zusammenfassung
Stream - kontinuierliche Verarbeitung von Ereignissen in Sekunden: Anti-Fraud/AML, RG-Trigger, SLA-Alerts, Live-Panels.
Batch - periodische Neuberechnung mit voller Reproduzierbarkeit: regulatorisches Reporting (GGR/NGR), Finswerke, ML-Datasets.
Richtlinien: Stream p95 e2e 0. 5-5 s, Batch D + 1 bis 06:00 Uhr (lok.) .
2) Auswahlmatrix (TL; DR)
80/20-Regel: alles, was keine Reaktion <5 Minuten erfordert - in Batch; der Rest ist in Stream, mit Batch Nachtvalidierung.
3) Architekturen
3. 1 Lambda
Stream für Online + Batch für Konsolidierung. Plus: Flexibilität. Der Nachteil: zwei Logiken.
3. 2 Kappa
Alles ist wie Ströme; Batch = „Replay“ über das Log. Plus: ein einziger Code. Nachteil: Komplexität der Repliken/Kosten.
3. 3 Lakehouse-Hybrid (empfohlen)
Stream → Online-OLAP-März (Minuten) und Bronze/Silber; Batch baut Gold (D + 1) neu zusammen und veröffentlicht Berichte.
4) Daten und Zeit
Stream
Fenster: tumbling/hopping/session.
Wasserzeichen: 2-5 min; late data ist markiert und wird nachgemeldet.
Stateful: CEP, dedup, TTL.
Batch
Inkremente/CDC: 'updated _ at', Logreplikation.
SCD I/II/III: Historie der Attribute.
Schnappschüsse: Tag-/Monatsschichten für „as-of“.
5) Anwendungsmuster in iGaming
AML/Anti-Fraud: Stream (velocity/Strukturierung) + Batch Abstimmungen und Fälle.
Responsible Gaming: Stream-Kontrolle von Limits/Selbstausschlüssen; Batch Berichtsregister.
Operationen/SRE: Stream alert SLA; Batch Post-Analyse von Vorfällen und Trends.
Produkt/Marketing: Stream Personalisierung/Missionen; Batch Kohorten/LTV.
Finanzen/Berichte: Batch (Gold D + 1, WORM-Pakete), Stream - operative Panels.
6) DQ, Reproduzierbarkeit, Replikation
Stream DQ: Validierung von Schemata, Dedup'(event_id, Quelle)', completeness Fenster, late-ratio, dup-rate; Kritische DLQ- →.
Batch DQ: Unique/FK/range/temporal, Abgleich mit OLTP/Providern; kritische → fail job + Bericht.
- Stream: Replikate von Topics durch Bereich + deterministische Transformation.
- Batch: time-travel/logic Versionen ('logic _ version') + Gold Snapshots.
7) Privatsphäre und Wohnsitz
Stream: Pseudonymisierung, Online-Masking, regionale Pipelines (EEA/UK/BR), Timeouts zu externen PII-Lookups.
Batch: Isolierung von PII-Muppings, RLS/CLS, DSAR/RTBF, Legal Hold, WORM-Archiven.
8) Kosten-Engineering
Stream: Vermeiden Sie „heiße“ Schlüssel (Salting), beschränken Sie async lookups, TTL-Status, Voraggregation.
Batch: Partitionierung/Clustering, Kompression kleiner Dateien, Materialisierung stabiler Aggregate, Kontingente/Startfenster.
9) Beispiele
9. 1 Stream - Flink SQL (10 min velocity Einzahlungen)
sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream. payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);9. 2 Stream - CEP (AML Pseudocode)
python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())9. 3 Batch - MERGE (Silberinkrement)
sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;9. 4 Batch — Gold GGR (D+1)
sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;10) Metriken und SLO
Stream (Orientierungspunkte)
p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99. 5%
schema-errors ≤ 0. 1%
late-ratio ≤ 1%
Verfügbarkeit ≥ 99. 9%
Batch (Benchmarks)
Gold. täglich fertig bis 06:00 Uhr lok.
completeness ≥ 99. 5%
validity ≥ 99. 9%
MTTR DQ-Vorfall ≤ 24-48 Stunden
11) Tests und Freigaben
Verträge/Regelungen: verbraucherorientierte Tests; back-compat CI.
Stream: Kanarienregeln, Dark Launch, Replay-Simulator.
Batch: Dry-Run auf Samples, Vergleich von Metriken, Checksummierung (Reconciliation).
12) Anti-Muster
Logik duplizieren: Verschiedene Berechnungen von Stream und Batch, ohne die Formeln auszurichten.
Synchrone externe APIs im Stream-Hot-Path ohne Cache/Timeouts.
Volle Reload „nur für den Fall“ statt Inkremente.
Fehlende Wasserzeichen/Late-Politik.
PII in analytischen Schichten; keine CLS/RLS.
Goldvitrinen, die im Nachhinein „mutieren“.
13) Empfohlener Hybrid (Playbook)
1. Stream-Schaltung: ingest → Reifen → Flink/Beam (Wasserzeichen, Dedup, CEP) →
OLAP (ClickHouse/Pinot) für 1-5 min Platten + Bronze/Silber (append).
2. Batch-Schaltung: Inkremente/CDC → Silber Normalisierung/SCD → Gold Tagesschau/Berichte (WORM).
3. Ausrichtung: eine einzige semantische Schicht von Metriken; nightly Abgleich der Stream↔Batch; Abweichungen> Schwelle → Tickets.
14) RACI
R (Responsible): Streaming Platform (Stream-infra), Data Engineering (Batch-Modelle), Domain Analytics (Metriken/Regeln), MLOps (Fichi/Feature Store).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Produkt/Marketing/Operations.
15) Fahrplan
MVP (2-4 Wochen):1. Kafka/Redpanda + 2 kritische Topics ('payments', 'auth').
2. Flink-Joba: Wasserzeichen + Dedup + 1 CEP-Regel (AML oder RG).
3. OLAP-Showcase 1-5 min + Dashboards lag/late/dup.
4. Lakehouse Silver (ACID), das erste Gold. ggr_daily (D + 1 bis 06:00 Uhr)
Phase 2 (4-8 Wochen):- Inkremente/CDC nach Domäne, SCD II, semantische Metrikschicht.
- DQ-Streaming und nightly Stream↔Batch-Abstimmungen.
- Regionalisierung (EWR/UK/BR), DSAR/RTBF, Legal Hold.
- Replay-Simulator, kanarische/A-B Regelfreigaben/Metriken.
- Kosten-Dashboards und Quoten; tiered storage; DR-Übungen.
- Automatische Generierung der Vitrinen-/Metrik- und Lineage-Dokumentation.
16) Checkliste Umsetzung
- Systeme/Verträge im Register; Back-Compat-Tests sind grün.
- Stream: watermarks/allowed-lateness, дедуп, DLQ; OLAP-Panels im Angebot.
- Batch: increments/CDC, SCD II, Gold D + 1 mit WORM-Exporten.
- Eine einzige semantische Schicht von Metriken; nightly Vergleich der Stream↔Batch.
- DQ-Dashboards von Freshness/Completeness/Validity; lag/late/dup alerts.
- RBAC/ABAC, Verschlüsselung, Wohnsitz; DSAR/RTBF/Legal Hold.
- Kosten unter Kontrolle (Kosten/GB, Kosten/Abfrage, staatliche Größe, Quotenreplikationen).
17) Das Ergebnis
Stream und Batch sind keine Konkurrenten, sondern zwei Zahnräder desselben Antriebs. Stream gibt eine „Hier und Jetzt“ -Reaktion, Batch eine überprüfbare Wahrheit „für den Morgen“. Der Lakehouse-Hybrid-Ansatz, die Single-Layer-Metriken und die Disziplin DQ/Lineage ermöglichen den Aufbau schneller, reproduzierbarer und konsistenter Analysekreise, die in Bezug auf SLA und Kosten optimal sind.