GH GambleHub

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.
Esempio Flink SQL (10 min velocity depositi):
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.

Pseudo-codice CEP:
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%.
Dashboard:
  • 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.

Regole minime (YAML, esempio):
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.
Fase 3 (8-12 settimane):
  • 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.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.