Fundamentals of stream processing

Siamo nel binario ml-tabellare, ma qui la tabella arriva in movimento: ogni evento conta perché arriva nel momento in cui è utile reagire. Questa lezione distingue ciò che merita un’elaborazione immediata da ciò che può aspettare tranquillamente il batch.

L’idea in breve

Lo stream processing elabora ogni evento al suo arrivo in finestre temporali esplicite per decidere subito cosa richiede reazione immediata e cosa può attendere il batch. Non è un’alternativa al batch, è un altro regime decisionale.

La procedura passo per passo

Per passare dai dati al sistema di streaming servono cinque decisioni in ordine.

1. Separa gli eventi che richiedono reazione in secondi da quelli che tollerano ore di ritardo.
2. Fissa per ogni flusso se conta il tempo di evento o il tempo di arrivo e dichiara la tolleranza al ritardo.
3. Scegli finestre tumbling per conteggi fissi e sliding per medie mobili con sovrapposizione.
4. Definisci garanzie di consegna e idempotenza per duplicati e replay prima di andare in produzione.
5. Collega ogni metrica live a una soglia, un owner and a runbook di intervento.

Perché la velocità non basta

Un prodotto digitale genera eventi ogni secondo: click, pagamenti, errori e cambi di stato. La velocità da sola non decide. Serve distinguere gli eventi che chiedono reazione immediata da quelli che possono attendere il batch, e dichiarare quali garanzie rendono il risultato credibile. La scelta passa per tre coppie operative: tempo di evento contro tempo di arrivo, finestre tumbling contro sliding, consegna at-least-once contro exactly-once. Ogni coppia fissa ritardo tollerabile, errore accettabile e costo di correzione.

Dati a riposo e dati in movimento

The batch lavora su dati a riposo: insiemi finiti, completi e delimitati. È il censimento nazionale che raccoglie per mesi e analizza alla fine, con risultati deterministici e riletture multiple. Funziona per fatturazione mensile, training su storici e report finanziari trimestrali. Lo stream lavora su dati in movimento: flussi potenzialmente infiniti, incompleti e non ordinati. È il controllore del traffico aereo che decide rotte su posizione, velocità e meteo senza attendere tutti gli atterraggi. Ogni transazione, click o lettura da sensore viene processata all’arrivo, da sola o in piccole finestre.

La vera differenza non è il tempo di risposta, ma il momento in cui il sistema è costretto a decidere. Il batch decide quando i dati sono completi: il numero finale è definitivo perché può sempre ricalcolare. Lo stream decide prima della completezza: la finestra si chiude, il conteggio esce, e se un evento arriva dopo non rifà la storia, la aggiunge o la ignora secondo le regole dichiarate.

Verdetto: usa lo streaming solo dove la decisione perde valore se aspetta. Per tutto il resto il batch costa meno e resta più affidabile.

Tempo di evento, tempo di arrivo e finestre

Il tempo di evento è il momento in cui l’accaduto è realmente avvenuto sul dispositivo o sul server; il tempo di arrivo è il momento in cui il sistema riceve l’evento. I due coincidono solo in condizioni ideali: un telefono in aereo, un client con cache o un servizio con coda producono eventi che arrivano in ritardo, con un gap anche di minuti. Se l’elaborazione usa il tempo di arrivo, un picco di traffico di venti minuti finisce conteggiato nella finestra sbagliata e la metrica si distorce proprio durante l’incidente, quando la leggi per decidere. La regola pratica: usa il tempo di evento per i fenomeni che i tuoi utenti percepiscono (latenza percepita, sessioni, acquisti) e dichiara la tolleranza al ritardo, l’intervallo massimo oltre il quale un evento in ritardo viene scartato o contato a parte.

Le finestre tumbling e sliding rispondono a domande diverse. Una finestra tumbling è una sequenza di intervalli fissi e contigui, dal minuto 0 al minuto 1, dal minuto 1 al minuto 2 e così via; ogni evento appartiene a una sola finestra e i totali sono additivi e facili da confrontare. È la scelta giusta per conteggi che devono quadrare: transazioni al minuto, errori per slot temporale. Una finestra sliding si sposta con continuità, per esempio 60 minuti che avanzano ogni 5, e ogni evento appare in molte finestre; serve alle medie mobili e ai trend, dove conta la forma della curva.

Scelta	Opzione A	Opzione B	Quando scegli A	Quando scegli B
Time	Tempo di evento	Tempo di arrivo	Conteggi di fenomeni percepiti, latenza	Monitoraggio di sistema, eventi puntuali
Finestra	tumbling	sliding	Totali che devono quadrare	Medie mobili, trend
Delivery	at-least-once	exactly-once	Contatori idempotenti	Pagamenti, saldi, stati

Garanzie di consegna e idempotenza

La consegna at-least-once garantisce che nessun evento vada perso, ma ammette duplicati: se il consumatore fallisce dopo aver ricevuto un evento e prima di confermarlo, l’evento verrà riconsegnato. exactly-once garantisce che ogni evento produca un effetto una sola volta, ma costa coordinamento tra sorgenti, stato e sink. La differenza non è solo il costo: è la natura dell’output. Un contatore di click che conta un duplicato in più su mille è un errore tollerabile; un pagamento addebitato due volte no. La scelta va fatta sull’output, non sull’entusiasmo per la tecnologia.

L’idempotenza è il piano B universale: se il sink accetta la stessa scrittura più volte con lo stesso risultato, at-least-once basta. Un pagamento è idempotente per design, con identificativo dell’ordine e stato: ripetere la stessa richiesta non cambia il saldo. Gli eventi devono quindi nascere con un id stabile attraverso i retry, altrimenti nessuna dichiarazione di garanzia regge.

L’errore da evitare

L’errore tipico è usare lo stream come etichetta invece che come criterio di scelta. Si pubblicano numeri senza decisione, senza baseline e senza rischio residuo. Il dato sembra preciso ma non guida l’azione. La domanda di controllo resta una sola: se questo risultato fosse instabile, quale scelta sbaglierei.

Il secondo errore è confondere gli eventi con la loro copia: duplicare un evento per alimentare due pipeline non è stream processing, è raddoppiare il problema dei duplicati. Il terzo è dichiarare exactly-once dove non serve e poi scoprire che costa latenza e complessità, oppure dichiarare at-least-once per un saldo e scoprire i duplicati in fatturazione. Le garanzie si scrivono prima, sulla base dell’output, e si testano con il replay.

Il caso di Twitter e Heron

Nel 2015 Twitter presenta Heron, successore di Storm, per reggere i picchi di tweet durante eventi live con latenze sotto il secondo. Il motore nasce perché il volume durante le dirette supera ciò che il sistema precedente garantisce senza code. Heron separa scheduling, backpressure e garanzie di consegna per tenere il flusso stabile anche sotto spike. La lezione resta netta: batch per ciò che può aspettare e streaming per ciò che richiede reazione immediata con regole esplicite su ritardi e duplicati.

Heron documenta pubblicamente che il problema non era solo la velocità di processamento: era la capacità di mantenere latenza e ordine quando il carico esplode, perché un sistema che regge la media ma soffoca il picco non è operativo. Da quel caso deriva la pratica di progettare le pipeline sul picco, non sulla media.

Domande per ripassare

1. Quando un evento richiede reazione in secondi invece di attesa batch?
2. Quale differenza passa tra tempo di evento e tempo di arrivo nel tuo flusso?
3. Quale finestra useresti per conteggi fissi e quale per medie mobili?
4. Come gestisci duplicati e replay senza corrompere il conteggio?
5. Quale output del tuo sistema tollererebbe un duplicato e quale non se lo può permettere?