GH GambleHub

Lucrul cu date istorice

1) Scop și principii

Scop: Stocați și procesați stările anterioare, astfel încât rapoartele, modelele și investigațiile să fie reproductibile, exacte și conforme.

Principii:
  • Timp-conștient de design-explicit modele de timp în scheme și interogări.
  • Reproductibilitate: Același raport pentru data D produce întotdeauna același rezultat.
  • Auditabilitate: descendență, straturi imuabile, WORM-uri acolo unde este necesar.
  • Conștient de costuri: straturi de arhivă, compresie, stocare la rece cu SLA-uri ușor de înțeles.
  • Privacy-by-design: managementul PII pentru tranzacții retrospective și cereri legale.

2) Modelele de timp

Timpul evenimentului: ora evenimentului real (rată, depozit).
Timpul de procesare atunci când sistemul a procesat înregistrarea (poate diferi).
Bitemporal: stocarea atât a event- cât și a timpului de procesare pentru editări retroactive.
Intervale de valabilitate: 'valid _ from', 'valid _ to', 'is _ current'.
As-of interogări: eșantionare de date "așa cum au știut la momentul T.

Șablon de câmp:
sql event_time TIMESTAMP, -- event time processed_at TIMESTAMP, -- TIMESTAMP valid_from processing time, -- start of version validity valid_to TIMESTAMP, -- end of validity (NULL if current)
is_current   BOOLEAN

3) Straturi și formate de stocare

Lakehouse: Bronz (numai pentru adăugare brută) → Silver (curat/SCD/normalizare) → Gold (vitrine).
ACID- форматы: Delta/Iceberg/Hudi (MERGE/Upsert, călătorie în timp, instantanee).
Depozitare pe niveluri: cald/cald/rece + WORM pentru artefacte de reglementare.
Partiţionare: 'event _ date', 'market', 'chiriaş'; clustering/Z-ordine de predicate frecvente (utilizator/joc/furnizor).

4) Istoricul măsurătorilor (SCD)

SCD I: suprascriere - pentru editări non-critice.
SCD II: poveste completă; recomandat pentru RG/KYC/canale de trafic/atribute de joc.
SCD III: „înainte/după” - cazuri rare de comparație.

Exemplu SCD II:
sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. rg_status <> u. rg_status OR t. country <> u. country) THEN
UPDATE SET is_current = FALSE, valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED THEN
INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

5) Poveste de fapt: instantanee și bitemporal

Instantanee: un instantaneu de agregate de sfârșit de zi/lună (cum ar fi soldul portofelului) - accelerează re-crearea de rapoarte istorice.
Fapte bitemporale: fixați timpul de eveniment și timpul de procesare pentru a distinge remedierile târzii de calculele retrospective.
Istorie exactă: dedup by 'event _ id' + idempotent MERGE.

6) Călătoria în timp și reproductibilitatea

Călătorie în timp: tabele de lectură „la momentul T” pentru depanare, incidente, reconcilieri.
Versioning logic: artefacte de transformare (versiuni SQL/DBT, containere) și etichete „logic_version” în tabele de ieșire.
Ieșiri înghețate: artefacte de raportare de aur sunt capturate și nu rescrise, hash și jurnalul de export sunt disponibile.

Exemplu de cerere ca:
sql
SELECT
FROM silver. fact_bets VERSION AS OF 1678901234567
WHERE event_date = DATE '2025-10-31';

7) Backfill и Reprocesare

Backfill: Gama istorică primară/de preîncărcare.
Reprocesare: recalculare după fixarea bug-uri sau schimbarea regulilor de afaceri.

Gardereils:
  • Idempotency (MERGE/upsert), intervale, cote, uscat-rula cu comparație metrică.
  • Marcarea rezultatului: 'recalc _ reason', 'logic _ version', 'reprocesed _ at'.
Runbook:

1. Congela curent de aur; 2) DLQ/DQ verificare; 3) argint a alerga; 4) compararea măsurătorilor; 5) Aur reconstrui; 6) publicarea și semnarea.

8) Reconciliere

Sume de control: reconcilierea volumelor/cantităților de vânzare cu OLTP, PSP/furnizori.
Verificarea buclei: conductă independentă pe eșantion (comparație A/B).
Toleranțe cum ar fi discrepanța GGR ≤ 0. 2% pentru a doua zi.

Probe SQL:
sql
-- Duplicates
SELECT transaction_id, COUNT() c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

-- Unknown Currencies/Markets
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON r. code = p. currency
WHERE r. code IS NULL;

9) Valute, timp, calendar: corectitudine istorică

FX la data evenimentului: fixați 'fx _ rate _ used' și 'fx _ source'.
Ora locală a pieței: DST/Timezones via Calendar Directory.
Sărbători/sezonalitate: un tabel calendaristic separat, utilizat în modele și rapoarte.

Exemplu de normalizare FX:
sql
SELECT p. transaction_id,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
r. fx_source
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time) AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

10) PII, Conformitate și Legal Hold

Minimizare PII: pseudonimizare, cartografiere separată protejată.
DSAR/RTBF: proiecții calculabile și modificări selective ale straturilor istorice; excepțiile de stocare legală sunt documentate.
Legal Hold: steaguri „congela” ștergeri pe intervale/obiecte, WORM pentru artefacte raportabile.
Audit: acces imuabil și jurnale de export.

11) DQ și descendență pentru istorie

DQ-as-code (exemplu):
yaml table: silver. fact_bets slo:
completeness_percent: 99. 5 freshness_minutes: 60 rules:
- name: unique_bet type: unique columns: [bet_id]
severity: critical
- name: market_known type: in_set column: market set_ref: ref. markets
- name: ts_in_range type: temporal expression: "event_time BETWEEN date_sub(now(), interval 5 year) AND now()"

Lineage: fixați versiuni de intrări/transformări/ieșiri; graficul de dependență este necesar pentru retroformații.

12) Performanță și cost

Partiționare: după dată/piață/chiriaș; clustering agresiv prin 'user _ pseudo _ id'/' game _ id', dacă filtrăm des.
Formate: Parchet + statistici/compresie; ASPIRAȚI REGULAT/OPTIMIZAȚI.
Materializare: precompută pentru agregări istorice „scumpe”; instantanee pentru raportarea trimestrială/anuală.
Arhivare: conversia loturilor vechi în stocare la rece (SLA-urile pentru recuperare sunt documentate).
Eșantionare: numai pentru sarcini de cercetare, nu pentru reglementare/finanțe.

13) Caracteristici istorice pentru ML

Registrul caracteristicilor: fiecare caracteristică are o formulă, proprietar, SLO, 'model _ version'.
Consistență online/offline: o bază de cod de transformare, teste de repetabilitate.
Derivă caracteristică: PSI/KS în funcție de perioadă, stocarea distribuțiilor istorice.

14) Modele de interogare

Ca-of: reproductibilitatea rapoartelor.
Analiza cohortelor: cohorte de înmatriculări/prime depozite, ferestre rulante.
SCD II („event _ time BETWEEN AND COALESCE”).

Exemplu de alăturare cu SCD II:
sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

15) Procese și RACI

R (Responsabil): Ingineria datelor (modele/SCD/backfill), Platforma de date (ACID/arhivă), Finanțe/Conformitate (reconcilieri/cerințe de stocare).
A (Responsabil): șef de date/CDO.
C (Consultat): Legal/DPO (DSAR/RTBF/Legal Hold), SRE (cost/SLA), Arhitectură.
I (Informat): BI/Produs/Marketing/Operațiuni.

16) Foaia de parcurs privind implementarea

MVP (3-5 săptămâni):

1. Tabele ACID cu călătorie în timp (Delta/Iceberg/Hudi) și partiționare de bază.

2. SCD II pentru dimensiuni cheie (utilizatori/jocuri/furnizori).

3. Instantanee zilnice ale agregatelor critice (GGR Daily).

4. DQ-as-code (uniqueness/in_set/temporal) + descendență-grafic.

Faza 2 (5-10 săptămâni):
  • Fapte bitemporale, ca-de-șabloane API/SQL, runbooks backfill/reprocesare.
  • FX/calendar/DST-îmbogățire, OLTP↔DWH/provaydery reconcilieri.
  • Arhivare depozitare la rece, WORM pentru pachete de raportare, Legal Hold.
Faza 3 (10-16 săptămâni):
  • Automatizarea completă a „reluării și ce-dacă”, compararea metricii și a alertelor de regresie.
  • Caracteristici istorice și controlul derivei ML, chargeback pe costul de stocare.
  • Documentație „as-of” măsurători și rapoarte reproductibile.

17) Lista de verificare pre-vânzare

  • Tabelele suportă călătoria în timp; Politicile VACUUM/RETENTION sunt coerente.
  • SCD II este implementat pentru măsurători critice; Alăturați-vă testat.
  • Imaginile unităților cheie de pe D/M sunt disponibile și verificate cu paiete.
  • Regulile DQ sunt active; lineage afișează intrări/ieșiri și versiuni logice.
  • DSAR/RTBF/Legal Hold testat pe straturi istorice.
  • Arhivare de stocare la rece și de recuperare documentate și verificate.
  • Cost/GB, cotă rece, SLA de recuperare

18) Greșeli frecvente și cum să le evitați

Nu există un model de timp explicit: adăugați eveniment/procesare/valabilitate.
FX „retroactiv”: întotdeauna cursul la momentul evenimentului, stoca 'fx _ source'.
Invalid join's cu SCD: utilizați intervalul de valabilitate, not 'is _ current'.
Vitrine de aur mutante: ieșirile raportabile trebuie să fie imuabile (sau versionate).
Fără descendență/DQ: fără provabilitate și puncte de control - introduceți-le din prima zi.
Costul imposibil de gestionat: opriți petrecerile fierbinți, vidul, convertiți la rece.

19) Glosar

As-of Query - cerere de date "așa cum s-au uitat la momentul T.
Bitemporal - fixarea simultană a evenimentului și a timpului de procesare.
Instantaneu - instantaneu materializat de stare/agregate la sfârșitul perioadei.
Călătoria în timp - citirea versiunilor istorice ale tabelelor.
WORM - Scrie o dată citit multe.

20) Linia de jos

Lucrul cu datele istorice nu este doar „stocare lungă”, ci disciplina timpului: evenimente explicite/procesare/modele bitemporale, SCD și instantanee, reproductibile ca solicitări, reconcilieri riguroase și controale de conformitate, observabilitate și o arhitectură de stocare rentabilă. Urmând acest ghid, veți avea o bază istorică solidă pentru raportare, analiză și ML, care este rezistentă la audit și schimbări în logica de afaceri.

Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Telegram
@Gamble_GC
Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.