Analisi in tempo reale

1) Assegnazione e valore aziendale

• AML/Antifrode: strutturazione di depositi, attacchi velocity, transazioni a rischio.
• Responciabile Gaming (RG) - Superamento dei limiti, dei pattern di rischio, dell'auto-esclusione.
• SRE/Operazioni - Rilevamento precoce delle degradazioni SLA, dei picchi di errore, del surriscaldamento dei cluster.
• Prodotto e marketing: trigger di personalizzazione, missioni/ricerche, segmentazione real-time.
• Report operativo: near-real-time GGR/NGR, dashboard delle sale/provider.

Punti di riferimento di destinazione: p95 end-to-end 0. 5–5 с, completeness ≥ 99. 5%, disponibile 99. 9%.

2) Architettura di riferimento

1. Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector; convalidazione dei circuiti, anti-ripresa, geo-routing.
2. Il bus degli eventi è Kafka/Redpanda (partizionamento per «user _ id/tenant/market», DLQ, retensh 3-7 giorni).
3. Stream - Flink/Spark Struttured Streaming/Beam: operatori stateful, CEP, watermarks, allowed lateness, deadup.
4. Arricchimento online - Redis/Scylla/ClickHouse lookups (limiti RG, KYC, BIN→MCC, IP→Geo/ASN), chiamate asincroni con timeout e fallback.
5. Cerving - ClickHouse/Pinot/Druid (vetrine operative 1-5 minuti), Feature Store (segni online), webhooks/ticketing/SOAR.
6. Lakehouse - Bronze/Silver/Gold per il consolidamento a lungo termine, repliche e saldature.
7. Osservabilità - metriche di pipline, tracking (OTEL), logi, lineage e cost-dashboard.

3) Segnali e tassonomia

Pagamenti dì payment ". deposit/withdraw/chargeback`.
Giochi: 'game. bet/payout ', sessioni.
Autenticazione e comportamento: 'auth. login/failure`, device-switch, velocity.
Operazioni: latency, errato-rate, riavvio dei sottoprodotti, saturation.
Compilazione: screening delle sanzioni, bandiere RG, eventi DSAR.

Ogni tipo ha un proprietario (domain owner), uno schema, un SLO di freschezza e un criterio late data.

4) Finestre, watermarks e late data

Finestre: tumbling (fix.) , hopping (sovrapposizione), sessione (inattività).
Watermark è il limite della conoscenza del tempo (di solito 2-5 min).
Eventi tardivi: preemissioni di regolazioni, flag «late = true», DLQ in ritardo.

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream.payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

5) CEP e stateful-aggregazione

La chiave è «user _ id», «device _ id», «payment». account_id`.
Stato: contatori/importi scorrevoli, filtri bloom per deduplo, TTL.
Pattern CEP: strutturing (<soglia, ≥N volte, finestra T), device-switch, RG-fatige.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6) Exactly-Once, ordine e idampotenza

At-least-once consegna in pneumatico + deadup per «event _ id» in lavorazione (TTL 24-72 ore).
Ordine: partizionamento delle chiavi (ordine locale garantito).
Sink: commit transazionali (2-phase) o idempotent upsert/merge.
Outbox/Inbox - Pubblicazione transazionale di eventi di dominio da OLTP.

7) Arricchimento online e Feature Store

Lookup: limiti RG, stati KYC, BIN→MCC, IP→Geo/ASN, mercati/tasse, FX al momento dell'evento.
Chiamate asincrone: API di sanzioni/RER con timeout; in caso di errore, «unknown» + retrai/cache.
Feature Store: allineamento online/offline; una base di trasformazione in codice.

8) Vetrine e cerving real-time

ClickHouse/Pinot/Druid: unità di secondi/minuti, materialization views, SLA per un ritardo di 1-5 minuti

API/GraphQL. Bassa latitanza per dashboard/widget.
Alert: webhook/Jira/SOAR con contesto arricchito (trace _ id, last events).

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;

9) Metriche, SLI/SLO e dashboard

• p95 2 c (regole critiche), 5 c (altro).
• Completeness finestra T-99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Disponibilità del servizio ≥ 99. 9%; late-ratio ≤ 1%.

• Lega delle partizioni/topic; busy time degli operatori Dimensione dello stato.
• Vortice «sobytiye→pravilo→keys», precisione/recall per dominio.
• Sistema termico late/completeness; La mappa delle chiavi hot.

10) Flusso DQ (qualità)

Ingest-validazioni: schema/enums/size-limits, anti-doppie.
Nel flusso: completeness/dup-rate/late-ratio, correttezza delle finestre (senza doppia conta).
Criteri di reazione: critical → DLQ + pager; maggiore/minore tag + report.

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

11) Privacy, sicurezza e residenza

Riduzioni PII: alias ID, masking dei campi sensibili, tornizzazione PAN/BAN.
Data residency - Linee di montaggio regionali (EEA/UK/BR), chiavi KMS separate.
DSAR/RTBF: modifiche selettive nelle vetrine downstream; Legale Hold per valigette/rapporti.
Controllo: fogli di accesso/modifica delle regole invariati, registrazione dei rilasci.

12) Economia e produttività

Charding/chiavi: evitare le chiavi hot (salting/composite), bilanciamento delle partiture.
Stato: TTL, compact snapshots, tuning e backend.
Pre-agregazione: reduce nelle fasi iniziali per argomenti rumorosi.
Sampling: solo per le metriche non ritriche (non transazioni/compilation).
Chargeback: budget per temi/jobs, quote per repliche e richieste pesanti.

13) Processi e RACI

R: Streaming Platform (infra/release), Domain Analytics (regole/fici), MLOs (scansione/Feature Store).
A: Head of Data/Risk/Compliance per dominio.
C: DPO/Legale (PII/Retention), SRE (SLO/incidenti), Architettura.
I: Prodotto, Supporto, Marketing, Finanza.

14) Road map di implementazione

1. Kafka/Redpanda + 2 topic critici (ad esempio «payments», «auth»).

2. Flink-jobs con watermark, deduplicazione e 1 regola CEP (AML o RG).

3. Vetrina operativa in ClickHouse/Pinot (1-5 min), dashboard lag/completeness.

4. Canale di incidente (webhook/Jira), SLO base e alert.

• Arricchimento online (Redis/Scylla), Feature Store, lookups asincrono.
• Gestione delle regole come codice, canary/A-B, flusso DQ.
• Regionalizzazione dei trasportatori, procedure DSAR/RTBF, Legale Hold per valigette.

• Multi-regione active-active, simulatore «replay & what-if», calibrazione automatica delle soglie.
• Vetrine Gold-stream (GGR/RG/AML), report near-real-time.
• Cost-dashboard, chargeback, insegnamenti DR.

15) Esempi (frammenti)

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT()      AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

16) Foglio di assegno prima della vendita

• Schemi/contratti in Registry, back-compat test verde.
• Abilitato watermark/allowed lateness, deadup e DLQ.
• SLO e alert configurati (lag/late/dup/state size).
• Arricchimento con cache e timeout fallback «unknown».
• RBAC/dual-control su regole/modelli; Registro delle modifiche attivato.
• Documentazione delle regole/vetrine; runbook e replica/rimozione.

17) Errori frequenti e come evitarli

Event-time: senza watermarks, le metriche nuotano.
Niente deduplo, falsi alert, doppia contabilità.
Chiave calda: distorsione delle partizioni di salting/resharding.
API esterne sincronizzate a caldo: solo async + cache.
Costo fuori controllo: preagregazione, stato TTL, quote, monitoraggio cost.
Nessun simulatore, scaricato senza «replay».

18) Totale

L'analisi in tempo reale non è «BI veloce», ma un circuito controllato con contratti, logica stateful, CEP, watermarks, arricchimento online e SLO rigorosi. Seguendo queste prassi, la piattaforma riceve segnali e soluzioni precisi entro secondi, supportando la compliance, gli scenari alimentari e la stabilità operativa a costi controllati.