Streaming und Streaming Analytics

1) Zweck und Wert

• Anti-Fraud/AML: Identifizierung der Strukturierung von Einlagen, Velocity-Attacken, Anomalien der Anbieter.
• Responsible Gaming (RG): Überschreitung von Limits, Risikomuster, Selbstausschlüsse.
• Operationen/SRE: SLA-Degradation, Fehlerspitzen, frühe Incident-Signale.
• Produkt/Marketing: Personalisierungsereignisse, Missionen/Quests, Echtzeit-Segmentierung.
• Near-Real-Time Reporting: GGR/NGR Schaufenster, Bedienfelder.

Zielmerkmale: p95 Ende-zu-Ende 0. 5-5 s, Vollständigkeit ≥ 99. 5%, überschaubare Kosten.

2) Referenzarchitektur

1. Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Validierung von Schemata, Anti-Duplikate, Geo-Routing.

2. Ereignisbus

Kafka/Redpanda (Partitionierung nach „user _ id/tenant/market“).
Retention 3-7 Tage, Kompression, DLQ/„ Quarantäne “für„ gebrochene “Nachrichten.

3. Streaming-Verarbeitung

Flink / Spark Structured Streaming / Beam.
Stateful-Operatoren, CEP, Wasserzeichen, zulässige Latenz, Deduplizierung.
Anreicherung (Redis/Scylla/ClickHouse-Lookup), asynchrone I/O mit Timeouts.

4. Serving/Einsatzvitrinen

ClickHouse/Pinot/Druid für Minuten-/Sekundenaggregation und Dashboards.
Feature Store (online) für das Scoring von Modellen.
Alert-Topics → SOAR/Ticketing/Webhooks.

5. Langzeitlagerung (Lakehouse)

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Replika/Backtests, Zeitreisen.

6. Beobachtungsstand

Pipline-Metriken, Tracing (OTel), Protokolle, Lineage.

3) Systeme und Verträge

Schema-first: JSON/Avro/Protobuf + Registry, 'schema _ version' in jedem Event.
Evolution: rückwärtskompatibel - neue nullbare Felder; breaking - '/v2'+ Doppelveröffentlichung.
Erforderliche Felder: 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id`, `market`, `source`.

4) Fenster, Wasserzeichen und verspätete Daten

• Tumbling (fest), Hopping (überlappend), Session (durch Inaktivität).
• Wasserzeichen: Schwelle des „Wissens“ nach Ereigniszeit; zum Beispiel 2-5 Minuten.
• Späte Daten: Voremission von Anpassungen, „late = true“, DLQ bei starkem Rückstand.

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);

5) Stateful-Aggregationen und KEP

Schlüsselwort: 'user _ id', 'device _ id', 'payment. account_id`.
Status: gleitende Summen/Zähler, Sitzungen, Bloom-Filter für Deduplex.
CEP-Muster: Strukturierung (<Schwelle, ≥N Mal, pro T-Fenster), Device-Switch, RG-Fatigue.

python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

6) Exactly-Once, Ordnung und Idempotenz

Bus: at-least-once + Partitionierungsschlüssel sorgen für lokale Ordnung.
Idempotenz: 'event _ id' + dedup state (TTL 24-72 h).
Sink: Transaktionskommits (2-Phase) oder Upsert/Merge-Idempotenz.
Outbox/Inbox: Garantierte Veröffentlichung von Domain-Events aus OLTP.

7) Anreicherung in Echtzeit

Lookup: Redis/Scylla (RG-Limits, KYC-Status, BIN→MCC, IP→Geo/ASN).
Asynchrone Aufrufe: sanktionierte/RER APIs mit Timeouts und Fallback („unknown“).
FX/Zeitzone: Normalisierung der Beträge und lokale Marktzeiten („fx _ source“, „tz“).

8) Serving und Echtzeit-Schaufenster

ClickHouse/Pinot/Druid: Aggregationen nach Minute/Sekunde, materialisierte Ansichten.
Gold-Stream: GGR/RG/AML Operationstabellen, SLA für Latenz ≤ 1-5 min.
API/GraphQL: geringe Latenz für Dashboards und externe Integrationen.

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream.game_events
GROUP BY ts_min, market, provider_id;

9) Beobachtbarkeit und SLO

• p95 ingest→alert ≤ 2 s (kritisch) ≤ 5 s (Rest).
• Die Vollständigkeit des Fensters T ≥ 99. 5%.
• Schaltungsfehler ≤ 0. 1%; Der Anteil der Ereignisse mit 'trace _ id' ≥ 98%.
• Verfügbarkeit des Streamingdienstes ≥ 99. 9%.

• Lags durch Parteien/Spitzen, busy Zeit der Betreiber, die Größe des Zustandes.
• Trichter „sobytiye→pravilo→keys“, Karte der „heißen“ Schlüssel, late-ratio.
• Kosten: Kosten/GB, Kosten/Abfrage, Kosten für Checkpoints/Replikate.

10) Datenschutz und Compliance

PII-Minimierung: ID-Pseudonymisierung, Feldmaskierung, PAN/IBAN-Tokenisierung.
Datenresidenz: regionale Pipelines (EEA/UK/BR), separate Verschlüsselungsschlüssel.
Legal Operations: DSAR/RTBF auf Downstream-Schaufenstern, Legal Hold für Fälle/Berichte.
Audit: Zugriffsprotokolle, unveränderliche Entscheidungsarchive.

11) Wirtschaft und Produktivität

Schlüssel und Sharding: Vermeiden Sie „heiße“ Schlüssel (Salting/Composite Key).
Zustand: vernünftige TTLs, Schnappschüsse, RocksDB/State Backend Tuning.
Voraggregation: Up-Front-Reduce für laute Ströme.
Sampling: auf unkritischen Metriken zulässig (nicht auf Transaktionen/Compliance).
Chargeback: Budgets für Themen/Jobs, Quoten und Allokation nach Team.

12) Streaming DQ (Qualität)

Ingest-Validierung (schema, enums, size), dedup'(event_id, source)'.
Am Stream: completeness/dup-rate/late-ratio, Fenstersteuerung (keine Doppelzählung).
Reaktionsrichtlinien: kritisch → DLQ + alert; major/minor → Tag und anschließende Reinigung.

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

13) Zugangssicherheit und Freigabekontrolle

RBAC/ABAC: separate Rollen zum Lesen von Threads, Ändern von Regeln/Modellen.
Dual Control: Ausrollen von Regeln und Modellen über „2 Schlüssel“.
Canary/A/B: Dunkle Regel- und Modellläufe, Precision/Recall-Steuerung.
Geheimnisse: KMS/CMK, regelmäßige Rotation, Verbot von Geheimnissen in Protokollen.

14) Prozesse und RACI

R (Responsible): Streaming Platform (infra/releases), Domain Analytics (rules/fici), MLOps (scoring).
A (Accountable): Head of Data/Risk/Compliance für Domains.
C (konsultiert): DPO/Legal (PII/retention), SRE (SLO/incidents), Architektur.
I (Informed): Produkt, Unterstützung, Marketing, Finanzen.

15) Fahrplan für die Umsetzung

1. Kafka/Redpanda + zwei kritische Topics ('payments', 'auth').

2. Flink-Joba mit Wasserzeichen, Deduplizierung und einer CEP-Regel (AML oder RG).

3. ClickHouse/Pinot Schaufenster 1-5 min, Dashboards lag/completeness.

4. Incident Channel (Webhooks/Jira), Basis-SLOs und Alerts.

• Online-Anreicherung (Redis/Scylla), Feature Store, asynchrone Lookups.
• Regeln als Code verwalten, kanarische Freigaben, A/B
• DQ-Streaming, Regionalisierung von Pipelines, DSAR/RTBF-Verfahren.

• Multi-Region aktiv-aktiv, Replay-Simulator „what-if“, Autokalibrierung von Schwellen.
• Komplette Gold-Stream-Vitrinen (GGR/RG/AML), Near-Real-Time Reporting.
• Value Dashboards, Chargeback, DR-Übungen.

16) Beispiele (Fragmente)

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT() AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

17) Checkliste vor dem Verkauf

• Schemes and contracts in Registry, back-compat tests green.
• Wasserzeichen/zulässige Latenz, Dedup und DLQ enthalten.
• SLO und Alerts sind konfiguriert (lag/late/dup/state size).
• Anreicherung mit Caches und Timeouts, Fallback „unbekannt“.
• RBAC/dual-control auf Regeln/Modellen, alle Änderungen werden protokolliert.
• Dokumentation von Regeln, Vitrinen und Runbook 'und Replay/Rollback.

18) Häufige Fehler und wie man sie vermeidet

Event-Zeit ignorieren: Ohne Wasserzeichen „schwimmen“ die Metriken.
Kein Deduplex: falsche Alerts und doppelte Buchführung.
Hot Keys: Verzerrung der Parteien → Salting/Resharding.
Synchrone externe APIs im Hot-Path: nur async + Cache.
Unüberschaubare Kosten: Voraggregationen, TTL-Zustände, Quoten, Kosten-Dashboards.
Kein Simulator: Rollouts ohne „replay“ führen zu Regressionen.

19) Glossar (kurz)

CEP - Complex Event Processing (Ereignismuster).
Watermark ist die Grenze der Ereigniszeit-Fensterbereitschaft.
Allowed Lateness - Zulassung von verspäteten Ereignissen.
Stateful Operator ist ein Operator mit einem gespeicherten Status.
Feature Store - Konsistentes Feature-Serving (online/offline).

20) Das Ergebnis

Streaming und Streaming Analytics sind ein überschaubares System: Verträge, Fenster und Wasserzeichen, stateful-Logik und KEP, Anreicherung und Echtzeit-Schaufenster, SLO und Beobachtbarkeit, Privatsphäre und Kosten unter Kontrolle. Nach den beschriebenen Praktiken erhält die Plattform zuverlässige Risikodetektoren, Bedienpanels und Personalisierung mit vorhersehbarer Latenz und Kosten.