L’anatomia di un job Azure Stream Analytics

Azure Stream Analytics (ASA) è il motore di elaborazione in tempo reale (real-time analytics) della piattaforma dati Azure. Ogni job ASA si compone di tre elementi:

  • Input: la sorgente streaming. Su DP-203 lo scenario canonico è Azure Event Hubs, ma sono validi anche IoT Hub (device-to-cloud) e Azure Blob/ADLS Gen2 come reference/lookup data statici (input di riferimento).
  • Query: un linguaggio SQL-like che filtra, aggrega e trasforma gli eventi in transito. È qui che vivono le funzioni di windowing.
  • Output: la destinazione. Le tre più ricorrenti sono Azure SQL Database / dedicated SQL pool (serving layer per report strutturati), ADLS Gen2 (data lake per archiviazione e batch downstream) e Power BI (dashboard live via streaming dataset).

Un dettaglio architetturale importante: la scelta del partition key dell’Event Hub e l’uso di PARTITION BY nella query determinano il parallelismo, mentre le Streaming Units (SU) dimensionano throughput e memoria.

Le funzioni di windowing

Le aggregazioni streaming richiedono di raggruppare eventi in finestre temporali. ASA offre cinque tipi, ciascuno con una vocazione precisa. La clausola chiave è sempre GROUP BY ... <window> con TIMESTAMP BY a definire il campo temporale.

Tumbling window

Finestre fisse, contigue e non sovrapposte: ogni evento appartiene a una sola finestra. È la scelta per aggregazioni periodiche pulite — “conteggio ordini ogni 5 minuti”.

SELECT DeviceId, COUNT(*) 
FROM Input TIMESTAMP BY EventTime
GROUP BY DeviceId, TumblingWindow(minute, 5)

Hopping window

Finestre di durata fissa che avanzano di un passo (hop) più piccolo della finestra stessa, quindi si sovrappongono: un evento può ricadere in più finestre. Serve per medie mobili — “media degli ultimi 5 minuti, aggiornata ogni 1 minuto”: HoppingWindow(minute, 5, 1).

Sliding window

La finestra non ha cadenza fissa: emette un output solo quando un evento entra o esce dalla finestra, cioè quando il contenuto cambia. Ideale per allarmi condizionali — “più di 3 errori in 10 secondi”.

Session window

Raggruppa eventi separati da meno di un timeout di inattività (gap), con un tetto massimo di durata. Perfetta per sessioni utente o burst di attività di durata variabile: la finestra si chiude quando arriva silenzio.

Snapshot window

Non ha una funzione dedicata: si ottiene raggruppando su System.Timestamp(). Aggrega tutti gli eventi con lo stesso identico timestamp.

Event time, arrival time e late arrivals

Distinzione centrale nell’esame:

  • Arrival time: quando l’evento raggiunge Event Hubs/ASA (EventEnqueuedUtcTime). È il default se non specifichi nulla.
  • Event time (application time): quando l’evento è realmente accaduto alla sorgente. Si attiva con TIMESTAMP BY <campo> ed è quasi sempre la scelta corretta, perché rende i risultati indipendenti da latenze di rete e code.

Usando l’event time, ASA gestisce l’ordine con il concetto di watermark: una soglia temporale progressiva che dichiara “non aspetto più eventi antecedenti a questo istante”. Due policy configurabili governano gli scostamenti:

  • Late arrival tolerance: quanto attendere gli eventi in ritardo (event time più vecchio del clock). Oltre la soglia, l’evento viene adjusted al limite o scartato (drop).
  • Out-of-order tolerance: buffer di riordino per eventi che arrivano fuori sequenza.

Alzare queste tolleranze migliora la correttezza ma aumenta la latenza dei risultati: è un trade-off da motivare in base allo scenario.

Trappole tipiche d’esame

  • Tumbling vs Hopping: se lo scenario chiede aggregazioni senza sovrapposizioni, ogni evento in una sola finestra → tumbling. Se chiede una media/conteggio mobile aggiornato più spesso della durata della finestra (finestre che si sovrappongono) → hopping. Ricorda: una hopping con hop = size coincide con una tumbling.
  • Sessioni a durata variabile con pause (attività utente, sensori intermittenti) → session window con gap di inattività, non tumbling.
  • Allarme “N eventi in M secondi” valutato a ogni nuovo evento → sliding window, non hopping: l’output deve reagire all’ingresso/uscita, non a intervalli fissi.
  • Risultati “sbagliati” per eventi ritardati: se serve robustezza a ritardi di rete usa TIMESTAMP BY (event time) e regola la late arrival policy; affidarsi all’arrival time falsa le finestre.
  • Output verso Power BI in tempo reale → sink Power BI (streaming dataset); per archiviazione storica e batch a valle → ADLS Gen2; per query relazionali/serving → Azure SQL. Non confondere i tre ruoli.