Comprendere la gestione del tempo in Azure Stream Analytics

La gestione del tempo in Analisi di flusso di Azure è il set di meccanismi che determinano il timestamp, l'ordinamento e l'elaborazione degli eventi di streaming in base al momento in cui si sono verificati rispetto a quando sono arrivati. Questo articolo illustra come effettuare scelte di progettazione per risolvere problemi pratici di gestione del tempo nei processi di Analisi di flusso di Azure. Le decisioni di progettazione della gestione del tempo sono strettamente correlate ai fattori di ordinamento degli eventi.

Concetti di base sul tempo

Per strutturare meglio la discussione, è opportuno definire alcuni concetti di base:

• Ora evento: ora in cui si verifica l'evento originale. Ad esempio, quando un'automobile in corsa su un'autostrada si avvicina a un casello.

• Tempo di elaborazione: Ora in cui l'evento raggiunge il sistema di elaborazione e viene osservato. Ad esempio, quando il sensore di un casello avvista l'automobile e il sistema impiega alcuni istanti ad elaborare i dati.

• Limite: marcatore ora evento che indica fino a quale punto il processore di streaming ha inserito eventi. I limiti consentono al sistema di indicare chiaramente lo stato di inserimento degli eventi. Per la natura stessa dei flussi, i dati degli eventi in ingresso non si arrestano mai, quindi i marcatori indicano il progresso fino a un determinato punto del flusso.

  Il concetto di filigrana è importante. Le filigrane consentono ad Analisi di flusso di Azure di determinare quando il sistema può produrre risultati completi, corretti e ripetibili che non devono essere ritirati. L'elaborazione può essere eseguita in un modo prevedibile e ripetibile. Ad esempio, se è necessario ripetere un conteggio per una qualche condizione di gestione degli errori, le filigrane sono sicuri punti di inizio e di fine.

Per altre informazioni su questo argomento, vedere i post di blog di Tyler Akidau Streaming 101 e Streaming 102.

Scegliere l'ora di inizio migliore

Analisi di flusso di Azure offre due opzioni per la selezione dell'ora dell'evento: ora di arrivo e ora dell'applicazione.

Ora di arrivo

L'ora di arrivo viene assegnata alla sorgente di input quando l'evento raggiunge la sorgente. È possibile accedere all'ora di arrivo usando la proprietà EventEnqueuedUtcTime per l'input di Hub eventi, la proprietà IoTHub.EnqueuedTime per l'input dell'hub IoT e la proprietà BlobProperties.LastModified per l'input del BLOB.

L'ora di arrivo viene usata per impostazione predefinita e trova il suo impiego ottimale negli scenari di archiviazione dei dati, dove la logica temporale non è necessaria.

Tempo di applicazione (o Tempo dell'evento)

L'ora dell'applicazione viene assegnata quando l'evento viene generato ed è inclusa nel payload dell'evento. Per elaborare gli eventi in base al tempo applicazione, usare la clausola Timestamp by nella query SELECT. Se Timestamp by è assente, gli eventi vengono elaborati in base all'ora di arrivo.

È importante usare un timestamp nel payload quando è necessaria la logica temporale per tenere conto dei ritardi nel sistema di origine o nella rete. Il tempo assegnato a un evento è disponibile in SYSTEM.TIMESTAMP.

Come avanza il tempo in Azure Stream Analytics

Quando si usa il tempo applicazione, l'avanzamento del tempo si basa sugli eventi in ingresso. È difficile per il sistema di elaborazione del flusso sapere se non ci sono eventi o se gli eventi sono ritardati. Per questo motivo, Analisi di flusso di Azure genera limiti euristici per ogni partizione di input nei modi seguenti:

• Quando è presente un evento in ingresso, il limite viene calcolato sottraendo dall'ora dell'evento maggiore registrata da Analisi di flusso di Azure fino a quel momento le dimensioni della finestra di tolleranza elementi non in ordine.

• Quando non è presente alcun evento in ingresso, il limite si calcola sottraendo dall'ora di arrivo stimata corrente la finestra di tolleranza per arrivo in ritardo. L'ora di arrivo stimata è il tempo trascorso dall'ultima volta in cui è stato rilevato un evento di input più l'ora di arrivo dell'evento di input.

  L'ora di arrivo può essere stimata solo perché l'ora di arrivo reale viene generata nel gestore eventi di input (ad esempio Hub eventi o hub IoT), non nella macchina virtuale di Analisi di flusso di Azure che elabora gli eventi.

Il design ha due scopi aggiuntivi oltre alla generazione di filigrane:

1. Il sistema genera risultati in modo tempestivo con o senza eventi in ingresso.

   È possibile controllare il livello di tempestività con cui visualizzare i risultati di output. Nella pagina Ordinamento eventi del processo di Analisi di flusso nel portale di Azure è possibile configurare l'impostazione Eventi non in ordine. Quando si configura l'impostazione, tenere in considerazione il compromesso fra tempestività e tolleranza degli eventi non in ordine nel flusso di eventi.

   La finestra di tolleranza per arrivo in ritardo è necessaria per continuare a generare limiti, anche in assenza di eventi in ingresso. A volte, potrebbe verificarsi un periodo in cui non arrivano eventi in ingresso, ad esempio quando un flusso di input di eventi è raro. Questo problema viene aggravato dall'uso di più partizioni nel gestore eventi di input.

   I sistemi di elaborazione dei dati di streaming senza una finestra di tolleranza per l'arrivo in ritardo potrebbero subire ritardi negli output quando gli input sono scarsi e vengono usate più partizioni.

2. Il comportamento del sistema deve essere ripetibile. La ripetibilità è una proprietà importante dei sistemi di elaborazione dati in streaming.

   Il watermark è derivato dall'orario di arrivo e dall'orario di applicazione. Entrambi sono memorizzati nel broker di eventi e pertanto sono ripetibili. Quando l'ora di arrivo è stimata in assenza di eventi, Analisi di flusso di Azure registra l'ora di arrivo stimata per garantire la ripetibilità durante la riproduzione per il recupero da malfunzionamenti.

Quando si sceglie di usare l'ora di arrivo come ora dell'evento, non è necessario configurare la tolleranza elementi non in ordine e la tolleranza per arrivo in ritardo. Poiché per l'ora di arrivo vi è una garanzia di incremento nel gestore eventi di input, Analisi di flusso di Azure ignora semplicemente le configurazioni.

Eventi che arrivano in ritardo

In base alla definizione della finestra di tolleranza per arrivo in ritardo, per ogni evento in ingresso Analisi di flusso di Azure confronta l'ora dell'evento con l'ora di arrivo. Se l'ora dell'evento non rientra nella finestra di tolleranza, è possibile configurare il sistema per eliminare l'evento o regolare l'ora dell'evento in modo che sia compresa nella tolleranza.

Dopo la generazione dei limiti, il servizio può potenzialmente ricevere eventi con un'ora inferiore al limite. È possibile configurare il servizio in modo da eliminare questi eventi o modificare l'ora dell'evento in base al valore del limite.

Come parte della regolazione, system.Timestamp dell'evento viene impostato sul nuovo valore, ma il campo ora dell'evento stesso non viene modificato. Questa regolazione è l'unica situazione in cui system.Timestamp di un evento può essere diverso dal valore nel campo dell'ora dell'evento e potrebbe causare la generazione di risultati imprevisti.

Gestire le variazioni temporali con i flussi secondari

Il meccanismo di generazione della filigrana euristica, in cui Analisi di flusso di Azure tiene traccia dello stato di avanzamento dell'evento usando il timestamp osservato più grande meno la finestra di tolleranza, funziona bene nella maggior parte dei casi in cui il tempo è principalmente sincronizzato tra i vari mittenti di eventi. Nella vita reale però, specialmente in molti scenari IoT, il sistema ha poco controllo sull'orologio dei mittenti di eventi. I mittenti di eventi potrebbero essere tutti tipi di dispositivi IoT nel campo, ad esempio in versioni diverse dell'hardware e del firmware del dispositivo.

Anziché usare una filigrana globale per tutti gli eventi in una partizione di input, Analisi di flusso di Azure ha un altro meccanismo denominato substream. È possibile usare substream nel processo scrivendo una query di processo che usa la clausola TIMESTAMP BY e la parola chiave OVER. Per designare il flusso secondario, specificare un nome di colonna chiave dopo la parola chiave OVER, ad esempio deviceid, in modo che il sistema applichi i criteri temporali in base a quella colonna. Ogni flusso secondario ottiene il proprio limite indipendente. Questo meccanismo è utile per consentire la generazione tempestiva dell'output, in presenza di notevoli sfasamenti di orario o ritardi di rete tra i mittenti di eventi.

Quando si usano i sottostreams, Azure Stream Analytics applica la finestra di tolleranza per gli arrivi in ritardo agli eventi in ingresso. La tolleranza per arrivo in ritardo determina la quantità massima in base alla quale i diversi flussi secondari possono essere separati tra loro. Ad esempio, se il dispositivo 1 è in timestamp 1 e il dispositivo 2 è al timestamp 2, la tolleranza massima per l'arrivo in ritardo è Timestamp 2 meno Timestamp 1. L'impostazione predefinita per la tolleranza di arrivo in ritardo è di 5 secondi, probabilmente troppo piccola per i dispositivi IoT con timestamp divergenti. Iniziare con 5 minuti e apportare modifiche in base al modello di asimmetria dell'orologio del dispositivo.

Eventi che arrivano in anticipo

La finestra di arrivo anticipata è una tolleranza fissa di 5 minuti che stabilisce quanto presto un evento può arrivare rispetto all'ora dell'evento prima che Azure Stream Analytics lo rimuova. Questa finestra ha uno scopo diverso rispetto alla finestra di tolleranza di arrivo in ritardo.

Poiché Analisi di flusso di Azure garantisce sempre risultati completi, è possibile specificare solo l'ora di inizio processo come prima ora di output del processo, invece dell'ora di input. L'ora di inizio del processo è necessaria in modo che il sistema elabori la finestra completa, non solo dalla parte centrale della finestra.

Azure Stream Analytics deriva l'orario di inizio dalla specifica della query. Tuttavia, poiché il gestore eventi di input viene indicizzato solo in base all'ora di arrivo, il sistema deve convertire l'ora di inizio dell'evento in ora di arrivo. Il sistema può iniziare a elaborare gli eventi da quel punto nel gestore eventi di input. Con il limite della finestra di tolleranza per arrivo in anticipo, la conversione è semplice: corrisponde all'ora di inizio dell'evento meno i 5 minuti della finestra di tolleranza per arrivo in anticipo. In base a questo calcolo, il sistema elimina tutti gli eventi la cui ora dell'evento è precedente all'ora di arrivo di oltre 5 minuti. La metrica degli eventi di input anticipati viene incrementata quando gli eventi vengono eliminati.

Questo concetto garantisce che l'elaborazione sia ripetibile indipendentemente dalla posizione di inizio dell'output. Senza un meccanismo di questo tipo, non sarebbe possibile garantire la ripetibilità, come molti altri sistemi di streaming sostengono.

Effetti collaterali delle tolleranze di ordinamento temporale degli eventi

I processi di Analisi di flusso di Azure hanno diverse opzioni di ordinamento degli eventi . Due di queste possono essere configurate nel portale di Azure, ossia Eventi non in ordine (tolleranza elementi non in ordine) e Eventi pervenuti in ritardo (tolleranza per arrivo in ritardo). La tolleranza di arrivo anticipata è fissa e non può essere modificata. Analisi di flusso di Azure usa questi criteri temporali per offrire garanzie solide. Queste impostazioni hanno tuttavia alcune implicazioni talvolta impreviste:

1. Invio accidentale di eventi troppo anticipati.

   Gli eventi iniziali non devono in genere essere restituiti. È possibile che gli eventi iniziali vengano inviati all'output se l'orologio del mittente è troppo veloce. Tutti gli eventi in arrivo in anticipo vengono eliminati, quindi non verranno visualizzati dall'output.

2. Invio di eventi non recenti a Hub eventi perché vengano elaborati da Analisi di flusso di Azure.

   Anche se gli eventi precedenti potrebbero sembrare innocui in un primo momento, a causa dell'applicazione della tolleranza di arrivo in ritardo, gli eventi precedenti potrebbero essere eliminati. Se gli eventi sono troppo vecchi, il valore di System.Timestamp viene alterato durante l'inserimento degli eventi. A causa di questo comportamento, Analisi di flusso di Azure è più adatto per scenari di elaborazione di eventi quasi in tempo reale rispetto agli scenari di elaborazione cronologici degli eventi. Per ovviare a questo comportamento, in alcuni casi è possibile impostare il tempo di Eventi pervenuti in ritardo sul valore più grande possibile (20 giorni).

3. Si osserva un ritardo degli output.

   Il primo watermark viene generato al momento calcolato: il tempo massimo dell'evento osservato finora dal sistema, meno le dimensioni della finestra di tolleranza per elementi fuori ordine. Per impostazione predefinita, la tolleranza elementi non in ordine è configurata su zero (00 minuti e 00 secondi). Se la si imposta su un valore più alto, diverso da zero, il primo output del processo di streaming viene ritardato in base a quel valore temporale (o a un valore superiore) per via del tempo del primo limite calcolato.

4. Gli input sono sparsi.

   Quando una determinata partizione è priva di input, il tempo del limite viene calcolato sottraendo dall'ora di arrivo la finestra di tolleranza per arrivo in ritardo. Di conseguenza, se gli eventi di input sono poco frequenti e distanziati, l'output può essere ritardato di quel lasso di tempo. Il valore predefinito di Eventi pervenuti in ritardo è 5 secondi. Ad esempio, un certo ritardo è normale quando si inviano eventi di input uno alla volta. I ritardi possono peggiorare quando si imposta la finestra Eventi pervenuti in ritardo su un valore elevato.

5. Il valore di System.Timestamp è diverso dal tempo indicato nel campo dell'ora dell'evento.

   Come descritto in precedenza, il sistema regola l'ora dell'evento in base alla finestra di tolleranza per elementi fuori ordine o alla finestra di tolleranza per ritardo. Il valore System.Timestamp dell'evento viene modificato, ma il campo dell'ora dell'evento non viene modificato. È possibile usarlo per identificare gli eventi per cui sono stati modificati i timestamp. Se il sistema modifica il timestamp a causa di una delle tolleranze, in genere sono uguali.

Metriche da osservare

È possibile osservare diversi effetti delle tolleranze di tempo per l'ordinamento degli eventi tramite le metriche di Analisi dei flussi di Azure. Le metriche seguenti sono rilevanti:

Dettagli della metrica Ritardo limite

Analisi di flusso di Azure calcola la metrica Ritardo limite sottraendo al tempo del nodo di elaborazione il valore del limite più grande osservato fino a quel momento. Per altre informazioni, vedere Ritardo limite.

Il valore di questa metrica può essere superiore a 0 in condizioni normali per diversi motivi:

1. Ritardo di elaborazione inerente della pipeline di streaming. In genere questo ritardo è nominale.

2. Il ritardo è stato introdotto dalla finestra di tolleranza elementi non in ordine, in quanto il limite è ridotto in base alle dimensioni della finestra di tolleranza.

3. Il ritardo è stato introdotto dalla finestra di tolleranza per arrivo in ritardo, in quanto il limite è ridotto in base alle dimensioni della finestra di tolleranza.

4. Sfasamento orario del nodo di elaborazione che ha generato la metrica.

Esistono diversi altri vincoli di risorse che possono causare un rallentamento della pipeline di streaming. Il valore della metrica Ritardo limite può aumentare per i motivi seguenti:

1. Risorse di elaborazione insufficiente in Analisi di flusso di Azure per gestire il volume degli eventi di input. Per aumentare le risorse, vedere Comprendere e regolare le Unità di Streaming.

2. La velocità effettiva nei gestori eventi di input non è sufficiente, pertanto vengono limitati. Per le possibili soluzioni, vedere Aumentare automaticamente le unità di throughput di Azure Event Hubs.

3. I sink di output, come il database SQL di Azure, l'Archiviazione BLOB o Power BI, non sono forniti di una capacità sufficiente, quindi vengono limitati. Le possibili soluzioni variano notevolmente in base al servizio di output usato.

Frequenza degli eventi di output

Analisi di flusso di Azure usa lo stato del limite come unico trigger per produrre eventi di output. Essendo derivato dai dati di input, il limite è ripetibile durante il ripristino da errori e anche nella rielaborazione avviata dall'utente. Quando si usano funzioni di aggregazione finestra, il servizio produce output solo alla fine delle finestre. In alcuni casi, potrebbe essere necessario visualizzare aggregazioni parziali generate dalle finestre. Le aggregazioni parziali non sono attualmente supportate in Analisi di flusso di Azure.

In altre soluzioni di streaming, gli eventi di output possono essere materializzati in vari punti di trigger, a seconda delle circostanze esterne. In alcune soluzioni è possibile che gli eventi di output per un determinato intervallo di tempo possano essere generati più volte. Man mano che i valori di input vengono ridefiniti, i risultati aggregati diventano più precisi. Gli eventi possono essere speculati in un primo momento e rivisti nel tempo. Ad esempio, quando un determinato dispositivo è offline, un sistema potrebbe usare un valore stimato. In seguito, lo stesso dispositivo si collega alla rete. i dati dell'evento effettivi potrebbero essere inclusi nel flusso di input. I risultati dell'elaborazione di quel intervallo di tempo forniscono un output più preciso.

Esempio illustrato di filigrane

Le immagini seguenti illustrano come i watermark progrediscono in diverse circostanze.

Questa tabella contiene i dati di esempio riportati nei grafici seguenti. Si noti che l'ora dell'evento e l'ora di arrivo cambiano: a volte coincidono, altre volte no.

In questa illustrazione vengono usate le tolleranze seguenti:

• La finestra di arrivo anticipato è di 5 minuti
• La finestra di tolleranza per arrivo in ritardo è di 5 minuti
• La finestra di riordino è di 2 minuti

1. Illustrazione dell'avanzamento della filigrana attraverso questi eventi:

   

   Processi rilevanti illustrati nell'immagine precedente:

   1. Il primo evento (device1) e il secondo evento (device2) hanno ore allineate e vengono elaborati senza modifiche. Il limite avanza in ciascun evento.

   2. Quando viene elaborato il terzo evento (device1), l'ora di arrivo (12:11) è precedente all'ora dell'evento (12:17). L'evento è arrivato 6 minuti prima, quindi viene eliminato a causa del limite di tolleranza di 5 minuti per arrivi in anticipo.

      In questo caso di evento anticipato, il limite non avanza.

   3. Il quarto evento (device3) e il quinto evento (device1) hanno ore allineate e vengono elaborati senza modifiche. Il limite avanza in ciascun evento.

   4. Quando viene elaborato il sesto evento (dispositivo3), l'ora di arrivo (12:17) e l'ora dell'evento (12:12) sono inferiori al livello limite. L'ora dell'evento viene regolata al livello limite (12:17).

   5. Quando viene elaborato il dodicesimo evento (device3), l'ora di arrivo (12:27) è di 6 minuti successiva all'ora dell'evento (12:21). Viene applicato il criterio di arrivo in ritardo. L'ora dell'evento viene modificata (12:22) e, poiché il nuovo valore è sopra il limite (12:21), non vengono applicate ulteriori modifiche.

2. Seconda illustrazione dell'avanzamento del limite senza un criterio di arrivo in anticipo:

   

   In questo esempio non viene applicato alcun criterio di arrivo in anticipo. Gli eventi outlier che arrivano in anticipo aumentano notevolmente il limite. Si noti che il terzo evento (deviceId1 alla volta 12:11) non viene eliminato in questo scenario e la filigrana viene aumentata a 12:15. Come risultato, il quarto evento viene regolato in avanti di 7 minuti (dalle 12:08 alle 12:15).

3. Nell'ultima illustrazione vengono usati i flussi secondari (SU DeviceId). Vengono tracciati più limiti, uno per flusso. Di conseguenza, il numero di eventi di cui viene modificata l'ora è minore.

   

Passaggi successivi

• Considerazioni sull'ordine degli eventi con Analisi di flusso di Azure
• Metriche dell'attività di Analisi di flusso di Azure