Data Mesh: Ein föderiertes Datenmodell

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Data Mesh ist ein organisatorisches und technisches Modell, bei dem Daten als Produkte von Domain-Teams betrachtet werden und die zentrale Rolle der Plattform darin besteht, Self-Service, Standards und Compliance bereitzustellen. Für iGaming bedeutet das: Das Payments-Team besitzt „Deposit Events“ und „Net Deposits Mart“, das Risk-Team „Fraud Signals“, Games „Bet Events“ und „Leaderboards“ und die zentrale Plattform gibt Katalog, Schema-Verträge, Zugänge, Qualitätsüberwachung, Finops und Tools Streaming/ELT.

1) Prinzipien des Data Mesh

1. Domain-Verantwortung: Jede Domain (Payments, Risk, Games, KYC/Compliance, CRM, Affiliate) besitzt ihre eigenen Datensätze und deren Lebenszyklus.
2. Daten als Produkt: Jeder Satz hat einen Besitzer, Beschreibung, SLO, SLA-Zugang, Dokumentation, Version, Feedback und Roadmap.
3. Self-serve Plattform: Standard-Pipelines ingest/transform/serve, Vorlagen, Standard-Sicherheit, Katalog und Beobachtbarkeit.
4. Federated Governance: Gemeinsame Standards für Schemata, Metriken, PII/Lokalisierung und Qualität stehen im Mittelpunkt; Implementierung und Evolution - in Domänen.

2) Betriebsmodell und Rollen

Domain Data Product Owner (DPO): Priorisierung, SLO, Backlog von Datenproduktverbesserungen.
Domain Data Engineer/Analytics Engineer: Diagramme, Pipelines, DQ-Tests, Versionierung.
Domain Steward: Semantik der Felder, Einhaltung des Metrik-Wörterbuchs und PII-Klassifizierung.
Plattformteam: Katalog, IAM/RBAC, Policy-as-Code, Tabellenformate (Delta/Iceberg/Hudi), Orchestrierung, Beobachtbarkeit, Finopse.
Federated Governance Board: genehmigt Standards (Schemata, Metriken, Sicherheit), löst domänenübergreifende Streitigkeiten.

3) „Datenprodukt“ - Datenblatt und Artefakte

• Vertrag (Schema, Typen, Entwicklung, Kompatibilität).
• Zugriff API (SQL/Tabelle, topic/stream, Datei/Shar).
• SLA/SLO (Frische, Verfügbarkeit, Qualität).
• DQ-Tests (Eindeutigkeit, Bereiche, referenzielle Integrität).
• Dokumentation (Feldbeschreibung, Beispielabfragen, Eigentümer, Kontakt).
• Versionierung (semantic versioning schemas, deprecate policy).
• Richtlinien (PII, Lokalisierung, Retention/TTL, Rechte).

Passvorlage (YAML, Beispiel)

yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"

4) Interoperabilität und Standards

Schemes/contracts: Avro/Protobuf/JSON-Schema + Schema Registry; Backcompat-Richtlinie, Verbot von brechenden Änderungen ohne neue Major-Version.
Semantische Schicht: einheitliche Definitionen von GGR, NGR, Net Deposits, LTV, Kohorten - als Code (dbt metrics/semantic layer).
Kennungen: globale' player _ id', 'tenant _ id', 'bet _ id', einheitliche Länderverzeichnisse/Währungen/Anbieter.
Metadaten: erforderliche Spalten 'ingest _ ts', 'schema _ version', 'trace _ id', 'source', 'region'.
Zugriff: SQL (Lakehouse/OLAP), Stream (Kafka/Pulsar), Tabellen/Snapshots-Sharing; Austauschformat - Parkett/Delta/Iceberg.

5) Technologische Referenz (agnostisch zu den Verkäufern)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; inkrementelle' MERGE', SCD, Materialvitrinen.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Verzeichnis/Lineage: einheitliches Verzeichnis, Auto-Dokumentation, Abhängigkeitsgraph.
Beobachtbarkeit: Frische/SLO-Metriken, DQ-Assert, Stream-Lags, Kosten.
Richtlinien: IAM/RBAC/ABAC, Verschlüsselung, Lokalisierung (Zonen-Datenrouting).

6) SLO/SLA für Datenprodukte

• Freshness: Bets Events (p95) ≤ 5 мин; Fraud Signals ≤ 30 Sekunden Net Deposits Mart ≤ 15 Min.
• Availability: ≥ 99. 9% für Leseschnittstellen.
• Qualität: Duplikate ≤ 0 01%, der Anteil der leeren Pflichtfelder ≤ 0. 1%, Währungskonsistenz 100%.
• Kosten SLO: Kosten für Schaufenster Scans ≤ N $/Tag, kleine Dateien Verhältnis <10%.

7) Sicherheit, PII und Lokalisierung

Klassifizierung: PII/sensitive Daten/operativ.
Techmer: at-rest/in-transit Verschlüsselung; Tokenisierung von PII; Maskieren von Spalten; row-level Filter nach 'tenant _ id'.
Lokalisierung: Domain-Produkte werden in den zugelassenen Regionen (EU/TR/LATAM) veröffentlicht; grenzüberschreitendes Sharing - nur Aggregate ohne PII.
Audit: wer veröffentlicht/gelesen hat; Version des Schemas; Anträge auf Eskalation von Rechten - durch Verhandlung.

8) FinOps und Wertmanagement

Budgets nach Domäne: compute limits, overspend alerts.
Lagerung: Speicherklassen + TTL (Bronze kurz, Silber mittel, Gold lang/Aggregate).
Abfrageoptimierung: Partitionen/Clustering, materialisierte Ansichten, BI-Ergebniscache.
Kleine Dateien: compaction/OPTIMIZE Richtlinien; Zieldateigröße 128-1024 MB.

9) Lebenszyklus und Evolution

Versionierung: 'Domäne. product. v{major}`; minor fields - back-compat.
Deprecate: Verbraucherbenachrichtigung, „Zwei-Schienen“ -Periode, automatische Warnungen für ältere Versionen.
Änderungen der Schemata: Pull Request in das Vertragsregister; CI-Kompatibilitätstests; AutoPublizieren in ein Verzeichnis.
Feedback: Produktkanal (Ausgabe Tracker), Verbraucher NPS, Incident Response Time.

10) Konkretisierung für iGaming - Domain- und Produktkarte

Payments

`payments. psp. webhooks. v1` (stream)

`mart_net_deposits_daily. v1'(SQL) - Frische SLO ≤ 15 min; PII-free

Games

`bets. events. v1'(Stream/SQL) - p95 ≤ 5 min

`mart_ggr_daily. v1'(SQL/MV) - Aggregate nach Ländern/Spielen

Risk/Anti-fraud

`risk. signals. v1'(Stream) - p95 ≤ 30 Sekunden

`risk. case_mgmt. v1'(SQL) - SCD2 der Untersuchungsgeschichte

CRM/Personalization

`crm. triggers. v1'(Stream) - Segmentauslöser

`profile. features. online. v1'(KV/SQL) - Online-Fichy (TTL)

KYC/Compliance

`kyc. status. v1'(SQL) - PII gesichert, row-level policies

`responsible_gaming. events. v1'(Stream) - Grenzen/Signale

11) Plattformprozesse und Artefakte

Verzeichnis: Suche nach Domain/Felder/PII-Tags, Vorschau von Diagrammen und Beispielen.
Mustergeneratoren: Cookiecutter für ein neues Produkt (Datenblatt, CI, DQ-Tests, SLO-Dashboards).
Policy-as-Code: Regeln für Export, PII, Sharing zwischen Regionen.
Beobachtbarkeit: fertige Dashboards: Frische, DQ-Fehler, Kosten, Lineage, Stream-Fehler.
Runbooks: Frische-/DQ-/Schaltungsvorfälle, Notfall-Deprecate, Rollback-Versionen.

12) Migration zum Data Mesh (Roadmap)

1. Bestandsaufnahme der aktuellen Datasets → Gruppierung nach Domains.
2. Pilot 2-3 Domain (Zahlungen, Spiele, Risiko) - als Produkte mit Pässen zu gestalten.
3. Katalog und Standards: Schemata, Metriken, PII/Lokalisierung, DQ.
4. Self-serve: Pipelinemuster, CI/CD, SLO-Überwachung.
5. Schneiden von monolithischen Vitrinen in Domänen; „Zwei-Schienen“ -Unterstützung für alte Schnittstellen.
6. Der Bundesrat - regelmäßige Sitzungen, Revue für den Wechselvertrag.
7. Skalierung auf CRM/Affiliates/Marketing, dann - auf Affiliate-Chers.

13) Checkliste Umsetzung

Domänen sind definiert; Besitzer und Kommunikationskanäle werden zugewiesen.
Verzeichnis gestartet; Das Datenblatt jedes Produkts wird veröffentlicht.
Schemata - im Vertragsregister; CI testet Kompatibilität/DQ.
SLO/SLA sind deklariert; Freshness/DQ/Cost Dashboards sind verfügbar.
PII/Lokalisierungsrichtlinien - Code; Audit ist aktiviert.
FinOps: Budgets, Alerts, Bericht „Kosten pro Domäne“.
Versionierung/Deprecate-Prozess - dokumentiert und automatisiert.
Runbooks der Vorfälle - verfügbar und trainiert (Spieltag).

14) Antipatterns

„Umbenannt in Data Mesh, aber alles über ein zentrales Datenkommando“ - der schmale Hals ist nicht beseitigt.
Das Fehlen eines einzigen Wörterbuchs von Metriken → GGR/NGR unterscheiden sich zwischen den Domänen.
Systeme ohne Verträge und Kompatibilitätstests → „Breaking“ -Freigaben.
Kein Self-serve → jede Tabelle wird manuell erstellt, hohe Zeit-zu-Daten.
Missachtung der PII/Lokalisierung beim cross-regionalen Sharing.
Mikroprodukte ohne Eigentümer/SLOs sind „verlassene“ Daten.

15) KPIs für den Erfolg von Data Mesh

Time-to-Data: Von der Idee zum verfügbaren Datenprodukt (Median ↓).
Wiederverwendung: Anzahl der Verbraucher-Domains pro Produkt.
Qualität: Anteil erfolgreicher DQ-Prüfungen, Mängel pro Millionen Veranstaltungen.
Zuverlässigkeit: SLO-Konformität von Frische/Verfügbarkeit.
Kosten: $/Anfrage/Benutzer, Anteil der kleinen Dateien, Entsorgung compute.
Änderungsrate: Schaltplan-/Schaufensterfreigaben pro Woche.

Ergebnisse

Data Mesh ist nicht nur eine Technologie, sondern auch eine verwaltete Domain-Föderation, in der Daten Produkte mit ihren Eigentümern, SLOs, Verträgen und Qualitätsmetriken sind. Bei iGaming beseitigt dieser Ansatz enge Hälse, beschleunigt Integrationen (Betrugsbekämpfung, Zahlungen, CRM), verbessert die Transparenz von Metriken (GGR/NGR/LTV) und steuert die Kosten. Bauen Sie eine starke Self-Serve-Plattform auf, geben Sie föderierte Standards und eine Data-as-a-Product-Kultur ein, und Ihr analytisches Ökosystem skaliert mit dem Geschäft - ohne Verlust an Qualität, Geschwindigkeit und Compliance.