Linee di montaggio di analisi e ETL

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

La catena di montaggio analitico trasforma gli eventi operativi «crudi» (scommesse, depositi, webhoop PSP, fogli di gioco) in vetrine di metriche resistenti (GGR/NGR, LTV, retenschn, antifrode-segnali). I principi di riferimento sono un unico modello di strati (Bronze/Silver/Gold), la disciplina strumentale DQ/lineage, l'incrementalità e l'idimpotenza, l'osservabilità e lo SLO, il controllo del costo. Le decisioni vengono prese tenendo conto del profilo di carico (picchi di tornei), della regolazione (PII/localizzazione) e dei requisiti aziendali per la freschezza dei dati.

1) Architetture: ETL vs ELT, batch vs stream

ETL (Extract n'Form Load) - Trasformazioni prima del caricamento in DWH. Si adatta dove le trasformazioni richiedono un ambiente/segreto controllato fino alla nuvola.
ELT (Extract n'Load n'Form) - Materie prime in Lake/Lakehouse/DWH, segue SQL/motore (dbt/SQL-script). Comodo per motori invertebrati e iterazioni flessibili.
Batch: finestre pianificate (ogni 5/15/60 minuti, nightly). È economico e prevedibile.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). Per le vetrine near-real-time (5-60 secondi) e i segnali antifrode/CRM.
Ibrido: Bronze si riempie di striom, Silver/Gold sono modelli batch incrementali.

La raccomandazione è di mantenere ELT + streaming: eventi attraverso CDC/outbox Bronze (freschezza di minuti), trasformazioni incrementali in Silver/Gold.

2) Modello a strati (Medallion)

Bronze (Raw) - Eventi crudi/CDC senza logica aziendale. Formati Parquet/ORC, schemi come sono, convalida minima.
Silver (Conformed) - Pulizia, deduplicazione, normalizzazione degli identificatori, misurazione SCD, unificazione valuta/fuso orario.
Gold (Marts): vetrine aziendali (fatti/misurazioni, cubi), materializzi views, preagregazione (giorni/paesi/prodotti).

I vantaggi sono riproducibilità, evoluzione trasparente, SLO e TTL differenti per livello.

3) Sorgenti e caricamento: CDC, outbox, file

CDC (Change Data Capture) - Flussi di modifiche da OLTP (Postgres/MySQL) con garanzia di ordine e idampotenza.
Outbox-Pattern: gli eventi vengono registrati nella tabella/raccolta outbox nella transazione del servizio → Il connettore viene pubblicato nel bus/lago.
Download di file: download PSP, report di partnership utilizzare i manifesti, il controllo delle prese (checksum) e le cartelle di ricezione.

Pratiche: le sorgenti sono versionate (schema variante), ogni sorgente ha un contratto di campi e aspettative di qualità.

4) Orchestrazione: DAG, dipendenze, deposito

DAGI: dipendenze evidenti (raw → staging → dims → facts → marts).
Idemotività delle attività: ricarica senza effetti collaterali (partition-overwrite, 'MERGE '/upsert).
Separazione degli ambienti: Dave/Stage/Prod, promozione degli artefatti, porta manuale (manual approval) per i costosi backfill.
Pianificazione: cron/finestre temporanee + event-trigger (in arrivo file/partiture).
Segreti: da un segreto manager; divieto di segreti nel codice 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) Qualità dati (DQ) e lineage

Gli assegni DQ sono completi (count, late arrivals), unicità delle chiavi, intervalli/regole di dominio (importo ≥ 0, valuta nell'elenco).
Soglia di attivazione: arresto rigido/soft-fail con alert a seconda delle criticità della tabella.
Lineage/directory: da retro a origine (tabelle, colonne, metriche), proprietari, documentazione, classificazione PII.
Controllo diagrammi: test di compatibilità automatici (backward/forward-compatibile), alert per le modifiche «frammentarie».

6) Modellazione: SCD, surrogate keys, normalizzazione

SCD2 per le misure: 'valid _ from/valid _ to/is _ current', 'surrogate key' ('_ sk') e chiave naturale ('_ id').
SCD1 - Sovrascrivi per attributi irrilevanti (ad esempio, interfaccia locale).
Surrogate keys: stabili «_ sk» per join, naturale keys per esclusività.
Normalizzazione delle misure: snowflake dove le gerarchie sono profonde; Altrimenti, per la velocità.

7) Modelli incrementali e partizionamento

Filigrana («updated _ at», «ingest _ ts») - Consente di leggere solo le righe nuove o modificate.
Strategie incrementali: «MERGE» per le chiavi aziendali, «INSERT OVERWRITE» per le partenze, «DELETE + INSERT» per le partiture minori.
Partitura per data/ora/regione; clustering (fort keys/Z-order) tramite le chiavi di filtraggio e join.
Visualizzazioni materializzate: GGR/NGR, cache di sezioni popolari.
Aggregati approx: HLL/approx _ distinct per vetrine top-N a basso costo.

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, reprocessing e gestione della cronologia

Backfill: DAGI separati con limiti di risorse e finestre una «finestra chiara della verità» (ad esempio 2024-01-01-2025-11-05).
Riprocessing - Trasformazioni determinate e ripetizione danno lo stesso risultato. Logifica le versioni del codice modello.
Time-travel/versioni delle tabelle - Utile per le indagini e DR «errori logici».
Retrazione: criteri di revisione dei dati (rimozione/correzione) con il protocollo.

9) CLO/SLA/SLO

Freschezza (freshness): Bronze da 1 a 5 min, Silver da 15 min, Gold da 60 min (esempio).
Affidabilità: il tasso di successo dei test DAG è di 99. x%.
Prestazioni: p95/p99 durata nodi Budget del tempo per la partitura.
Monitoraggio di LAG: ritardo di ingest striam, profondità delle code, percentuale di late data.
Alterazione della freschezza/volume, DQ, aumento del costo delle scale, degrado MV.

10) Costo: previsione e ottimizzazione

Partenze e cluster riducono al minimo il volume delle scene.
Materializzazione dei marcatori caldi (giorni/paesi/prodotti).
Cache dei risultati/MVs per i dashboard utilizzati di frequente.
Controllo della frequenza di riavvio (nessun «ogni 5 minuti» senza motivo).
TTL: Retenschn Bronze aggressiva, media Silver, lunga Gold (solo unità).
Capacity planning - metriche in catalano, previsioni di picchi di tornei/campagne.

11) Sicurezza, PII e localizzazione

Classificazione dei dati: PII/finanziari/operativi.
Crittografia in pace e in transito; KMS/ruolo di accesso basato.
ID: hash/masking, singole colonne con chiavi.
RLS/wuhi per la multi-tenenza (in tenant _ id).
Localizzazione: aree di storage e elaborazione per regione (EU/TR/LATAM); esportare solo in località autorizzate.
Controllo: lettura/scrittura in tabelle critiche, accesso alla directory.

12) Osservabilità: metriche, fogli, roulotte

Metriche della catena di montaggio: durata delle operazioni, coda, errori, retrai, quantità di byte/righe elaborate, costo.
Logi strutturati; correlazione «trace _ id »/« run _ id».
Tracing: dalla sorgente alla vetrina (ingest n'express n'load "BI).
Dashboard: freschezza strati, successo DAGov, richieste top-care, p95/p99.

13) Strumenti (punti di riferimento per ruolo)

Orchestrazione: orchestratori DAG (con pianificatore, retrai, alert, segreti).
Trasformazioni: modellazione SQL (modelli come codice), test unit dei modelli, documentazione.
DQ/contratti: cornici di controllo e SLA per set di dati.
Lineage/directory: creazione automatica del grafico delle dipendenze, ricerca del proprietario.
Streaming: processori di finestre/aggregazioni, connettori sonk/source.

(I venditori specifici vengono selezionati con lo stack aziendale e i requisiti di sicurezza).

14) Esempi di modelli

Modello di vetrina GGR (generalizzato 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;

Modello incrementale con filigrana

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

Controlli DQ (idea)

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) Assegno-foglio di implementazione

1. Definire il dizionario delle metriche (GGR/NGR/LTV/Retention) e i proprietari.
2. Fissa la freschezza SLO sui livelli Bronze/Silver/Gold.
3. Standardizzare i contratti di origine (schemi, DQ, SLA).
4. Costruite un DAG con passaggi idimpotenti e segreti isolati.
5. Implementare incrementalità (MERGE/overwrite per partitura) e filigrana.
6. Includere DQ (controlli critici/soft), lineage e directory dati.
7. Regolare l'osservabilità (metriche, fogli, roulotte) e gli alert.
8. Inserisci il retensch/TTL e il criterio backfill/reprocessing.
9. Controllo PII, crittografia, RLS e localizzazione.
10. Fai clic su game-day per simulare la caduta di sorgenti, diagrammi di rottura, backfill di massa.

16) Antipattern

«Un ETL notturno per tutto» senza partenze e incrementalità.
L'assenza di DQ e lineage → i rapporti in conflitto e la caccia ai fantasmi.
Rielaborazione completa delle tabelle a ogni avvio (esplosione del costo).
Legatura rigida in tempo reale senza buffer/retrai.
Miscelare PII e vetrine pubbliche senza segmentare e mascherare.
Nessun criterio retrazione/rimozione (impossibile correggere gli errori).

Riepilogo

Una catena di montaggio resistente nel iGaming è ELT + caricamento in streaming su un modello a strati con DQ/lineage rigido, modelli incrementali, orchestratore trasparente e SLO misurabili. Aggiungi il controllo dei costi, la politica PII/localizzazione, i regolari backfill/DR-esercizi - e la piattaforma di analisi sarà scalabile in modo affidabile sotto i picchi del torneo, rispondendo alle aziende con i dati di freschezza e qualità.