Datenseen und Flow Aggregation

1) Zweck und Wert

• Streams aus Produkten/Spielen/Zahlungen landen „as is“ bei Bronze.
• Silber normalisiert und bereichert, indem es konsistente Schlüssel und Qualität liefert.
• Gold - aggregierte Vitrinen (inkl. Real-/Near-Real-Time) für BI, Regulator, Anti-Fraud/RG.

Die Aggregation der Streams auf Lakehouse ergibt: geringe Latenz der Berichte, vorhersehbare Kosten, Reproduzierbarkeit und Forensik.

2) Referenzarchitektur

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (nur append): Objektspeicher + ACID-Tabellen (Delta/Iceberg/Hudi), Partitionen nach Datum/Markt/Tenant; Speicherung der ursprünglichen payload.
3. Stream Compute: Flink/Spark/Beam - Fenstereinheiten, KEP, Dedup, Online-Lookups.
4. Silber (clean/conform): Währungsnormalisierung/Zeitzone, FK/Handbücher, SCD für Messungen.
5. Serving/OLAP: ClickHouse/Pinot/Druid sind materialisierte Minuten-/Sekundenaggregate für Panels.
6. Gold (serve): Tages-/Stundenvitrinen, regulatorische Schnitte, unveränderliche Exportpakete (WORM).
7. Regelkreise: Schema Registry, DQ-as-Code, Lineage, Kataloge, Secrets/KMS, RBAC/ABAC.

3) Verträge und Regelungen

Schema-first: JSON/Avro/Protobuf; Pflichtfelder: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market', 'schema _ version'.
Evolution: back-compatible → nullable hinzufügen; breaking → '/v2'+ doppelter Eintrag.
Verzeichnis: Domain-Beschreibung, Besitzer, Frische SLA, DQ-Regeln, Lineage.

4) Landung der Bäche im See

Einmal ganz unten: at-least-once publishing + idempotent sink (MERGE/upsert by 'event _ id').
Dedup: stateful im Stream + einzigartig in Silber.
Dateikompression: kleine Dateien → regelmäßige OPTIMIZE/VACUUM zum Lesen und Kosten.
Zeitreise: umfasst Debugging, Replikate und Audit.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Aggregation von Strömen: Fenster und Wasserzeichen

• Tumbling - fest (z.B. 1 min/5 min) für stabile Paneele.
• Hopping - überlappend (Schritt
• Session - Verhaltenslücken durch Inaktivität.
• Watermarks: Kontrolle der Spätdaten (in der Regel 2-5 Minuten), Regeln für Voremission/Korrektur.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Materialisierung von Aggregaten

OLAP-Engine (ClickHouse/Pinot/Druid): Speichert Minuten-/Sekundenaggregate für Dashboards und Online-Analysen.
Lakehouse Gold: speichert Tages-/Stundenabschnitte für Reporting und Sweeps (Reproduzierbarkeit).

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;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Silber: Normalisierung und Harmonisierung

Zeit und Währung: 'event _ time (UTC)', 'amount _ base', 'fx _ rate _ used', 'fx _ source'.
Schlüssel/Verzeichnisse: 'user _ pseudo _ id', 'game _ id', 'provider _ id', 'market'.
SCD II: Historisierung von Messungen (Benutzer/Spiele/Anbieter/RG/KYC).
DQ-Regeln: Eindeutigkeit der Schlüssel, Verzeichnisse, Summenbereiche, zeitliche Gültigkeit.

8) Aggregatregister und „richtige“ Definitionen

Semantic Layer: einheitliche Formeln GGR/NGR, Wetten/Gewinne, Umwandlung, ARPPU, Latenz p95.
Versionierung der Metriken: 'metric _ version' und 'as-of' Berechnung.
Dock-Karten: Besitzer, Formel, Quellen, SLA Bereitschaft.

9) Exactly-once/idempotence und Ordnung

Bus: at-least-once + Partitionierung (lokale Ordnung).
Verarbeitung: Dedup durch 'event _ id' (TTL 24-72h), CEP/Fensteroperatoren mit Anpassungen.
Sink: Transaktionskommits oder idempotent upsert/merge.
Outbox/Inbox: Veröffentlichung von Domain-Events aus OLTP mit Garantie.

10) Späte Daten und Anpassungen

Erlaubt Latenz: 2-5 min für operative Vitrinen; tägliche Neumontage für Gold.
Korrekturen: Vor-Emissionen in OLAP und Gold (idempotent) -Nachbeseitigung.
Flags: 'late = true', 'correction _ of = <event _ id>' für die Prüfung.

11) Beobachtbarkeit und DQ

• p95 ingest→1 -min Vitrine ≤ 2-5 c; Gold täglich bereit bis 06:00 Uhr lok.
• Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Pipelinemetriken: lag/throughput/busy time/state size, late-ratio, dup-rate.
• DQ-Dashboards: Freshness/Completeness/Validity, Verlusttrichter, Hot-Key-Karte.
• Lineage: Weg von Bronze zu Gold/Exporte; Impact-Analyse bei Änderungen.

12) Privatsphäre, Wohnsitz, Sicherheit

PII-Minimierung: Pseudonymisierung, separates geschütztes Mupping.
Residency: EEA/UK/BR - separate Verzeichnisse und Verschlüsselungsschlüssel; Verbot regionalübergreifender Join's ohne Grund.
Verschlüsselung: TLS in-transit; KMS/CMK at-rest; Exportsignaturen + WORM bei der Regulierungsbehörde.
DSAR/RTBF/Legal Hold: Selektive Bearbeitung, Einfrieren von Löschungen, auditierbare Zugriffe.

13) Leistung und Kosten

Partitionierung: nach Datum/Markt/Tenant; Clustering/Z-Order nach häufig gefilterten Attributen.
Compact: Eliminierung kleiner Dateien, regelmäßig OPTIMIZE/VACUUM.
Materialisierung: Minuten/Sekunden - in OLAP; Tag/Stunde in Gold.
Tiered storage: hot/warm/cold, SLA recovery, chargeback per command (cost/GB, cost/query).
Voraggregationen/Sketche: HyperLogLog/approx-distinct wo akzeptabel.

14) Beispiele (Fragmente)

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Prozesse und RACI

• Data Platform (Lakehouse/Katalog/ACID, Compact),
• Streaming (Aggregate/CEP/dedup),
• Domain Analytics (Metriken/Gold).
• A (Accountable): Head of Data/CDO.
• C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
• I (Informed): BI/Produkt/Marketing/Operations.

16) Fahrplan für die Umsetzung

1. Lakehouse Bronze/Silber (ACID-Tabellen), ingest von Kafka, Registrierungsschemata.

2. Basis-Stream-Aggregate (1-5 min) in OLAP; Schaufenster Gold. ggr_daily (D + 1 bis 06:00 Uhr)

3. DQ-as-Code für Payments/Gameplay, Freshness/Completeness Dashboards.

4. Compact/OPTIMIZE, minimale Cost-Metriken und Alerts lag/late/dup.

• Erweiterung Silber (SCD II für Benutzer/Spiele/Anbieter), Lineage und Impact-Analyse.
• Asynchrone Lookups (RG/KYC/ASN/BIN), Steuerung von Late-Korrekturen.
• Semantische Metrikschicht, Exportverordnung (WORM/Signaturen).

• Multi-Region, DR/Replay-Simulator, Auto-Tuning von Fenstern und Wasserzeichen.
• Kosten-Dashboards, Chargeback/Kontingente, Tiered Storage und Archivierung.
• Autogenerierung der Dokumentation von Schaufenstern und Metrikkarten.

17) Checkliste vor dem Verkauf

• Systeme und Verträge im Register; Back-Compat-Tests sind grün.
• Dedup, Wasserzeichen/zulässige Latenz, DLQ enthalten.
• Compact/OPTIMIZE/VACUUM ist planmäßig konfiguriert.
• SLO: p95 ingest→minute-view, Gold до 06:00; lag/late/dup/state size alerts.
• DQ-Regeln sind aktiv; lineage sichtbar von Bronze bis Export.
• RBAC/ABAC и KMS; Wohnsitz und DSAR/RTBF/Legal Hold getestet.
• Kosten unter Kontrolle (cost/GB, cost/query, cold share), Grenzen für Replays.

18) Anti-Muster und Risiken

Vermischung von Roh- und Meldedaten in einer Tabelle: stört die Reproduzierbarkeit.
Mangel an Kompaktheit: Explosion von kleinen Dateien → teure Anfragen.
FX-Berechnung „im Nachhinein“: bricht Geschichte und Berichte.
Keine Wasserzeichen/Late-Politiker: Schaufenster und Alerts „schweben“.
Volles Reload ohne Not: Nutzen Sie Inkremente/MERGE und Anpassungen.
PII in Analytics: Muppings getrennt halten, CLS/RLS einschalten.

19) Glossar (kurz)

Lakehouse - Datensee + ACID-Tabellen und SQL-Engine.
Bronze/Silber/Gold - roh/normalisiert/Serving-Schichten.
Watermark ist die Grenze der Ereigniszeit-Fensterbereitschaft.
Materialized View ist ein vorgefertigtes Schaufenster für schnelles Lesen.
Zeitreise - Lesen Sie historische Versionen von Tabellen.
WORM ist die unveränderliche Lagerung von Exportartefakten.

20) Das Ergebnis

Der Data Lake mit der richtigen Stream-Aggregation ist die Disziplin der Schichten und Verträge: Bronze „as is“, Silber für Normalisierung und Qualität, OLAP für Minutentafeln, Gold für reproduzierbare Berichte. Durch die Verwaltung von Fenstern und Wasserzeichen, Deduplex und Kompression, Privatsphäre und Kosten erhalten Sie schnelle, überprüfbare und konforme Vitrinen für Produkt-, Compliance- und Betriebsmanagement.