Ottimizzazione delle richieste di analisi

1) Perché ottimizzare (contesto iGaming)

Velocità aziendale: report GGR/NET, provider/giochi, RG/AML e marketing in p95 SLA.
Il costo è inferiore a byte e → scansionati sotto i $/richiesta.
Affidabilità: orologi di punta stabili, assenza di congelamento BI.
Scala: decine di marchi/mercati, miliardi di righe, minuti di freschezza.

2) Profilo di carico e SLO

Descrivere i primi 90% delle richieste: finestre (7/28/90d), filtri ('brand, country, provider, psp, status'), join's, attributi JSON, top K e percense.
SLO esempi p95 ≤ 1. 2 s per il dashbord, scanned byties 256 MV/richiesta, freshness 5 min.

3) Anatomia dei piani: cosa cercare

Predicate/Progection pushdown - I filtri e l'elenco delle colonne scendono all'origine.
Partition pruning & data skipping - Ritaglia le partizioni/file in eccesso (min-max/bloom/manifest).
Vitorized scan/late materialization: lettura delle colonne posticipate da JOIN/PROJECT.
Join strategy: Broadcast Hash (BHJ), Sort-Merge (SMJ), Nested Loop (NLJ — избегать).
Spill & shuffle - Il volume e lo stretto sul disco sono il nemico principale di SLA.
Adattative query execution: cambio di strategia nel Rantaim (cambio di BHJ↔SMJ, coalizione dinamica).

Il piano deve indicare quanti byte leggiamo, dove lo zafferiamo, cosa lo mettiamo in cache.

4) Partenze, ordinamenti, valigette di cluster

Partizioni: «date» + 1-2 misure di accesso (ad esempio, «brand, country»).
Ordina/clusterizza: 'ORDER BY/CLUSTER BY/Z-order'per filtri/join frequenti (' provider, game _ id, occurred _ at ').
Ricasterizzazione e compattazione: transizione regolare per data skipping; Dimensioni target dei file 128-1024 MB.

5) JOIN-pattern

Broadcast Hash Join (BHJ) è una piccola dimensione ( centinaia di MB) di broadcast al fatto.

sql
/ hint if engine supports/
SELECT /+ BROADCAST(dim_provider) /...

Fort-Merge Join (SMJ) - Set di grandi dimensioni, ordinamenti chiave compatibili, valigette di cluster e schienali minimi.
Pre-join/denormalizzazione - Porta gli attributi stabili da «dim _» a un dato-istantanea - meno JOIN su un percorso critico.
Anti/semijoins: riscrivere «NOT IN/EXECUTS» in chiari piani semi-/anti-join.
Eliminazione esplosione radicale: controlla le chiavi duplicate nelle misure, usa surrogate-keys.

6) GROUP BY, apparecchiature e preagregazione

Rollup/Cube/Grouping Set: una fase invece di più aggregazioni.

sql
SELECT brand, country, DATE(ts) d, SUM(amount)
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
GROUP BY GROUPING SETS ((brand,country,d),(brand,d),(d));

Visualizzazioni materializzate (MV )/proiezioni: 'payments _ 7d _ by _ brand _ psp', 'rounds _ 1d _ by _ provider _ game'.
Partial → Final aggregation: consente di aggregare il motore in parte sui worker (locale) e in modo finale sul coordinatore.
Approximate: HLL per'COUNT (DISTINCT user) ', TDigest per i percentili è il doppio del costo e sufficiente per BI.

7) Funzioni finestre (con attenzione)

PARTITION BY in base alle chiavi ad alta selettività ORDER BY - Per ordinamento intestinale.
Sostituisci le finestre pesanti con le preagregate e semi-joins, ove possibile.

sql
-- Instead of window distinct
SELECT brand, COUNT() users
FROM (SELECT DISTINCT brand, user_id FROM gold. sessions WHERE d>=CURRENT_DATE-7) t
GROUP BY brand;

8) Filtri, paginazione e TOP-K

L'ordine dei filtri non è importante per il CBO, ma è importante per la selettività e gli indici/ordinamento.
LIMIT … WITH TIES/APPROX TOP-K - Riducono lo scan.
Paginazione: «keyset pagination» invece di «OFFSET/LIMIT» per grandi tabelle.

sql
-- keyset
SELECT FROM t WHERE (date, id) > (:last_date,:last_id) ORDER BY date, id LIMIT 1000;

9) JSON/semistrutturato

Materializzare i percorsi caldi nelle colonne ('device. os`, `psp. method`).
Utilizzare indici/GIN invertiti sui percorsi JSON se il motore supporta.
Evitare l'UDF a righe, meglio la proiezione con l'evidenziazione degli attributi.

10) Approx e sampling

HLL/Theta Sketch: «COUNT DISTINCT».
TDigest/KLL: Percentili p95/p99 senza fort fort.
Riservoir/stratified sampling - Ricerca interattiva e prevaricazione.

11) Memoria, Stretto e Concarrance

Spill-guard: limiti di memoria per join/agg; allo stretto - riduce il batch/parallelismo, aumenta l'ordinamento per chiave.
Concorrency & QoS: pool per dashboard hot e pesanti ad hoc; limiti di scansione/tempo kill-switch per le query «dimenticate».
Result cache/query cache: abilita per i modelli BI ripetuti, disabili per il tocco di freschezza.

12) Test di regressione e «doppia prova»

Memorizzare i profili di riferimento (piano/scan-byte/tempo) per le richieste top-N.
Prima di rilasciare indici/cluster - A/B-test: confrontare p95, scanned byties, skipped share, shuffle.
Creare una soglia «fail-fast» se p95 è aumentato> X% - Ripristina.

13) Osservabilità e SLO

• p50/p95/p99 latency, scanned bytes/query, skipped bytes %, files touched;
• shuffle bytes, spilled bytes, peak memory;
• cache hit-rate; accuracy approx.

Alert: crescita scanned byties, calo skipped share, frequenti NLJ, stretto> soglia.

14) Le iGaming (ricette)

14. 1 Pagamenti/PSP: «picchi di rifiuto»

WHERE: `ts BETWEEN now()-7d AND now()`, `brand,country,psp,status`.
Partitura: day; ORDER/Z-order: `(brand,country,ts)`; bitmap: `psp,status`; bloom: `transaction_id`.
MV: `payments_7d_by_brand_psp(status)`.
Il risultato è p95, 1s, scanned byties, 5-10 x, zero.

14. 2 Round di gioco: top K giochi/ora

ORDER BY / cluster по `(provider, game_id, occurred_at)`; progection per i pre-regati.
Approx Top-K + TDigest per la durata del round.
Il risultato è grafico secondario sulla cache hot.

14. 3 RG/AML: vincoli attivi

JSON'reason ', colonna; bitmap `rg_state`, `kyc_level`; semi-join con l'ultimo stato.
Il risultato è «30 giorni» in secondi, senza full scan.

15) Assegno-foglio di ottimizzazione (giornaliero)

1. Raccogliere le richieste Top N e i loro profili (piano/byte/scaffale).
2. Partenze per data + ordinamento/cluster-valige coerenti.
3. Controlla pushdown e project pruning (solo le colonne desiderate).
4. STRATEGIA JOIN: broadcast di piccole dimensioni, ordinamento per SMJ, nessun NLJ.
5. Preagregazione/MV per i dashboard caldi.
6. Approx è dove è consentito (distinct/percentiles/top-k).
7. JSON → le colonne e/o gli indici invertiti.
8. Compattazione/riclasterizzazione; obiettivo di skipped bytas 70%.
9. La cache dei risultati e i pool di concarrance separati.
10. Monitoraggio: p95, scanned byties, shuffle, spill, hit-rate.

16) Modelli (pronto per l'uso)

16. 1 Criteri di ottimizzazione (YAML)

yaml workload: bi_hot slo:
p95_latency_ms: 1200 scanned_bytes_max_mb: 256 skipped_bytes_share_min: 0. 70 storage:
partition_by: ["date"]
cluster_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
aggregation:
mv:
- name: mv_payments_7d_brand_psp window: "7d"
group_by: ["brand","psp","status"]
approx:
count_distinct: "hll"
percentile: "tdigest"
concurrency:
pools: {bi_hot: 50, adhoc: 10}
timeout_s: 120

16. 2 Test di regressione della query (pseudo-SQL)

sql
-- baseline: p95<=1200ms, scanned_bytes<=256MB
EXPLAIN ANALYZE
SELECT brand, psp, status, COUNT() cnt, SUM(amount) amt
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
AND brand =:brand AND country =:country
GROUP BY brand, psp, status;

16. 3 Riscrittura di DISTINCT

sql
-- Bad: Heavy COUNT (DISTINCT user_id)
SELECT COUNT(DISTINCT user_id) FROM gold. sessions WHERE d>=CURRENT_DATE-7;

-- Better: HLL sketch/preaggregate
SELECT hll_union(user_hll) FROM agg. sessions_7d_user_hll WHERE d>=CURRENT_DATE-7;

16. 4 paginazione Keyset

sql
SELECT
FROM gold. game_rounds
WHERE (occurred_at, round_id) > (:ts,:rid)
AND brand=:brand AND country=:country
ORDER BY occurred_at, round_id
LIMIT 1000;

17) Anti-pattern

SELECT in vendita; Nessun progetto pruning.
Paginazione OFFSET su milioni di righe.
COUNT DISTINCT senza sketch percorribili attraverso il completo sart.
NLJ su grandi set; join per espressioni JSON.
Piccole partenze e file separati (tempesta di metadati).
Righe UDF in WHERE anziché materializzare colonne.
Ignora statistiche/ANALYZE - ottimizzatore cieco e full scan.
Nessun test di regressione e nessuna soglia di rientro.

18) Road map di implementazione

0-30 giorni (MVP)

1. Misura del top-N delle richieste e installazione di SLO/SLI.
2. Partenze per data + ordinamento/cluster-valige; abilitare data skipping/bloom.
3. Un MV per bollettino a caldo; HLL/TDigest в BI.
4. Separare i pool di query, attivare result cache.

30-90 giorni

1. Censimento delle finestre pesanti/JSON di pre- →/colonna.
2. Broadcast-join di piccole dimensioni SMJ per grandi; eliminazione di NLJ.
3. Compattazione e riclasterizzazione pianificata L'autotrasportatore delle chiavi.
4. Osservabilità e alert di degrado, piani A/B, auto-rientro.

3-6 mesi

1. Catalogo proiezioni/MV con versioning e SLA.
2. Kernel approx per distinct/percentile/top-k per tutti i dashboard.
3. Un unico modello di test di regress e budget $/query.
4. Igiene continua di JSON e UDF: materializzazione e indici.

19) RACI

Platform (R) - Partizioni/clustering/compressione, MV/proiezioni, cache, monitoraggio.
Analytics/BI (R) - Riscrittura SQL, aggregazioni approx, test di regressione.
Domain Owners (C) - Requisiti di taglio e precisione.
Sicurezza/DPO (A/R): privacy/PII, k-anonimato delle unità.
SRE/Osservabilità (C): SLO/alerting, concarrance e capasiti.
Finanza (C) - Budget per $/richiesta e impatto economico.

20) Partizioni correlate

Indicizzazione dello storage analitico, Schemi di dati e relativi sviluppi, Convalida dei dati, EP, Clustering dei dati, Riduzione delle dimensioni, API di analisi e metriche, MLOs: utilizzo dei modelli.

Totale

L'ottimizzazione delle query non è un hit magico, ma un sistema: mappatura corretta dei dati (partition/cluster), preagregazione e algoritmi approximate, strategie JOIN corrette, cache/concarrance e monitoraggio costante di p95 e scanned byties. Questo significa che i pagamenti, i giochi e la compilazione sono veloci e stabili, all'interno della SLA e del budget.