Datenschemata und ihre Entwicklung

1) Warum ist es eine iGaming-Plattform

Zuverlässigkeit: Änderungen an Daten machen Berichte, APIs und Modelle nicht kaputt.
Geschwindigkeit: Fügen Sie Felder (KYC/RG/PSP) sicher hinzu, ohne die Streams zu stoppen.
Regulatory: Rückverfolgbarkeit und Reproduzierbarkeit (Audit/Lineage, DSAR, Legal Hold).
Kosten: Minimieren Sie „Überläufe“ und Downtime von Backfills.

2) Arten von Schemata und wo sie leben

Veranstaltungen (Streams): 'payments. deposit_accepted`, `game. round_finished`.
OLTP/DDL: normalisierte Tabellen (KYC, Konten, Limits).
DWH/Showcases (Gold): denormalisierte Aggregate unter BI/ML.
Feature Store: Online-/Offline-Fich-Sets mit Konsistenzgarantien.
Verträge von externen Partnern: PSPs, Spieleanbieter, Marketingquellen.

Notationen: Avro/Protobuf (Streams), JSON Schema (Integrationen), SQL DDL (DWH), Parkettschema (See).

3) Kompatibilität (Kern der Evolution)

Backward-kompatibel: Neue Produzenten → alte Konsumenten (fügten das Feld c default/nullable hinzu).
Forward-kompatibel: Alte Produzenten → neue Konsumenten (neuer Leser ignoriert Überschuss).
Full-compatible: beides (gewünschtes Ziel für Veranstaltungen).
Breaking-changes: Feld umbenennen/löschen, Typ/Semantik ändern, Schlüssel/Partitionierung ändern.

Regel 1: Ereignisse entwickeln sich durch Hinzufügen, nicht durch Ändern.
Regel 2: Löschen - nur in der MAJOR-Version des Schemas nach der Deprecate-Periode.

4) Semantische Versionen und Richtlinien

`MAJOR. MINOR. PATCH 'für jedes Schema/Schaufenster/Fitch-Set.

MAJOR - nicht kompatibel (neues Thema/Tabelle/Festsatz, Dual-Run).
MINOR - kompatibel (neue nullbare/default Felder, neue enum-Werte).
PATCH - Änderungen an Beschreibungen/Limits/Kommentaren.

Lebenszyklus des Feldes: 'experimental → active → deprecated → removed' (mit Datum und Besitzer).

5) Scheme-Register und Datenverträge

Schema Registry: speichert Versionen, Kompatibilität, Evolution und Besitzer.
Datenvertrag: Erfasst das Qualitätsschema + SLO + Datenschutz (siehe Abschnitt Datenvalidierung).

json
{
"type":"record","name":"deposit_accepted","namespace":"payments",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"user_id","type":"string"},
{"name":"brand","type":"string"},
{"name":"country","type":"string"},
{"name":"psp","type":"string"},
{"name":"method","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":{"type":"enum","name":"Currency","symbols":["EUR","USD","TRY","BRL"]}},
{"name":"risk_score","type":["null","int"],"default":null},       // MINOR+
{"name":"kyc_level","type":["null",{"type":"enum","name":"Kyc","symbols":["L0","L1","L2","L3"]}],"default":null}
],
"compatibility":"FULL","owner":"team-payments"
}

6) Migrationsmuster

6. 1 Veranstaltungen (Streams)

Nur additiv: Fügen Sie Felder mit default/nullable hinzu; Alte Consumer gehen nicht kaputt.
Enum-Extensions: Neue Symbole gelten als MINOR, Consumer müssen einen 'else/unknown' -Zweig haben.
MAJOR-Migration: ein neues Thema "Zahlungen. deposit_accepted. v2', Dual-Write, Shadow-Reads, dann Consumer-Switching.

6. 2 DWH/Schaufenster

Blau-Grüne Tabellen: 'gold. revenue_v2' neben 'v1'; materialisieren, vergleichen, BI wechseln.
Backfill: Replay durch Schnappschüsse + idempotent merge (durch Schlüssel/Versionen).
SCD: Typ 2 für langsam wechselnde Attribute (Limits, KYC, VIP-Status).

6. 3 Feature Store

Dual-serve: das alte Fitch-Set wird parallel zum neuen bedient; Das Modell wird über einen Router bedient.
Point-in-Time-Konsistenz: Evolution darf PITA-Joins nicht brechen (Timestamp/Granularität unverändert bei MINOR).

7) Taxonomie der Änderungen (Checkliste)

• Hinzufügen eines' nullable/default '-Feldes;
• Erweiterung enum (mit 'unknown' -Zweig beim Verbraucher);
• Die Ergänzung des nicht Schlüsselindexes/Kommentars/Beschreibung.

• Änderung der Skala/Einheiten (z. B. amount in Cent → in der Hauptwährung) - nur in MAJOR;
• Handbuch/Referenz-Transfer - durch die Präsentationsschicht.

• Umbenennen/Löschen eines Felds;
• Änderung des Typs/Formats/Schlüssels/Partition;
• Änderung der Semantik (z. B. „bonus _ amount“ von „aufgeladen“ → „abgeschrieben“).

8) Schaltungslinter und Kompatibilitätstests

Schema-lint: Namensstil ('snake _ case'), erforderliche Bezeichnungen ('owner', 'doc', 'pii'), Datums-/Währungsformat.
Compat-Tests: Wir prüfen die neue Version gegen die Registry (backward/forward/full).
Verbrauchervertragstests: Jeder Dienst liefert ein „Nutzlastbeispiel“ und Erwartungen; Wir fahren auf CI beim Wechsel des Schemas.
Golden-datasets: eine Reihe von realen und „bösen“ Beispielen (neue enum, leere/späte Felder, Grenzwerte von Summen).

9) Verzeichnisse, enum und Lokalisierung

Referenzdaten (Länder/Währungen/PSPs/Anbieter): separate Versionen und SLAs von Updates; nicht in den Ereigniscode einnähen.
Locale/Zeitzonen: Speichern Sie UTC in Events + explizite Locale für die Präsentation.
Regeln der Gerichtsbarkeiten: Altersflaggen, Promobeschränkungen - in Form von Verzeichnissen mit Gültigkeitsdaten.

10) Multibrand/Multijurisdiktion und PII

Tenant-Isolation: 'brand', 'country', 'license' - Pflichtfelder mit enum; Routing auf sie.
PII-Richtlinie auf Schemaebene: Felder 'pii = true' markieren, Masken/Tokenisierung anwenden; in Ereignissen - nur Token.
DSAR: Vorhandensein von 'source _ id/trace _ id' zum Löschen/Suchen; Legal Hold auf MAJOR-Migrationen.

11) Versionierung von DDL und See

DDL-Migrationen: deklarative Migrationen (Liquibase/Flyway/dbt), Speicherung im VCS, Revue des Domain-Inhabers.
Formate im See: Avro/Parkett - wir erfassen die Entwicklung der Felder; bei MAJOR eine neue Tabelle/Pfad '.../v2/'.
Partitioning: Ändern von Parties (z.B. 'date'→'date,brand') - nur durch MAJOR und Double Entry.

12) Beispiele für iGaming

12. 1 PSP erweiterte Methoden

'Methode =' MEFETE''zu enum hinzugefügt.
MINOR Release des Schemas' deposit _ accepted v1. 8. 0`; Consumer, die MEFETE nicht kennen, senden einen Zweig an 'unknown _ method'.

12. 2 Spieleanbieter hat Felder hinzugefügt

Im 'Spiel. round_finished' wurde „jackpot _ id“ (nullbar) hinzugefügt.
Schaufenster 'Gold. game_rounds_v3' erhält MINOR; alte Berichte funktionieren, neue zählen Jackpots.

12. 3 RG-Attribute

Übergang vom Booleschen 'self _ excluded' zum Status' rg _ state ∈ {none, limit, cooldown, self_excluded}' - MAJOR, neues Thema + dual-write + Migration von Schaufenstern und Modellen.

13) Evolutionsprozess (von der Idee bis zum Wechsel)

1. Proposal (ADR): Warum wir ändern, Art der Kompatibilität, Risikobewertung und betroffene Verbraucher.
2. Entwurf und Vertrag: Schema im Register, semver, Kompatibilitätspolitik.
3. Tests: linters, compat, consumer-contracts, replies on golden-sets.
4. Einsatz: dual-write/blue-green/shadow-reads; Alertas.
5. Überleitung: Geschäftsbilanzen/Invarianten (siehe „Datenvalidierung“).
6. Schalter: Wir wechseln zwischen Consumer/BI/Fichy.
7. Deprecate: freeze des alten Schemas, grace-period, delete und archive.

14) Metriken und SLO der Evolution

Erfolgsrate der Migrationen, Dual-Run-Zeit, Ereignisanteil des neuen Formats, Backfill-Volumen, Lag/Freshness.
Kompatibilitätsvorfälle (P1/P2), Qualität der Vitrinen nach Umschaltung.
Kosten: $/TB Überlauf, $/Stunde dual-write, Cluster-Boot.
Compliance: 0 PII-Lecks, SLA DSAR/Legal Hold erfüllt.

15) Werkzeuge und Artefakte

15. 1 Kompatibilitätsrichtlinie (Register)

yaml schema: payments. deposit_accepted compatibility: FULL default_nulls: true enums:
currency: {allow_new_symbols: true, require_consumer_unknown_branch: true}
pii: false owners: ["team-payments"]
reviewers: ["data-governance","security-dpo"]

15. 2 Migrationsdatenblatt (Vorlage)

yaml change_id: MIG-2025-041 scope: game. round_finished -> v3 type: MAJOR plan:
dual_write: true shadow_reads: consumers: ["gold-rounds","rg-models"]
backfill: {from: "2025-01-01", mode: "idempotent-merge"}
validation:
invariants: ["sum_bets = sum_wins + margin + bonuses"]
freshness_delta_p95_max: "PT5M"
switch_criteria:
error_rate_max: 0. 1%
kpi_diff_pp_max: 0. 5 deprecate_after: "2025-12-31"

15. 3 Linter von Namen und Typen (Regeln)

'snake _ case', UTC-Zeitstempel, DECIMAL (18,2) für Beträge, 'country' für ISO-3166-1 alpha-2, 'currency' für ISO-4217.
Kein 'free _ text' für enum-Felder; Die Verzeichnisse sind extern.

16) Fahrplan für die Umsetzung

0-30 Tage (MVP)

1. Aktivieren Sie Schema Registry + Kompatibilitätsrichtlinie für Schlüsselereignisse (Zahlungen, game_rounds, Benutzer).
2. Linter-/Compat-Tests im CI; Besitzer Verzeichnis und SLA Bewertungen.
3. ADR-Vorlagen und Migrationsdatenblatt; Checkliste MAJOR.

30-90 Tage

1. Blau-Grün für Gold-Vitrinen; dual-write für kritische Themen.
2. Consumer-contract-tests für die wichtigsten Dienstleistungen; golden-datasets.
3. Automatische Diff-Matches und Alerts beim Umschalten; Kostenberichte.

3-6 Monate

1. Einzelprozess deprecate/remove mit grace-period; Archivierung und Legal Hold.
2. Geo-/Tenant-spezifische Schemata und Verschlüsselungsschlüssel; DP-Optionen für sensible Märkte.
3. Das Verzeichnis der Semantik der Felder (data dictionary) und die lebendigen Diagramme lineage.

17) RACI

Data Governance (A/R): Standards, Register, Migrationsrevue, De-Publishing.
Domain Owners (R): Bedeutung von Feldern, Verzeichnissen, Geschäftsinvarianten.
Data Platform (R): Registry-Tools, Compat-Tests, Dual-Run/Backfills.
Sicherheit/DSB (A/R): PII-Richtlinien, geo/tenant, DSAR/Legal Hold.
SRE/Observability (C): Warnungen, SLOs der Evolution, Kapazität.
Produkt/Finanzen (C): Validierung von KPIs, Schaltfenster.

18) Anti-Muster

„Wir regeln das Feld on the fly“ ohne Versionen und Dual-Run.
Umbenennen statt Hinzufügen eines neuen Felds → massive Pannen.
Hard enum ohne Zweig 'unknown' → Tropfen bei neuen Werten.
Eine einzige Referenz „im Code“ für alle Gerichtsbarkeiten.
Backfill ohne idempotent-merge und Scheckbilanzen.
Protokolle mit PII und ohne trace_id für die Suche/DSAR.

19) Verwandte Abschnitte

Datenvalidierung, Datenherkunft und -pfad, DataOps-Praktiken, Analyse- und Metrik-APIs, Audit und Versionsfähigkeit, Datensicherheit und Verschlüsselung, Zugriffskontrolle, MLOps: Ausnutzung von Modellen.

Summe

Die Entwicklung der Systeme ist ein Prozess, keine einmalige Migration: Register, Versionen und Interoperabilität; Dual-Run und Blau-Grün statt „Schalter um Mitternacht“; Kompatibilitätstests und Geschäftsinvarianten statt Glück. So bleiben die Daten stabil, die Modelle vorhersehbar, die Berichte korrekt und die Regulierungsbehörden ruhig.