Criteri di asimmetria temporale (Analisi di flusso di Azure)

In Analisi di flusso tutti gli eventi del flusso di dati hanno un timestamp associato. Gli utenti possono usare la parola chiave TIMESTAMP BY per scegliere tra una di queste due volte diverse:

• Ora dell'applicazione, ovvero l'ora in cui vengono generati gli eventi , contrassegnati dall'applicazione o dal dispositivo che genera gli eventi. Quando si usa l'ora dell'applicazione, è possibile elaborare tutti gli eventi usando una sequenza temporale globale o analizzare ogni dispositivo/partizione usando una sequenza temporale personalizzata usando flussi secondari;
• Ora di arrivo, ora in cui l'evento ha raggiunto il cloud ,ad esempio l'ora di arrivo in hub IoT o hub eventi.

Oltre alla scelta del timestamp, gli utenti potrebbero dover definire i criteri Arrivo in ritardo e Fuori ordine a causa dei problemi seguenti:

• I produttori degli eventi hanno sfasamenti dell'orologio. Questo è comune quando i produttori provengono da computer diversi, quindi hanno orologi diversi.
• A causa della latenza di rete, gli eventi provengono dallo stesso orologio possono arrivare all'hub eventi o hub IoT in un ordine diverso da quando sono stati originati
• Sfasamento dell'orologio tra le partizioni. Quando si usano query non partizionate, gli eventi di tutte le partizioni vengono uniti dal timestamp scelto dall'utente. Gli sfasamenti di clock tra le partizioni possono comportare un ritardo di elaborazione, perché la fusione deve attendere la partizione più lenta.

I flussi di input che non sono in ordine possono essere:

• Ordinato (e quindi ritardato).
• Regolati dal sistema, in base al criterio specificato dall'utente.

Analisi di flusso di Azure tollera eventi in ritardo e non in ordine durante l'elaborazione in base al tempo applicazione.

Criteri non in ordine

La presenza di eventi ordinati in base al tempo è molto importante nell'analisi di streaming. Tuttavia, a causa dei 3 problemi indicati in precedenza, è spesso il caso in cui vengono ricevuti in ordine non ordinato, che può influire sui risultati delle query. Il criterio out-of order consente di riordinare gli eventi in base al timestamp quando arrivano all'interno della finestra di tolleranza definita. Gli eventi che arrivano più tardi della tolleranza vengono eliminati o modificati, a seconda dell'impostazione scelta.

• Regolati: regolati in modo che sembrino arrivati nel momento di massimo ritardo accettabile.
• Eliminati: rimossi.

Questa impostazione può essere modificata nella portale di Azure (nella scheda "Ordinamento eventi" di un processo). Per altre informazioni, vedere la pagina considerazioni sull'ordine degli eventi.

Quando si imposta un criterio non ordinato maggiore di 0, Analisi di flusso memorizza nel buffer gli eventi fino a tale finestra e li riordina usando il timestamp definito dall'utente prima di applicare la trasformazione temporale. A partire da una prima finestra di 3 secondi è una procedura consigliata e quindi ottimizzare il valore per ridurre il numero di eventi che ottengono la regolazione del tempo. Si noti che a causa del buffering, l'effetto collaterale è l'output ritardato dalla stessa quantità di tempo. Di conseguenza, sarà necessario ottimizzare il valore per ridurre il numero di eventi non in ordine e mantenere bassa la latenza.

Tolleranza arrivo in ritardo

La finestra di tolleranza per arrivo in ritardo viene usata per tenere conto del ritardo negli eventi che raggiungono l'origine di input a causa di vari motivi descritti in precedenza. In breve, la finestra di arrivo in ritardo è il ritardo massimo tra la generazione dell'evento e la ricezione dell'evento nell'origine di input. La modifica in base alla tolleranza per arrivo in ritardo viene eseguita per prima, seguita da quella degli elementi non in ordine. La colonna System.Timestamp() avrà il timestamp finale assegnato all'evento.

Questa impostazione è applicabile solo quando l'elaborazione si basa sul tempo applicazione. In caso contrario, viene ignorata. Può anche essere impostato nella portale di Azure (nella scheda "Ordinamento eventi" di un processo). Per altre informazioni, vedere la pagina considerazioni sull'ordine degli eventi.

Quando un evento è in ritardo, il timestamp viene modificato in base all'ora di accodamento corrente nell'origine di input meno la finestra di tolleranza per arrivo in ritardo (o eliminata, a seconda dell'azione scelta). Quando più partizioni dello stesso flusso di input o più flussi di input vengono combinati insieme, la tolleranza di arrivo in ritardo è la quantità massima di tempo di attesa dei nuovi dati di ogni partizione.

Tolleranza arrivo in ritardo ed eventi sparse

I criteri di arrivo in ritardo consentono ad Analisi di flusso di spostare il tempo in avanti e generare l'output in modo più timelier in assenza di eventi di input. Ciò è molto utile quando gli eventi di input sono di tipo sparse (o non vengono ricevuti affatto in alcune partizioni dell'hub eventi).

Ad esempio, gli eventi di input vengono generati una volta ogni minuto per una query select*. Senza usare questo criterio, Analisi di flusso non può generare risultati di output fino a quando gli eventi non arrivano a tutte le partizioni di Hub eventi (per spostare il tempo in avanti). Questo può significare 16 minuti se l'hub eventi ha 16 partizioni e che ogni evento viene recapitato a una partizione diversa. Con il criterio predefinito di 5 secondi, l'orologio viene spostato in avanti di 5 secondi dopo il primo evento, quindi l'evento di output viene generato 5 secondi dopo il primo evento.

Vedere anche

Gestione del tempo (Analisi di flusso di Azure)
System.Timestamp() (Analisi di flusso)
TIMESTAMP BY (Analisi di flusso di Azure)
Considerazioni sull'ordine degli eventi