Analiză și conducte ETL

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Conducta analitică transformă evenimentele operaționale iGaming „brute” (pariuri, depozite, carti web PSP, jurnale de joc) în vitrine metrice stabile (GGR/NGR, LTV, retenție, semnale antifraudă). Principii de susținere: un model cu un singur strat (Bronze/Silver/Gold), disciplina instrumentală DQ/descendență, incrementalitate și idempotence, observabilitate și SLO, controlul costurilor. Deciziile sunt luate ținând cont de profilul de încărcare (vârfuri de turneu), de reglementare (PII/localizare) și de cerințele de afaceri pentru prospețimea datelor.

1) Arhitecturi: ETL vs ELT, lot vs stream

Extract → transforma → Load-transformă înainte de încărcare în DWH. Potrivit în cazul în care transformările necesită un mediu controlat/secrete înainte de „nor”.
ELT (Extract → Load → Transforme): materii prime în Lake/Lakehouse/DWH, apoi SQL/motor (scripturi dbt/SQL). Convenabil pentru motoare coloană și iterații flexibile.
Lot: ferestre programate (la fiecare 5/15/60 minute, noapte). Ieftin şi previzibil.
Stream: почти în timp real (Kafka → Flink/ksqlDB → OLAP). Pentru ferestre aproape în timp real (5-60 secunde) și semnale antifraudă/CRM.
Hibrid: Bronz se umple cu flux, Silver/Gold - modele incrementale de lot.

Recomandare: în iGaming păstrați ELT + streaming: evenimente prin CDC/outbox → Bronze (prospețime minut), transformări incrementale în Silver/Gold.

2) Medalion

Bronz (Raw): Evenimente brute/CDC fără logică de afaceri. Formate de parchet/ORC, scheme ca este, validare minimă.
Argint (Conform): curățare, eliminare a duplicatelor, normalizare ID, SCD dimensiune, unificare valută/fus orar.
Aur (Marts): cazuri de afaceri (fapte/dimensiuni, cuburi), vizualizări materializate, preagregări (zile/țări/produse).

Pro: reproductibilitate, evoluție transparentă, SLO-uri diferite și TTL-uri pe straturi.

3) Surse și încărcare: CDC, outbox, fișiere

CDC (Change Data Capture): schimbarea fluxurilor din OLTP (Postgres/MySQL) cu ordine garantată și idempotență.
Modelul outbox: evenimentele sunt scrise la tabelul/colecția outbox în tranzacția de servicii pe → conectorul o publică la autobuz/lac.
Încărcarea fișierelor: încărcări PSP, rapoarte partenere; utilizați manifestele, suma de control și primiți directoare.

Practici: sursele sunt versionate (versiunea schemei), pentru fiecare sursă - un contract de domenii și așteptări de calitate.

4) Orchestrație: DAG, dependențe, implementare

DAG-uri: dependențe explicite (prime → stadializare → dims → fapte → marte).
Idempotență sarcină: reluare fără efecte secundare (partiție-suprascriere, „MERGE ”/upsert).
Separarea mediilor: Dev/Stage/Prod, promovarea artefactelor, „aprobarea manuală” pentru rambursarea costisitoare.
Programare: ferestre cron/time + declanșatoare de evenimente (în funcție de sosirea fișierelor/părților).
Secrete: de la managerul secret; interzicerea secretelor în codul DAG.

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5) Calitatea datelor (DQ) și descendența

Verificări DQ: completitudine (număr, sosiri târzii), unicitatea cheilor, intervale/reguli de domeniu (sumă ≥ 0, monedă în director).
Pragul de declanșare: hard stop/soft-fail cu alertă în funcție de criticalitatea tabelului.
Descriere/catalog: de la raport la sursă (tabele, coloane, metrici), proprietari, documentație, clasificare PII.
Controlul schemei: teste automate de compatibilitate (compatibile cu spatele/înainte), alertă pentru „spargerea” modificărilor.

6) Simulare: SCD, chei surogat, normalizare

SCD2 pentru dimensiuni sunt "valid _ from/valid _ to/is _ current', cheia surogat ('_ sk') și cheia naturală ('_ id').
SCD1-Overwrites pentru atribute minore (de exemplu, interfață locală).
Chei surogat: stabil '_ sk' pentru alăturare, chei naturale pentru unicitate.
Normalizarea dimensiunii: fulg de zăpadă unde ierarhiile sunt adânci; altfel stea pentru viteză.

7) Modele incrementale și partiționare

Filigran ('update _ at', 'ingest _ ts'): citiți doar linii noi/modificate.
Strategii incrementale: „MERGE” prin taste de afaceri, „INSERA SUPRASCRIE” prin loturi, „ȘTERGE + INSERA” pentru loturi mici.
Partiționare: după dată/oră/regiune; clustering (sort keys/Z-order) prin filtrarea și alăturarea cheilor.
Vizualizări materializate: preagregarea GGR/NGR, memoria cache a secțiunilor populare.
Unități aproximative: HLL/approx_distinct pentru vitrine ieftine de top-N.

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8) Backfill, reprocesare și gestionarea poveștilor

Backfill: DAG-uri individuale cu limite de resurse și ferestre; o „fereastră clară a adevărului” (ex. 2024-01-01.. 2025-11-05).
Reprocesarea: transformările deterministe → rulajele repetate dau același rezultat. Versiuni de logare ale codului modelului.
Versiuni de călătorie în timp/masă: convenabil pentru investigații și DR „erori logice”.
Retracție: retrage (șterge/repara) politica cu logare.

9) Transportor CLO/SLA/SLO

prospețime: bronz ≤ 1-5 min, argint ≤ 15 min, aur ≤ 60 min (exemplu).
Fiabilitate: rata de trecere DAG ≥ 99 x%.
Performanță: durata nodului p95/p99; bugetul de petrecere a timpului.
Monitorizarea decalajului: decalajul fluxului ingerat, adâncimea cozii, cota de „date târzii”.
Alerte: încălcarea prospețimii/volumului, fișiere DQ, creșterea costului scanărilor, degradarea MV.

10) Cost: prognoză și optimizare

Partițiile și clusterele minimizează volumul de scanare.
Materializarea markerilor calzi (zile/țări/produse).
Rezultate cache/MV-uri pentru tablouri de bord utilizate frecvent.
Frecvența de repornire a monitorului (fără „la fiecare 5 minute” fără motiv).
TTL: retenție agresivă de bronz, argint mediu, aur lung (numai agregate).
Planificarea capacității: măsurători de catalog, previziuni de turnee/campanii.

11) Siguranță, PII și localizare

Clasificarea datelor: PII/financiar/operațional.
Criptare: în repaus și în tranzit; KMS/acces bazat pe roluri.
De-identificare: hashing/mascare, coloane separate cu taste.
RLS/viscol pentru multi-chiriași (prin "chiriaș _ id').
Localizare: zone de depozitare si procesare pe regiuni (EU/TR/LATAM); export numai în locații permise.
Audit: citește/scrie la tabele critice, acces director.

12) Observabilitate: valori, busteni, trasee

Măsurători de conducte: durata sarcinii, coadă, erori, retribuții, octeți/rânduri prelucrate, cost.
Busteni: structurat; corelație pe 'trace _ id'/' run _ id'.
Urmărirea: de la sursă la vitrină (ingerarea → transformarea sarcinii → → BI).
Tablouri de bord: prospețimea straturilor, succesul DAG-urilor, cererile scumpe de top, p95/p99.

13) Instrumente (repere de rol)

Orchestrație: orchestratori DAG (cu programator, retravertizări, alerte, secrete).
Transformări: modelare SQL („modele ca cod”), teste unitare de modele, documentație.
DQ/contracte: cadre de validare și SLA pe seturi de date.
Lineage/Catalog: grafic de dependență automată, găsiți proprietarul.
Streaming: procesoare de ferestre/agregare, conectori chiuvetă/sursă.

(Furnizorii specifici sunt selectați pentru cerințele de stivă și securitate ale companiei.)

14) Șabloane de probă

Șablon de prezentare GGR (Generic SQL)

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

Model filigranat incremental

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

DQ verificări (idee)

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15) Lista de verificare a implementării

1. Definiți dicționarul metric (GGR/NGR/LTV/Retention) și proprietarii.
2. Înregistrați prospețimea SLO în straturile de bronz/argint/aur.
3. Standardizarea contractelor sursă (scheme, DQ, SLA).
4. Construiți un grafic DAG cu pași idempotenți și secrete izolate.
5. Implementați incrementalitatea (MERGE/suprascrie de partid) și filigrane.
6. Includeți DQ (verificări critice/soft), descendență și directorul de date.
7. Configurați observabilitatea (valori, busteni, trasee) și alerte.
8. Introduceți politica de retenție/TTL și rambursare/reprocesare.
9. Furnizați control PII, criptare, RLS și localizare.
10. Petreceți ziua jocului: imitarea unei căderi de sursă, scheme de „rupere”, rambursare în masă.

16) Antipattern

„One Night ETL for Everything” fără petreceri și fără incrementalitate.
Lipsa de DQ și descendență → rapoarte contradictorii și vânătoare de fantome.
Revizuirea completă a tabelelor la fiecare lansare (explozia costurilor).
Pachet greu în timp real, fără tampoane/retrase.
Amestecarea PII și a magazinelor publice fără segmentare și mascare.
Nicio politică de retracție/ștergere (erorile nu pot fi corectate).

Rezumat

Conducta de analiză robustă din iGaming este încărcarea în flux ELT + într-un model stratificat cu DQ/linie dură, modele incrementale, orchestrator transparent și SLO-uri măsurabile. Adăugați control al costurilor, politica PII/localizare, exerciții regulate de backfill/DR - iar platforma analitică va scala în mod fiabil la vârfurile turneului, răspunzând la afaceri cu date de prospețimea și calitatea dorită.