Laghi di dati e aggregazione dei flussi

1) Assegnazione e valore

• I flussi da prodotti/giochi/pagamenti atterrano a Bronze «com'è».
• Silver normalizza e arricchisce fornendo chiavi e qualità coerenti.
• Gold è una vetrina aggregata (tra cui real/near-real-time) per BI, regolatori, antifrode/RG.

L'aggregazione dei flussi su Lakehouse offre un basso ritardo nei rapporti, costi prevedibili, riproducibilità e forensistica.

2) Architettura arbitrale

1. Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).
2. Bronze (append-only): magazzino oggetti + ACID (Delta/Iceberg/Hudi), partiture by date/market/tenant; storage del payload originale.
3. Stream Compute: Flink/Spark/Beam - unità a finestre, CEP, deadup, online-lookups.
4. Silver (clean/conform) - Regolazione delle valute/timesone, FK/riferimenti, SCD per le misurazioni.
5. Serving/OLAP: ClickHouse/Pinot/Druid - Apparecchiature da minuti/secondi materializzate per i pannelli.
6. Gold (serve) - Vetrine diurne/orarie, tagli regolatori, pacchetti di esportazione invariati (WORM).
7. Tracciati di controllo: Schema Registry, codice DQ-come, lineage, directory, segreti/KMS, RBAC/ABAC.

3) Contratti e schemi

Schema-first: JSON/Avro/Protobuf; campi obbligatori: 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market', 'schema _ version'.
Evoluzione: back-compatibile per aggiungere nullable; breaking '/v2 '+ doppia voce.
Cartella descrizione dominio, proprietario, freschezza SLA, regole DQ, lineage.

4) Atterraggio dei flussi nel lago

Exactly-once sul fondo: at-least-once pubblicazione + idempoted sink (MERGE/upsert a «event _ id»).
stateful in strim + unicità in Silver.
Compagine di file: small files → OTTIMIZE/VACUUM regolari per la lettura e il costo.
Time-travel include debug, repliche e verifiche.

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5) Aggregazione flussi: finestre e watermarks

• Tumbling è fisso (ad esempio, 1 min/5 min) per pannelli stabili.
• Hopping - sovrapponibili (passo
• Sessione è una rottura comportamentale per inattività.
• Watermarks - Gestione late data (generalmente 2-5 minuti), regole di preemissione/correzione.

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6) Materializzazione delle unità

Motore OLAP (ClickHouse/Pinot/Druid) - Memorizza unità minuti/secondi per dashboard e analisi operative.
Lakehouse Gold memorizza i tagli giornalieri/orari per la segnalazione e la riproduzione.

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7) Silver: normalizzazione e negoziazione

Ora e valuta: 'event _ time (UTC)', 'amount _ basé,' fx _ rate _ used ',' fx _ source '.
Chiavi/guide: «user _ pseudo _ id», «game _ id», «provider _ id», «market».
SCD II: storiizzazione delle misurazioni (users/games/provider/RG/KYC).
Regole DQ: unicità delle chiavi, guide, intervalli di importo, temporale-validità.

8) Registro delle apparecchiature e definizioni «corrette»

Semantic Layer: singole formule GGR/NGR, scommesse/vincite, conversione, ARPPU, latency p95.
Versioning delle metriche: «metric _ variante» e «as-of» del calcolo.
Carte doc: owner, formula, fonti, SLA pronto.

9) Exactly-once/idampotenza e ordine

Bus: at-least-once + partizionamento (ordine locale).
Elaborazione: deadup dì event _ id "(TTL 24-72h), operatori CER/finestre con regolazioni.
Sink: committenti transazionali o idempotent upsert/merge.
Outbox/Inbox - Pubblica eventi di dominio da OLTP con garanzia.

10) Late data e regolazioni

Allowed lateness: 2-5 min per le vetrine operative; sovrapprezzi giornalieri per la Gold.
Regolazioni: preemissioni in OLAP e ridisegnazione Gold (idempotent).
I flag sono «late = true», «correction _ of = <event _ id>» per il controllo.

11) Osservabilità e DQ

• p95 - min vetrina 2-5 c; Gold daily è pronto entro le 6:00.
• Completeness ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Metriche di pipeline: lag/throughput/busy time/state size, late-ratio, dup-rate.
• DQ-Dashboard: Freshness/Completeness/Validity, vortice di perdita, mappa delle chiavi hot.
• Lineage: percorso da Bronze a Gold/export; Analisi impact in caso di modifiche.

12) Privacy, residenza, sicurezza

Minimizzazione PII: alias, mapping protetto separato.
Residency: EEA/UK/BR - singole directory e chiavi di crittografia Vietare i join'ov crocifissori senza fondamento.
Crittografia: TLS in-transit; KMS/CMK at-rest; firma di esportazione + WORM durante la regolazione.
DSAR/RTBF/Legale Hold: modifiche selettive, congelamento delle cancellazioni, accessibilità verificabili.

13) Prestazioni e costi

Partitura per data/mercato/tenante; clustering/Z-order per attributi spesso filtrati.
Compattazione: eliminazione di small files, OTTIMIZE/VACUUM regolare.
Materializzazione: minuti/secondi in OLAP; 24 ore al Gold.
Tiered storage: hot/warm/cold, SLA di ripristino, conformeback per comando (cost/GB, cost/query).
Preagregazione/sketch, HyperLogLog/approx-distinct dove è accettabile.

14) Esempi (sezioni)

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15) Processi e RACI

• Platform data (Lakehouse/directory/ACID, compagine),
• Streaming (unità/CEP/dedup),
• Domain Analytics (metriche/Gold).
• A (Accountable): Head of Data/CDO.
• C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.
• I (Informed): BI/Prodotto/Marketing/Operazioni.

16) Road map di implementazione

1. Lakehouse Bronze/Silver (ACID-Tabelle), ingest di Kafka, diagramma registry.

2. Unità strim di base (1-5 min) in OLAP; la vetrina Gold. ggr _ daily (D + 1 fino alle 6:00).

3. Codice DQ come per Payments/Gameplay, dashboard Freshness/Completeness.

4. Compattazione/OTTIMIZE, minime coste metriche e alert lag/late/dup.

• Estensione Silver (SCD II per users/games/provider), lineage e impact.
• Lookups asincroni (RG/KYC/ASN/BIN), gestione delle regolazioni late.
• Livello semantico delle metriche, regolamento di esportazione (WORM/Firma).

• Multi-regione, DR/replay-simulatore, auto-tuning finestre e watermarks.
• Cost-dashboard, chargeback/quote, tiered storage e archiviazione.
• Generazione automatica della documentazione delle vetrine e delle schede delle metriche.

17) Foglio di assegno prima della vendita

• Schemi e contratti nel registro; back-compat test sono verdi.
• Abilitato deadup, watermark/allowed lateness, DLQ.
• La compagine/OTTIMIZE/VACUUM è stata configurata come pianificato.
• SLO: p95 ingest→minute-view, Gold до 06:00; alert lag/late/dup/state size.
• Le regole DQ sono attive; lineage è visibile da Bronze alle esportazioni.
• RBAC/ABAC и KMS; residenza e DSAR/RTBF/Legale Hold sono stati testati.
• Costo sotto controllo (cost/GB, cost/query, quota cold), limiti per repliche.

18) Anti-pattern e rischi

La miscelazione tra dati crudi e report in una tabella viola la reproducibility.
L'esplosione di small files è costosa.
Calcolo FX a posteriori - Rompe la cronologia e i report.
Niente watermarks/late-policy, vetrine e alert che nuotano.
Full reload senza necessità: utilizzare gli incantesimi/MERGE e le regolazioni.
PII nell'analisi: tenete separati i mupping, includete CLS/RLS.

19) Glossario (breve)

Lakehouse - data lake + tabelle ACID e motore SQL.
Bronze/Silver/Gold - strati crudi/normalizzati/cervinaggi.
Watermark è il limite di preparazione delle finestre per event-time.
Materialization View è una vetrina predefinita per la lettura rapida.
Time-travel - Lettura delle versioni storiche delle tabelle.
WORM - Memorizzazione invariata dei manufatti di esportazione.

20) Totale

Un lago di dati con la corretta aggregazione strim è la disciplina dei livelli e dei contratti: Bronze «com'è», Silver per la normalizzazione e la qualità, OLAP per i pannelli minuti, Gold per i rapporti riproduttivi. Gestendo finestre e watermarks, deducibilità e compattazione, privacy e costo, si ottengono vetrine veloci, verificabili e complesse per il prodotto, la compilazione e la gestione operativa.