Echtzeit-Analysen

1) Zweck und Geschäftswert

• AML/Anti-Fraud: Strukturierung von Einlagen, Velocity-Attacken, Risiko-Transaktionen.
• Responsible Gaming (RG): Überschreitung von Limits, Risikomuster, Selbstausschluss.
• SRE/Operations: Früherkennung von SLA-Degradationen, Fehlerspitzen, Cluster-Überhitzung.
• Produkt und Marketing: Personalisierungsauslöser, Missionen/Quests, Echtzeit-Segmentierung.
• Betriebsberichterstattung: Near-Real-Time GGR/NGR, Hallen/Anbieter Dashboards.

Zielvorgaben: p95 Ende-zu-Ende 0. 5–5 с, completeness ≥ 99. 5%, Verfügbarkeit ≥ 99. 9%.

2) Referenzarchitektur

1. Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector; Validierung von Schemata, Anti-Double, Geo-Routing.
2. Der Ereignisbus ist Kafka/Redpanda (Partitionierung nach 'user _ id/tenant/market', DLQ, retention 3-7 Tage).
3. Stream-Verarbeitung - Flink/Spark Structured Streaming/Beam: stateful-operators, CEP, watermarks, allowed lateness, dedup.
4. Online-Anreicherung - Redis/Scylla/ClickHouse Lookups (RG-Limits, KYC, BIN→MCC, IP→Geo/ASN), asynchrone Aufrufe mit Timeouts und Fallback.
5. Serving - ClickHouse/Pinot/Druid (operative Schaufenster 1-5 Minuten), Feature Store (Online-Zeichen), Webhooks/Ticketing/SOAR.
6. Lakehouse - Bronze/Silber/Gold für langfristige Konsolidierung, Replika und Sweets.
7. Beobachtbarkeit - Pipeline-Metriken, Tracing (OTel), Protokolle, Lineage und Cost-Dashboards.

3) Signale und Taxonomie

Zahlungen: 'Zahlung. deposit/withdraw/chargeback`.
Spiel: 'Spiel. bet/payout', Sitzungen.
Authentifizierung und Verhalten: 'auth. login/failure`, device-switch, velocity.
Operativ: Latenz, Fehlerrate, Neustart der Pods, Sättigung.
Compliance: Sanktionsscreening, RG-Flags, DSAR-Events.

Jeder Typ hat einen Eigentümer (Domain Owner), ein Schema, ein Frische-SLO und eine Late-Data-Richtlinie.

4) Fenster, Wasserzeichen und Spätdaten

Fenster: tumbling (fix.) , hopping (Überlappung), session (durch Inaktivität).
Wasserzeichen: die Grenze von „Wissen über die Zeit“ (in der Regel 2-5 min).
Verspätete Ereignisse: Voremissionen von Anpassungen, Flag 'late = true', DLQ bei starker Verspätung.

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) CEP und stateful-Aggregationen

Schlüsselwort: 'user _ id', 'device _ id', 'payment. account_id`.
Zustand: gleitende Zähler/Summen, Bloom-Filter für Deduplex, TTL.
CEP-Muster: structuring (<Schwelle, ≥N mal, pro Fenster T), device-switch, RG-fatigue.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6) Exactly-Once, Ordnung und Idempotenz

At-least-once Lieferung im Bus + dedup durch 'event _ id' bei der Bearbeitung (TTL 24-72 h).
Reihenfolge: Partitionierung nach Schlüssel (lokale Reihenfolge garantiert).
Sink: Transaktionskommits (2-Phase) oder idempotent upsert/merge.
Outbox/Inbox: Transaktionale Veröffentlichung von Domänenereignissen aus OLTP.

7) Online-Anreicherung und Feature Store

Lookup: RG-Limits, KYC-Status, BIN→MCC, IP→Geo/ASN, Märkte/Steuern, FX zum Zeitpunkt des Ereignisses.
Asynchrone Aufrufe: sanktionierte/RER APIs mit Timeouts; wenn der Fehler 'unknown' + retray/cache ist.
Feature Store: Online-/Offline-Verhandlung; eine Transformationscodebasis.

8) Echtzeit-Schaufenster und Serving

ClickHouse/Pinot/Druid: Sekunden-/Minutenaggregate, materialisierte Ansichten, SLA für eine Verzögerung von 1-5 min.
API/GraphQL: geringe Latenz für Dashboards/Widgets.
Alertas: Webhooks/Jira/SOAR mit angereichertem Kontext (trace_id, letzte Ereignisse).

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) Metriken, SLI/SLO und Dashboards

• p95 ingest→alert ≤ 2 s (kritische Regeln), ≤ 5 s (andere).
• Die Vollständigkeit des Fensters T ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Verfügbarkeit des Streamingdienstes ≥ 99. 9%; late-ratio ≤ 1%.

• Lag nach Parti/Topic; busy time Operatoren; Zustandsgröße.
• Trichter „sobytiye→pravilo→keys“, Precision/Recall für Domains.
• Late/completeness Wärmekarte; Karte der „heißen“ Schlüssel.

10) Streaming DQ (Qualität)

Ingest-Validierungen: schema/enums/size-limits, anti-takes.
Am Stream: completeness/dup-rate/late-ratio, Korrektheit der Fenster (ohne Doppelzählung).
Reaktionsrichtlinien: kritisch → DLQ + pager; major/minor → tagging + report.

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

11) Privatsphäre, Sicherheit und Wohnsitz

PII-Minimierung: Pseudonymisierung der ID, Maskierung empfindlicher Felder, Tokenisierung der PAN/IBAN.
Datenresidenz: regionale Pipelines (EEA/UK/BR), separate KMS-Schlüssel.
DSAR/RTBF: selektive Bearbeitung in Downstream-Vitrinen; Legal Hold für Fälle/Berichte.
Audit: Unveränderliche Protokolle von Zugriffen/Regeländerungen, Protokollierung von Releases.

12) Wirtschaft und Produktivität

Sharding/Schlüssel: Vermeiden Sie „heiße“ Schlüssel (Salting/Composite), Partienausgleich.
Zustand: TTL, compact snapshots, tuning RocksDB/state backend.
Voraggregationen: Reduzieren Sie in der Anfangsphase für laute Themen.
Sampling: nur für unkritische Metriken (keine Transaktionen/Compliance).
Chargeback: Themen-/Jobbudgets, Replay-Quoten und Heavy Requests.

13) Prozesse und RACI

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

14) Fahrplan für die Umsetzung

1. Kafka/Redpanda + 2 kritische Topics (z.B. 'payments', 'auth').

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

3. Operative Schaufenster in ClickHouse/Pinot (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, canary/A-B, DQ streamen.
• Regionalisierung von Pipelines, DSAR/RTBF-Verfahren, Legal Hold für Fälle.

• Multi-Region aktiv-aktiv, Simulator „replay & what-if“, automatische Kalibrierung von Schwellen.
• Gold-Stream-Vitrinen (GGR/RG/AML), Near-Real-Time-Reporting.
• Kosten-Dashboards, Chargeback, DR-Übungen.

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

16) Checkliste vor dem Verkauf

• Schemes/contracts in Registry, back-compat tests sind grün.
• Wasserzeichen/zulässige Latenz, Dedup und DLQ enthalten.
• SLO und Alerts sind konfiguriert (lag/late/dup/state size).
• Anreicherung mit Caches und Timeouts; fallback «unknown».
• RBAC/Dual-Control auf Regeln/Modelle; Änderungsprotokoll aktiviert.
• Dokumentation der Vorschriften/Schaukästen; runbook 'und Replay/Rollback.

17) Häufige Fehler und wie man sie vermeidet

Event-Zeit ignorieren: Ohne Wasserzeichen „schwimmen“ die Metriken.
Kein Deduplex: falsche Alerts, doppelte Buchführung.
Hot Keys: Verzerrung der Parteien → Salting/Resharding.
Synchrone externe APIs im Hot-Path: nur async + Cache.
Nicht verwaltete Kosten: Voraggregationen, TTL-Status, Quoten, Kostenüberwachung.
Kein Simulator: Rollouts ohne „replay“ → Regression.

18) Ergebnis

Echtzeit-Analytics ist keine „schnelle BI“, sondern eine geführte Schleife mit Verträgen, stateful-Logik, KEP, Wasserzeichen, Online-Anreicherung und strengen SLOs. Durch die Befolgung dieser Praktiken erhält die Plattform innerhalb von Sekunden genaue Signale und Entscheidungen und unterstützt Compliance, Produktszenarien und betriebliche Nachhaltigkeit zu kontrollierten Kosten.