Utilizzo dei dati storici

1) Assegnazione e principi

Scopo: conservare e gestire gli stati passati in modo che i rapporti, i modelli e le indagini siano riproduttivi, precisi e complessi.

• Time-aware by design - Modelli temporali espliciti nei diagrammi e nelle query.
• Ripartibilità: lo stesso report per data D dà sempre lo stesso risultato.
• Auditability - Origine provata (lineage), livelli invariati, WORM dove si desidera.
• Cost-aware - Livelli archiviati, compressione, cold storage con SLA comprensibili.
• Privacy-by-design - Gestione del PII per le operazioni retrospettive e le richieste legali.

2) Modelli di tempo

Event-time: ora dell'evento effettivo (tasso, deposito).
Processing-time - Quando il sistema ha elaborato il record (potrebbe essere diverso).
Bitemporal - Memorizzazione e event e processing time per le modifiche a posteriori.
Intervalli validity: 'valid _ from', 'valid _ to', 'is _ current'.
As-of queries - Un campione di dati «come sapevano al momento T».

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) Livelli di storage e formati

Lakehouse: Bronze (raw append-only) → Silver (clean/SCD/normalizzazione) → Gold (vetrine).
ACID-форматы: Delta/Iceberg/Hudi (MERGE/Upsert, time-travel, snapshots).
Tiered storage: hot/warm/cold + WORM per gli artefatti di regolazione.
Partitura: «event _ date», «market», «tenant»; clustering/Z-order per predici frequenti (user/game/provider).

4) Storializzazione misurazione (SCD)

SCD I: sovrascrivi - per modifiche non ritritiche.
SCD II: storia completa; raccomandato per RG/KYC/canali di traffico/attributi di gioco.
SCD III è una valigetta di confronto rara.

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) Storia dei fatti: immagini e bitemporale

Snapshots - Snapshots a fine giorno/mese (ad esempio, bilanciamento del portafoglio) - Consente di ripristinare i report storici.
Dati Bitemporal - Fissiamo event-time e processing-time per distinguere le correzioni tardive dai calcoli retrospettivi.
Storia di Exactly-once - Deadup per «event _ id» + Idempoted MERGE.

6) Time-travel e riproduzione

Time-travel - Lettura di tabelle al momento T per debug, incidenti, fustigazioni.
Versioning logica: artefatti di trasformazione (SQL/DBT, contenitori) e etichette logic _ variante nelle tabelle di output.
Frozen outputs: Gli artefatti Gold Report vengono registrati e non scritti, è disponibile hash e registro di esportazione.

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

7) Backfill и Reprocessing

Backfill è una gamma storica primaria/ridimensionata.
Riprocessing: riconteggio dopo la correzione dei bagagli o la modifica delle regole aziendali.

• Idampotenza (MERGE/upsert), intervalli, quote, prova scura (dry-run) con confronto delle metriche.
• Marciamo il risultato: 'recalc _ reason', 'logic _ version', 'reprocessed _ at'.

1. Freeze corrente Gold; 2) controllo DLQ/DQ; 3) ricerca Silver; 4) confronto delle metriche; 5) intersezione Gold; 6) pubblicazione e firma.

8) Incroci di precisione

Checkpoint: comprimere giri/quantità con OLTP, PSP/provider.
Controllo a due contorni: pipeline indipendente nel campione (A/B confronto).
Tolleranze: ad esempio, ≤ GGR 0. Il 2% al giorno.

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, tempo, calendario: correttezza storica

FX data evento: registriamo «fx _ rate _ used» e «fx _ source».
Data di mercato locale: DST/Timsons tramite l'elenco dei calendari.
Festività/stagionalità: tabella del calendario separata, utilizzata nei modelli e nei report.

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, compagine e Legale Hold

Minimizzazione PII: alias, mapping protetto separato.
DSAR/RTBF: proiezioni calcolate e modifiche selettive ai livelli storici sono documentate eccezioni per il legittimo dovere di conservazione.
Legale Hold - Flag di cancellazione per intervalli/oggetti, WORM per gli artefatti di report.
Controllo: fogli di disponibilità ed esportazione invariati.

11) DQ e lineage per la cronologia

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: registriamo le versioni di ingressi/trasformazioni/uscite; Il conte delle dipendenze è obbligatorio per i ritocchi.

12) Prestazioni e costi

Partitura per data/mercato/tenante; clustering aggressivo con'user _ pseudo _ id '/' game _ id ', se spesso filtrato.
Formati: Parquet + statistica/compressione; VACUUM/OTTIMIZE regolare.
Materializzazione: precompute per aggregazioni storiche «costose»; snap per i rapporti su base trimestrale/annuale.
Archiviazione - La traduzione delle vecchie partiture in cold storage (SLA per il ripristino) è documentata.
Solo per attività di ricerca, non per regolazione/finanza.

13) Fischi storici per ML

Feature registry: ogni fiocco ha la formula, owner, SLO, model _ variante.
Coerenza online/offline: una base di trasformazioni in codice, test di reimpostazione.
La deriva dei segni è PSI/KS per periodi, conservazione delle distribuzioni storiche.

14) Pattern di query

As-of (data) - Riproduzione dei report.
Cohort-analisi - coorti di registrazione/primi depositi, rolling finestre.
Slowly changing facts: корректные join’ы с SCD II (`event_time BETWEEN valid_from AND COALESCE(valid_to, '9999-12-31')`).

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) Processi e RACI

R (Respontible): Data Engineering (modelli/SCD/backfill), Data Platform (ACID/archivio), Finance/Compliance (Crocifissioni/Requisiti di conservazione).
A (Accountable): Head of Data/CDO.
C (Consulted): Legale/DPO (DSAR/RTBF/Legale Hold), SRE (costo/SLA), Architettura.
I (Informed): BI/Prodotto/Marketing/Operazioni.

16) Road map di implementazione

1. Tabelle ACID con time-travel (Delta/Iceberg/Hudi) e partizionamento di base.

2. SCD II per le misure chiave (users/games/provider).

3. Snapshots giornalieri di unità critiche (GGR Daily).

4. DQ-come-codice (uniqueness/in _ set/temporale) + lineage-grafico.

• Dati Bitemporal, as-of API/modelli SQL, runbooks backfill/reprocessing.
• FX/calendario/arricchimento DST, OLTP↔DWH/provaydery.
• Archiviazione di cold storage, WORM per pacchetti di report, Legale Hold.

• Automazione completa «replay & what-if», confronto tra metriche e alert di regressione.
• Fitte storiche e il controllo della deriva ML, il chargeback per il costo di conservazione.
• Documentazione «as-of» delle metriche e dei report riprodotti.

17) Foglio di assegno prima della vendita

• Le tabelle supportano time-travel; i criteri VACUUM/RETENTION sono coerenti.
• SCD II è implementato per misurazioni critiche; join's testati.
• Le istantanee degli aggregati chiave su D/M sono disponibili e verificate in base ai controlli.
• Le regole DQ sono attive; lineage visualizza le entrate/uscite e le versioni della logica.
• DSAR/RTBF/Legale Hold sono stati testati su livelli storici.
• L'archiviazione e il ripristino da cold storage sono documentati e convalidati.
• Costo di conservazione sotto controllo (cost/GB, quota cold, SLA ripristino).

18) Errori frequenti e come evitarli

Nessun modello temporale esplicito: aggiungi event/processing/validity.
FX «retroattivo»: sempre corso al momento dell'evento, memorizzare «fx _ source».
join's con SCD non validi: usa l'intervallo di validità anziché 'is _ current'.
Vetrine Gold mutanti: le uscite di report devono essere invariate (o con versioning).
Senza lineage/DQ: nessuna prova né punti di controllo - inseriscili dal primo giorno.
Costo fuori controllo: disattiva le partenze calde, svuota, trasferisci in cold.

19) Glossario

As-of Query - La richiesta di dati «come erano al momento T».
Bitemporal - Fissa simultaneamente event e processing time.
Snapshot è un'immagine materializzata dello stato/aggregazione alla fine del periodo.
Time-travel - Lettura delle versioni storiche delle tabelle.
WORM - Storage invariato (Write Once Read Many).

20) Totale

I dati storici non sono solo «conservazione a lungo termine», ma una disciplina del tempo: modelli espliciti di event/processing/bitemporal, SCD e snapshots, replucable as-of query, rigorosi controlli di incrocio e compliance, osservabilità e architettura di storage a basso costo. Seguendo questa guida, si otterrà una solida base storica per la segnalazione, gli analisti e ML, resistente alla verifica e al cambiamento della logica aziendale.