Streaming e analisi in streaming
1) Assegnazione e valore
Il tracciato streaming consente di prendere decisioni in volo:- Antifrod/AML: identificazione della struttura di depositi, attacchi velocity, anomalie dei provider.
- Responciabile Gaming (RG) - Superamento dei limiti, pattern a rischio, auto-esclusione.
- Operazioni/SRE: degrado della SLA, picchi di errore, primi segnali di incidenti.
- Prodotto/marketing: eventi di personalizzazione, missioni/ricerche, segmentazione real-time.
- Report near-real-time: vetrine GGR/NGR, pannelli operativi.
Caratteristiche di destinazione: p95 end-to-end 0. 5-5 s, totale 99. 5%, valore gestito.
2) Architettura di riferimento
1. Ingest/Edge
`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Convalida diagrammi, anti-duplicati, geo-instradamento.
2. Bus degli eventi
Kafka/Redpanda (partigiano'user _ id/tenant/market ').
Restituzione 3-7 giorni, compressione, DLQ/quarantena per i messaggi a bit.
3. Elaborazione in streaming
Flink / Spark Structured Streaming / Beam.
Operatori Stateful, CEP, watermark, allowed lateness, deduplicazione.
Arricchimento (Redis/Scylla/ClickHouse-Lookup), asincrona I/O con timeout.
4. Cerving/vetrine operative
ClickHouse/Pinot/Druid per aggregazione minuti/secondi e dashboard.
Feature Store (online) per la compilazione dei modelli.
Alert topic SOAR/ticketing/webhook.
5. Conservazione a lungo termine (Lakehouse)
Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Repliche/battistest, time-travel.
6. Osservabilità
Metriche di pipline, tracking (OTEL), logi, lineage.
3) Schemi e contratti
Schema-first: JSON/Avro/Protobuf + Registry, 'schema _ version'in ogni evento.
Evoluzione: back-compatibile - nuovi campi nullabili; breaking - '/v2 '+ doppia pubblicazione.
I campi obbligatori sono «event _ time» (UTC), «event _ id», «trace _ id», «user». pseudo_id`, `market`, `source`.
4) Finestre, watermarks e dati tardivi
Finestre:- Tumbling (fisso), Hopping (sovrapposto), Sessione (inattività).
- Watermark: soglia di conoscenza per event-time; per esempio, 2-5 minuti.
- Late data: preemissione di regolazioni, «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) Aggregazioni stateful e CEP
La chiave è «user _ id», «device _ id», «payment». account_id`.
Stato: importi/contatori, sessioni, filtri bloom per la deduplicazione.
Pattern CEP: strutturazione (<soglia, 3 volte, oltre la finestra T), device-switch, RG-fatige.
python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())
6) Exactly-Once, ordine e idampotenza
Bus: at-least-once + chiavi di partitura garantiscono l'ordine locale.
Idampotenza: 'event _ id' + deadup state (TTL 24-72 ore).
Sink: committenti transazionali (2-phase) o upsert/merge-idampotenza.
Outbox/Inbox - Pubblicazione garantita degli eventi di dominio da OLTP.
7) Arricchimento in tempo reale
Lookup: Redis/Scylla (limiti RG, stato KYC, BIN→MCC, IP→Geo/ASN).
Chiamate asincroni: API/RER con timeout e fallback («unknown»).
FX/Timeson: regolazione degli importi e tempo di mercato locale ('fx _ source', 'tz').
8) Cerving e vetrine real-time
ClickHouse/Pinot/Druid: aggregazioni minuti/secondi, materialization views.
Gold-stream: tabelle operative GGR/RG/AML, SLA per ritardo di 1-5 minuti
API/GraphQL è bassa latitanza per i dashboard e le integrazioni esterne.
Esempio di ClickHouse (GGR a minuti):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) Osservabilità e SLO
SLI/SLO:- p95 2 c (critico), 5 c (resto).
- Completeness finestra T-99. 5%.
- Errori di schema 0. 1%; la percentuale di eventi con'trace _ id 'è del 98%.
- Disponibilità del servizio ≥ 99. 9%.
- Lagi per partenze/topic, busy time operatori, dimensioni dello stato.
- Vortice di , hot card, late-ratio.
- Costo: cost/GB, cost/query, costo di checkpoint/replay.
10) Privacy e compliance
Riduzioni PII: alias ID, maschera dei campi, tornitura PAN/BAN.
Dati di residenza: linee di montaggio regionali (EEA/UK/BR), chiavi di crittografia separate.
Operazioni legali: DSAR/RTBF sulle vetrine downstream, Legale Hold per valigette/report.
Login di accesso, archivi di soluzioni invariati.
11) Economia e produttività
Chiavi e charding: evitare le chiavi hot (salting/composite key).
Stato: TTL ragionevoli, snapshot, tuning RocksDB/Backend State.
Preagregazione: up-front reduce per flussi rumorosi.
Sampling: valido su metriche non ritriche (non su transazioni/compilation).
Chargeback: budget per temi/jobs, quote e allocazione per comando.
12) Flusso DQ (qualità)
Ingest-Validation (schema, enums, size), deadup '(event _ id, source)'.
Nel flusso: completeness/dup-rate/late-ratio, controllo delle finestre (nessuna doppia contabilità).
Criteri di reazione: critical → DLQ + alert; maggiore/minore tag e pulizia successiva.
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
13) Sicurezza di accesso e controllo release
RBAC/ABAC: singoli ruoli di lettura dei flussi, modifica delle regole/modelli.
Dual Control: rimozione di regole e modelli con «2 chiavi».
Canary/A/B: lanci oscuri di regole e modelli, controllo precisione/recall.
I segreti sono KMS/CMK, rotazione regolare, proibizione dei segreti nei cassetti.
14) Processi e RACI
R (Respontible): Streaming platform (infra/release), Domain Analytics (regole/fitch), MLOs (scansione).
A (Accountable) - Head of Data/Risk/Compliance per dominio.
C (Consulted): DPO/Legale (PII/Retention), SRE (SLO/incidenti), Architettura.
I (Informed) - Prodotto, Supporto, Marketing, Finanza.
15) Road map di implementazione
MVP (2-4 settimane):1. Kafka/Redpanda + due topic critici ('payments', 'auth').
2. Flink-jobs con watermark, deduplicazione e una sola regola CEP (AML o RG).
3. ClickHouse/Pinot una vetrina di 1-5 minuti, dashboard lag/completeness.
4. Canale di incidente (webhook/Jira), SLO base e alert.
Fase 2 (4-8 settimane):- Arricchimento online (Redis/Scylla), Feature Store, lookups asincrono.
- Controllo delle regole come codice, release canarie, A/B.
- Flusso DQ, regionalizzazione delle reti di montaggio, procedure DSAR/RTBF.
- Multi-regione active-active, repliche-simulazione «what-if», calibrazione automatica delle soglie.
- Vetrine Gold-stream complete (GGR/RG/AML), report near-real-time.
- Dashboard di valore, chargeback, dott.
16) Esempi (sezioni)
Flink CEP — device switch: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
Kafka Streams - filtro Idempotente:
java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}
17) Foglio di assegno prima della vendita
- Schemi e 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, tutte le modifiche vengono regolate.
- Documentazione delle regole, delle vetrine e del runbook e della replica/rimozione.
18) Errori frequenti e come evitarli
Event-time: senza watermarks, le metriche nuotano.
Niente deduplo, falsi alert e 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, cost-dashboard.
Nessun simulatore: scaricare senza «replay» porta a regressione.
19) Glossario (breve)
CEP - Complex Event Processing.
Watermark è il limite di preparazione delle finestre per event-time.
Allowed Lateness - Accesso agli eventi in ritardo.
Stateful Operator - Operatore con stato salvato.
Feature Store - Serving coerente dei segni (online/offline).
20) Totale
Lo streaming e lo streaming sono un sistema gestito: contratti, finestre e watermarks, logica stateful e CEP, arricchimento e real-time vetrine, SLO e osservabilità, privacy e costi sotto controllo. Seguendo le prassi descritte, la piattaforma ottiene rilevatori di rischio affidabili, pannelli operativi e personalizzazione con una latenza e costi prevedibili.