Schemele de date și evoluția acestora

1) De ce este aceasta o platformă iGaming

Fiabilitate - Modificările aduse datelor nu sparg rapoartele, API-urile sau modelele.
Viteza caracteristică: adăugați în siguranță câmpuri (KYC/RG/PSP) fără a opri fluxurile.
Reglementare: trasabilitate și reproductibilitate (audit/descendență, DSAR, Legal Hold).
Cost: minimizați „revărsările” și timpii de inactivitate ai rambursărilor.

2) Tipuri de scheme și unde trăiesc

Evenimente (fluxuri): "plăți. deposit_accepted', "joc. round_finished'.
OLTP/DDL: tabele normalizate (KYC, conturi, limite).
DWH/storefronts (Aur): agregate denormalizate sub BI/ML.
Feature Store: seturi de funcții online/offline cu garanții de consecvență.
Contracte de parteneri externi: PSP, furnizori de jocuri, surse de marketing.

Notatii: Avro/Protobuf (streams), JSON Schema (integrations), SQL DDL (DWH), Parchet schema (lake).

3) Compatibilitate (nucleul evoluției)

Compatibil înapoi: producători noi → consumatori vechi (câmp adăugat c implicit/nullable).
Compatibil înainte: producători vechi → consumatori noi (cititor nou ignoră inutile).
Compatibil complet: ambele (obiectiv dorit pentru evenimente).
Modificări de rupere: redenumirea/ștergerea unui câmp, schimbarea tipului/semanticii, schimbarea tastei/partiționării.

Regula 1: evenimentele evoluează prin adăugare, nu prin schimbare.
Regula 2: ștergeți - numai în versiunea MAJORĂ a schemei după perioada de depreciere.

4) Versiuni și politici semantice

MAIORULE. MINOR. PATCH "pentru fiecare set de scheme/vitrine/caracteristici.

MAJOR - incompatibil (nou subiect/tabel/set de caracteristici, dual-run).
MINOR - compatibil (noi câmpuri nullable/default, noi valori enum).
PATCH - editați descrieri/limite/comentarii.

Ciclul de viață al câmpului: „experimental → activ → depreciat → îndepărtat” (cu date și proprietar).

5) Registrul schemei și contracte de date

Schema Registry: stochează versiuni, compatibilitate, evoluție și proprietari.
Contract de date: stabilește schema + calitatea SLO + confidențialitate (a se vedea secțiunea „Validarea datelor”).

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) Modele de migrare

6. 1 Evenimente (fluxuri)

Numai aditivi: adăugați câmpuri cu implicit/nullable; consumatorii vechi nu se sparg.
Extensii de enum: caractere noi sunt considerate minore, consumatorii trebuie să aibă o ramură „altfel/necunoscut”.
MIGRAȚIA MAJORĂ: plățile noului subiect. deposit_accepted. v2 ', dual-write, shadow-reads, apoi comutarea consumatorilor.

6. 2 DWH/storefronts

Tabele albastru-verde: "aur. revenue_v2' lângă „v1”; materializați, verificați, schimbați BI.
Backfill: reluare prin instantanee + îmbinare idempotentă (prin taste/versiuni).
SCD: tip 2 pentru atribute în schimbare lentă (limite, KYC, statusuri VIP).

6. 3 Magazin de caracteristici

Dual-serve: setul de caracteristici vechi este servit paralel cu cel nou; modelul este deservit printr-un router.
Consistența punctuală: evoluția nu trebuie să rupă bucuriile PITA (marcajul de timp/granularitatea sunt neschimbate la MINOR).

7) Taxonomia modificărilor (lista de verificare)

• adăugarea câmpului „nullable/default”;
• extinderea enum (cu o sucursală „necunoscută” la consumator);
• adăugarea unui index/comentariu/descriere non-cheie.

• Schimbare de scară/unitate (de exemplu, suma în cenți → moneda de bază) - NUMAI MAJOR
• transfer de referință/referință - prin stratul de prezentare.

• Redenumirea/ştergerea unui câmp
• Modificarea tipului/formatului/cheii/partiției
• schimbarea semanticii (de exemplu, „bonus _ sound” de la „acumulat” → „eliminat”).

8) Lintere de circuit și teste de compatibilitate

Schema-scame: nume stil ('snake _ case'), etichete necesare ('proprietar', 'doc', 'pii'), format dată/monedă.
Compat-teste: verificarea noii versiuni în registru (înapoi/înainte/complet).
Consumer-contract-teste: fiecare serviciu oferă o „sarcină utilă eșantion” și așteptări; rula pe CI atunci când se schimbă schema.
Seturi de date de aur: un set de exemple reale și „malefice” (enum nou, câmpuri goale/târzii, valori limită ale sumelor).

9) Directoare, enum și localizare

Date de referință (țări/valute/PSP/furnizori): versiuni individuale și actualizări SLA; nu coase în codul evenimentului.
Zone locale/orare: stocați UTC în evenimente + localizare explicită pentru prezentare.
Reguli de jurisdicție: pavilioane de vârstă, restricții promoționale - sub formă de directoare cu date de acțiune.

10) Multi-Brand/Multi-Jurisdicțional și PII

Izolarea chiriașilor: „marcă”, „țară”, „licență” - câmpuri obligatorii cu enum; rutare pe ele.
Politica PII la nivel de schemă: marcați câmpurile 'pi = true', aplicați măști/tokenization; în evenimente, doar jetoane.
DSAR: prezența 'source _ id/trace _ id' pentru ștergerea/recuperarea; Legal Hold privind migrațiile majore.

11) Versioning DDL și lac

Migrații DDL: migrații declarative (Liquibase/Flyway/dbt), stocare în VCS, revizuire de către proprietarul domeniului.
Formate în Lacul: Avro/Parchet - înregistrează evoluția câmpurilor; la MAJOR - tabel nou/cale '.../v2/'.
Partiționare: schimbarea părților (de exemplu, „date'→'date,brand”) - numai prin intrare majoră și dublă.

12) Exemple de iGaming

12. 1 metode extinse PSP

Adăugat 'metodă = „MEFETE”' la enum.
Eliberarea minoră a 'dosit _ acceptată v1. 8. 0`; consumatorii care nu cunosc MEFETE trimit o sucursală la 'known _ method'.

12. 2 Furnizorul de jocuri a adăugat terenuri

V 'game. round_finished' adăugat 'jackpot _ id' (nullable).
Aurul vitrinei. game_rounds_v3' primește MINOR; rapoartele vechi funcționează, cele noi contează jackpot-uri.

12. 3 atribute RG

Tranziția de la Boolean 'self _ exclused' la status 'rg _ state ∈ {none, limit, cooldown, self_excluded}' - MAJOR, new topic + dual-write + migration of showcases and models.

13) Procesul de evoluție (de la idee la comutator)

1. Propunere (SAL): de ce schimbări, tipul de compatibilitate, evaluarea riscurilor și consumatorii afectați.
2. Design și contract: sistem de înregistrare, semver, politică de compatibilitate.
3. Teste: lintere, compat, contracte de consum, reluare pe seturi de aur.
4. Implementare: dual-write/blue-green/shadow-reads; alerte.
5. Reconciliere: Solduri de afaceri/invarianți (a se vedea Validarea datelor).
6. Comutator: comutator consumatori/BI/caracteristici.
7. Depreciați: înghețați schema veche, perioada de grație, ștergeți și arhivați.

14) Metrica și SLO-urile evoluției

Rata de succes a migrațiilor, timpul dual-run, cota de evenimente de format nou, volumul de rambursare, lag/prospețime.
Incidente de compatibilitate (P1/P2), calitatea ferestrelor după comutare.
Cost: $/TB overflow, $/oră dual-write, încărcare cluster.
Conformitate: 0 scurgeri PII, SLA DSAR/Legal Hold îndeplinite.

15) Instrumente și artefacte

15. 1 Politica de compatibilitate (registru)

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 Pașaport de migrare (model)

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 de nume și tipuri (reguli)

'sake _ case', marcaje de timp UTC, DECIMAL (18. 2) pentru sume, „țară” pentru ISO-3166-1 alfa-2, „monedă” pentru ISO-4217.
Câmpuri de enum no 'free _ text' pentru; cărți de referință - externe.

16) Foaia de parcurs privind implementarea

0-30 zile (MVP)

1. Activați registrul schemei + politica de compatibilitate pentru evenimentele cheie (plăți, game_rounds, utilizator).
2. Teste de linter/compat în CI; director proprietar și recenzii SLA.
3. Șabloane ADR și pașaport de migrare; Lista de verificare majoră.

30-90 zile

1. Albastru-verde pentru vitrine de aur; dual-write pentru subiecte critice.
2. Testarea contractelor de consum pentru serviciile de bază; seturi de date de aur.
3. Diff-reconcilieri automate și alerte la comutare; rapoarte de costuri.

3-6 luni

1. Proces unic de depreciere/eliminare cu perioada de grație; arhivare și Legal Hold.
2. Scheme și chei de criptare specifice geografiei/chiriașilor; Variante DP pentru piețe sensibile.
3. Dicționar de date și diagrame de linie live.

17) RACI

Guvernanța datelor (A/R): standarde, registru, revizuire migrație, de-publicare.
Proprietarii de domenii (R): semnificația câmpurilor, cărți de referință, invarianți de afaceri.
Platforma de date (R): instrumente de registry, teste de compat, dual-run/backfills.
Securitate/DPO (A/R): politici PII, geo/chiriaș, DSAR/Legal Hold.
SRE/Observabilitate (C): alerte, evolutie SLO, capacitate.
Produs/Finanțe (C): validarea KPI-urilor, comutarea ferestrelor.

18) Anti-modele

„Editați câmpul pe zbor” fără versiuni și dual-run.
Redenumirea în loc să adăugați un nou câmp → defecțiuni masive.
Enum greu fără ramura 'unknown' → scădea la noi valori.
Un singur director „în cod” pentru toate jurisdicțiile.
Rambursare fără solduri idempotent-fuzionare și verificare.
Jurnale cu PII și fără trace_id pentru căutare/DSAR.

19) Secțiuni conexe

Validarea datelor, originea și calea datelor, practicile DataOps, API de analiză și metrică, auditarea și versioning, securitatea și criptarea datelor, controlul accesului, MLOps: exploatarea modelului.

Total

Evoluția sistemelor este un proces, nu o migrație unică: registru, versiuni și interoperabilitate; dual-run și albastru-verde în loc de „comutatoare la miezul nopții”; teste de compatibilitate și invarianți de afaceri în loc de noroc. Deci datele rămân stabile, modelele sunt previzibile, rapoartele sunt corecte, iar autoritățile de reglementare sunt calme.