Elaborazione in streaming

Cos'è lo streaming

Lo streaming è una risposta continua a sequenze infinite di eventi (logici di transazioni, clic, pagamenti, telemetria), con un minor ritardo e garanzia di correttezza degli stati. A differenza di un batch in cui «prelevare tutto ciò che è stato accumulato nel periodo», il flusso elabora i dati quando arriva, mantiene lo stato e tiene conto dell'ora dell'evento.

Concetti chiave

Evento (event) è un dato non modificabile con'event _ time'e univoco 'event _ id'.
Tempo evento (event time) vs tempo di elaborazione (processing time) - Il primo viene dall'origine, il secondo quando l'operatore ha effettivamente visto l'evento.

• Tumbling (non riconducibili), Hopping/Sliding (sovrappeso), Sessione (interruzioni di inattività).
• Filigrana (watermarks) - Stima che «gli eventi prima del momento T sono già arrivati», che consente di chiudere le finestre e limitare l'attesa dei dati in ritardo.
• Dati lateness - Eventi con «event _ time» inferiori al watermark corrente; spesso vengono applicate le regole di pre-elaborazione.
• Stato - Tabelle/archivi locali degli operatori (keyed state) per aggregazioni, join'ov, deduplicazione.
• Backpressure: pressione per il superamento della larghezza di banda downstream; gestito da protocollo e buffer.

Basi architettoniche

1. Sorgente: broker di eventi (Kafka/NATS/Pulsar), CDC da database, code, file/logo-raccoglitori.
2. Motore di flusso: calcola finestre, aggregazioni, gioielli, pattern (CEP), controlla lo stato e checkpoint'ami.
3. Ricevitore (sink): database OLTP/OLAP, motore di ricerca, cache, topic, depositi per vetrine/report.
4. Registro degli schemi: controllo dell'evoluzione dei payload e della compatibilità.
5. Osservabilità: metriche, tracking, logi, dashboard e filigrane.

Semantica del tempo e dell'ordine

Preferisci sempre l'event time: è l'unico invariante in caso di ritardi e interruzioni.
Gli eventi possono venire fuori dall'ordine; l'ordine è garantito solo all'interno della chiave di partitura.

• Chiudere le finestre e emettere i risultati
• limitare «quanto aspettiamo» gli eventi in ritardo ('allowed _ lateness').
• Per gli eventi in ritardo, utilizzare retrazioni/upserts per ricontrollare aggregazioni ed eventi di correzione.

Stato e affidabilità

Keyed state: i dati degli aggregati (importi, contatori, strutture di deduplicazione) vengono distribuiti in base alle chiavi.
Checkpoint/Savepoint: istantanee di stato periodiche per il ripristino; savepoint è un'istantanea guidata per le migrazioni di codice.

• transazionale «letto-elaborato-scritto» (commit sink + posizione di lettura)
• Sinks idonei (upsert/merge) + tabelle di deduplicazione
• versioning degli aggregati.

Finestre, aggregazioni, join's

• Tumbling - Report periodici semplici (minuti, ore).
• Hopping/Sliding: metriche «scorrevole» (in 5 minuti con un passo di 1 minuto).
• Sessione - Naturalmente per sessioni personalizzate e antifrode.
• Aggregations: sum/count/avg/approx-distinct (HyperLogLog), percentiles (TDigest/CKMS).
• Stream-Stream join: richiede il buffering di entrambe le parti in chiave e ora, rispettando allowed _ skew.
• Stream-Table join (KTable) - Consente di allegare una guida o uno stato corrente, ad esempio i limiti attivi dell'utente.

Operazioni con dati in ritardo e duplicati

Deduplicazione per «event _ id» o «(producer _ id, sequence)»; memorizzare le chiavi «viste» dalla finestra di ripetizione di TTL.
Late events - Consente il completamento della finestra durante X dopo la chiusura (retraction/upserts).
Duplicati falsi - Correggi le unità in modo idimpotente e fissa ALREADY _ APPLIED nei fogli.

Scalabilità e prestazioni

Charding a chiave - fornisce parallelismo; Tieni d'occhio le chiavi calde.
Backpressure: limitare la parallelità, utilizzare batch e compressione durante la pubblicazione.
Filigrana: non mettere troppo aggressivo - I watermarks rigidi riducono l'attesa, ma aumentano la percentuale di aggiornamenti late.
Stato: selezionare il formato (RocksDB/state store/memoria) in base alle dimensioni e ai pattern di accesso. pulire la TTL.
Scala automatica: lame, CPU, dimensione state, tempo GC.

Affidabilità e riavvio

Un sink Idempotent o un commit transazionale con fissaggio offset è la base della correttezza.
È possibile riprogettare dopo il riavvio. L'effetto deve rimanere «esattamente una volta».
DLQ/parcheggio lot: invia i record problematici a un flusso separato con cause; Assicuratevi che il lavoro venga rifatto.

Osservabilità (cosa misurare)

In base alle fonti (orari e messaggi).
Watermark/current event time e la quota di eventi late.
Throughput/latency operatori, p95/p99 end-to-end.
State size/rocksdb I/O, frequenza checkpoint/durata.
DLQ rate, percentuale di deduplicazione/retrai.
CPU/GC/heap, tempo di pausa.

Protezione e compliance

Classificazione dati: contrassegnare PII/PCI nei circuiti, memorizzare il minimo, cifrare state e snapshot.
Access control: ACL separate su top/tabelle state e sinks.
Retenze coerenti con i requisiti legali (GDPR/diritto all'oblio).
Controllo: logica «event _ id», «trace _ id», l'esito è «APPLIED/ALREADY _ APPLIED/RETRIED».

Pattern di implementazione

1. CDC → la normalizzazione dell'evento di dominio →: non trasmettere modifiche crude al database, mappare i fatti aziendali comprensibili.
2. Outbox produttore: transazione + evento in una singola transazione database.
3. Core vs Entriched: payload minimo in flusso critico, arricchimento asincrono.
4. Amichevole replay: le proiezioni/vetrine devono essere riarrangiate dal cavo.
5. Idempotency by design: operation/event key, schemi upsert, versioni di aggregazioni.

Test

Unità/Property-based - Invarianti di aggregazioni e trasformazioni.
Stream test: flusso fisso di eventi con out-of-order e duplicati per la verifica delle finestre e della deduplicazione.
Golden windows: finestre/aggregazioni di riferimento e regolazioni tardive valide.
Fault-injection: la caduta tra «registra l'effetto» e «commette l'offset».
Replay test - Intersezione vetrina dall'inizio del login = stato corrente.

Costi e ottimizzazione

Le finestre e il watermark influiscono sul ritardo/risorse: più lunga è la finestra e più 'allowed _ lateness', più grande è lo state.
Codec e compressione bilanciare CPU/rete.
Batching in uscita: meno chiamate di rete e transazioni.
Filtrazione precoce («pushdown») - Allontanarsi il più possibile dall'origine.

Antipattern

L'allacciamento sul processing time è dove è necessario un event time non corretto.
La mancanza di idampotenza nel sink ha avuto effetti doppi nei restart.
Chiave mega globale: una sezione calda rompe il parallelismo.
Il CDC crude come eventi pubblici, la fuga di schemi di database, la fragilità dell'evoluzione.
Nessun DLQ: i messaggi velenosi bloccano l'intera catena di montaggio.
Ritardo rigido fisso invece di watermark, o l'attesa eterna o la perdita di dati.

Esempi di dominio

Pagamenti/finanza

Flusso dì payment ", finestre per l'antifrode (sessione + CEP), dedotto per" operation _ id ".
Effetto exactly-once quando esplode in ledger contabile (upsert + versione).

Marketing/pubblicità

Sliding finestre CTR/Conversioni, Join click e mostre con permessi di aggregazione per bidding.

iGaming/servizi online

Real time bilanci/limiti, missioni/finestre (sessione finestra), antifrode pattern e avvisi.

Modelli minimi (pseudocode)

Finestra con filigrana e late-upgrade

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

Sink transazionale con fissa offset

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

Foglio di assegno di produzione

• Definiti event time e strategia watermark; le finestre selezionate sono allowed _ lateness.
• Icpotent sink o commit transazionale offset.
• Il registro degli schemi e le modalità di compatibilità sono inclusi; evoluzione additiva.
• Metriche: lega, watermark, p95/p99, DLQ, dimensione state, durata checkpoint.
• Test: out-of-order, duplicati, riavvio, replay.
• Criteri PII/Retenze per state e snapshot.
• Piano di scalabilità e strategia backpressure.
• Documentazione relativa ai contratti di finestre e regolazioni (late updates).

FAQ

Event time è obbligatorio?
Se conta la correttezza delle metriche e la coerenza, sì. Processing time è adatto per i calcoli e il monitoraggio, ma distorce l'analisi.

È necessario exactly-once?
Punto - per gli effetti critici. Più spesso è sufficiente at-least-once + Idempotent sink.

Come scegliere le finestre?
Allontanati dalla SLA aziendale: «negli ultimi 5 minuti», «sessione utente» «sessione», «rapporti minuti» «tumbling».

Cosa fare con i dati tardivi?
Consenti «allowed _ lateness» limitato ed emettere regolazioni (upsert/retract). La vetrina dei clienti deve essere aggiornata.

Totale

Lo streaming non è solo un ritardo basso, ma anche una disciplina del tempo, dello stato e dei contratti. La corretta scelta di event time, finestre e filigrane, più effetti idipotenti, osservabilità e test rendono la catena di montaggio affidabile, riproduttiva ed economica - e offre alle imprese soluzioni «qui e ora» anziché «tra la notte».