Archivi dati e modelli OLAP

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Lo storage dei dati (DWH) è uno strato di riferimento degli analisti di iGaming: rapporti ai regolatori, redditività dei prodotti/mercati, LTV coorte, antifrode, segmentazione CRM e dashboard real-time. Il DWH sostenibile si basa su un modello di dati chiaro (Star/Snowflake/Data Vault), integrazione affidabile (ETL/ELT + CDC), prestazioni elaborate (motori a rotelle, partizioni, MVs), semantica rigorosa delle metriche, sicurezza/PI e gestione dei costi.

Approcci architettonici

DWH classico (Kimball vs Inmon)

Kimball (Dimensional/Star/Snowflake): vetrine di report veloci; focus su fatti e misure, storia SCD. Tempo veloce.
Inmon (Corporate Information Factory) - Nucleo normalizzato + vetrina più difficile in termini di tempo, ma rigorosamente e centralmente.

Data Vault 2. 0

Hubs-Links-Satellites è un modello scalabile «crudo» per l'integrazione delle origini e il controllo delle modifiche. Le vetrine della Star sono in costruzione.

Data Lake / Lakehouse

File crudi (Parket/ORC) + directory (Hive/Glue/Unity/Metastore).
Lakehouse è un unico livello per batch/stream, ACID (Delta/Iceberg/Hudi), time-travel, upsert/merge, file compatti, Z-order/Clustering.

Medallion (Bronze–Silver–Gold)

Bronze: dati crudi (raw) + CDC.
Silver pulito e conformato.
Gold: vetrine aziendali/metriche/cubi.
Adatto per ibridi (Kafka n'Bronze; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).

Modelli OLAP: Star, Snowflake, Data Vault

Star Schema (star)

Le tabelle fact sono transazioni (tassi, depositi, sessioni).
Dimensions: giocatore, gioco, provider, data/ora, geo, canale di attrazione.
Vantaggi: gioielli semplici, prestazioni prevedibili.

Snowflake

Normalizzazione delle misure (gerarchie di paesi/regioni/città, gerarchia dei prodotti).
Più: meno duplicazione; meno, più gioielli.

Data Vault → Star

I cambiamenti crudi vengono ripiegati in DV (verifiche, riproducibilità totale), le vetrine di report sono costruite come Star/Snowflake.

Integrazione: ETL/ELT, CDC, modifiche lente

Pipline

Outbox/CDC di OLTP ( ) Kafka/connettori di Bronze.
ELT: pulizia, deadup, normalizzazione in Silver.
Logica aziendale e aggregazioni in Gold/vetrine.

SCD (Slowly Changing Dimensions)

Type 1 - Sovrascrivi (per campi irrilevanti).
Type 2 - Storytelling (versioni datate) - standard per profili/canali/prezzi.
Type 3 - Memorizzazione di una coppia di valori (raramente).

sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;

-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;

Livelli semantici e metriche «vere»

Immettere un unico livello di metriche (semantic layer): definizioni GGR, NGR, Net Deposits, ARPPU, LTV, Churn, Retention Cohorts.
Le metriche come codice (dbt metrics/LookML/Semantic Layer) → le stesse formule in tutti i report.
Calendario: tabella di date/ore con attributi TZ/regioni/fine settimana/campagne.

Archivi e motori - Seleziona sotto il profilo

Invertebrati e cloud DWH

ClickHouse: scansioni/aggregazioni ultra veloci, rappresentazioni materializzate, proiezioni; diverso per eventi/telemetria e vetrine di marketing.
BigQuery: server, zoom, cache automatica/cluster Prezzo per scansione; Comodo per carichi misti e ad hoc.
Snowflake: reparto compute/storage, cluster su richiesta, time-travel; trasparente per comandi diversi.
Redshift/Vertica/Pinot/Druid: opzioni sotto OLAP/real-time.

Sintonizzazione sotto il profilo

Partizionamento per data/regione/canale.
Clustering/ordinamento per chiave di filtraggio/gioiello.
Compressione e codifica con dizionario.
Preagregazione (rollup, cubes), rappresentazioni materializzate.
Funzionalità Approx (HyperLogLog/approx_distinct) per valutazioni a basso costo.

Progettazione delle prestazioni

Partizionamento e clustering

La partitura è il limite dell'alloggiamento. Partenze diurne/orarie per eventi.
Clustering (fort keys/Z-order) - Accelera gli intervalli e i join.

Viste materializzate (MV)

Pre-conteggio GGR/NGR per giorno/paese/prodotto.
Aggiornamento incrementale dallo striam CDC.

sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win)  AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;

Modelli incrementali (dbt/ELT)

Strategie «insert _ overwrite» per le partenze, «merge» per le chiavi CDC, «watermark» per «updated _ at».

Strategie join

Replica delle misurazioni in ciascun segmento partitico (denorm).
Broadcast small dims; shuffle larghe facts con ordinamento per chiave.

Costi: controllo e ottimizzazione

BigQuery/Snowflake: limitare le dimensioni dello scan (progettare partiture/cluster), includere result cache/materialization views, limitare le ricerche auto BI.
ClickHouse: dimensioni delle partiture, frequenza dei merjay, budget per deposito (TTL per eventi crudi, aggregazioni durature).
La semantica delle metriche riduce i calcoli «doppi».
Data pruning - Ritocco per Bronze, aggregazione per Gold.

Qualità dati (DQ), directory, lineage

Assegni DQ: completezza (completeness), esclusività, intervalli, regole aziendali (ad esempio, GGR 0).
Data Catalog & Lineage: descrizioni delle tabelle/campi, proprietari, classificazione PII, traccia dal report all'origine.
Controllo diagrammi: contratto eventi/CDC, alert in caso di modifiche incompatibili.

Sicurezza, compliance e multi-tenenza

Segmentazione PII: zone separate, maschera/alias, colonne con crittografia KMS.
RBAC/ABAC: ruoli a livello di progetto/diagramma/tabella/riga (RLS), wuhi per «need-to-know».
Localizzazione dei dati: buckets/warehouses regionali (EU/TR/LATAM).
Controllo accesso: chi ha letto/cambiato vetrine e modelli.

DR, backup e riproduzione

Versioning del codice dati (dbt/git), dell'ambiente Dave/QA/Prod.
Snapshot metastore/catalogo + versioning tabelle (time-travel).
Retenschn/TTL strati Bronze/Silver/Gold; esportazione di vetrine critiche.
Game-day - Ripristina le vetrine, controlla l'integrità delle metriche.

Real-time e vetrine ibride

Stream-to-OLAP: Kafka per vetrine di minuti.
Materialization views + CDC per aggiornamenti quasi online (5-15 min).
Il livello semantico rimane uno solo: le metriche sono identiche in real-time e batch.

Esempio di vetrina «GGR per giorni e paesi» (generalizzato da SQL)

sql
CREATE TABLE fact_bets (
bet_id   BIGINT,
player_sk BIGINT,
game_sk  BIGINT,
country_sk BIGINT,
stake   DECIMAL(18,2),
win    DECIMAL(18,2),
ts     TIMESTAMP
) PARTITION BY DATE(ts);

CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2    STRING,
region   STRING,
valid_from TIMESTAMP,
valid_to  TIMESTAMP,
is_current BOOL
);

-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win)  AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;

Assegno foglio di implementazione

1. Definire le origini e i domini e fissare il dizionario delle metriche.
2. Selezionare il modello DV per i livelli crudi/auditi + Star per le vetrine.
3. Progettare particelle/cluster per le richieste e le finestre chiave.
4. Configurare CDC/ELT, criteri SCD e surrogate keys.
5. Immettere un livello semantico (metriche come codice) e un calendario di date/ore.
6. Creare MVs/preagregazione per report costosi.
7. Abilita DQ/directory/lineage e il controllo degli schemi.
8. Definire RBAC/PII/localizzazione, crittografia, controllo.
9. Regolare il monitoraggio p95/p99, il costo, gli alert sul degrado e il sovraccarico.
10. Esercitazioni DR regolari e riproducibilità degli ambienti.

Antipattern

«Un fatto gigantesco senza partenze», scansioni di terabyte e conto in aumento.
Definizioni di metriche incoerenti in diversi dashboard.
La mancanza di SCD2 dove gli affari richiedono storia.
Normalizzazione prematura delle misurazioni: gioielli superflui e rapporti lenti.
Dati crudi senza assegni DQ e lineage → i rapporti «niente».
Mancanza di reticenza/TTL, deposito di rifiuti e esplosione del costo.

Riepilogo

Un iGaming-DWH robusto è un modello (DV→Star), un unico dizionario di metriche, corrette partizioni/clustering, vetrine materializzate, DQ/lineage rigorosi e RBAC/PII/localizzazione. Aggiungi uno streaming ibrido per la freschezza, gestito da ELT e disciplina del costo - e ottieni una piattaforma di analisi sostenibile che si scalerà per tornei, rapporti regolatori e studi ad hoc senza sorprese in p99 e budget.