Concetti di checkpoint e riproduzione nei processi di Analisi di flusso di Azure

Analisi di flusso di Azure mantiene internamente le informazioni di stato ogni volta che un lavoro viene eseguito, e periodicamente salva quello stato in un checkpoint. Se un lavoro fallisce o viene aggiornato, Stream Analytics può utilizzare l'ultimo checkpoint per recuperare. Quando il processo non può utilizzare il checkpoint, esegue invece una riesecuzione, rielaborando i recenti eventi di input per ricostruirne lo stato.

Questo articolo spiega come funzionano i checkpoint e le repliche in Analisi di flusso di Azure e come influenzano il tempo necessario per il recupero di un lavoro.

Logica di query con stato negli elementi temporali

Una delle funzionalità distintive di un processo di Analisi di flusso di Azure è la possibilità di eseguire l’elaborazione con stato, ad esempio aggregazioni su finestra, join temporali e funzioni analitiche temporali. Ognuno di questi operatori mantiene le informazioni sullo stato durante l'esecuzione del processo. La dimensione massima della finestra temporale per questi elementi di query è sette giorni.

Il concetto di finestra temporale è presente in diversi elementi di query di Analisi di flusso:

  • Funzioni di aggregazione finestra (GROUP BY di finestre temporali scorrevoli, di salto e a cascata)
  • Join temporali (JOIN con DATEDIFF)
  • Funzioni analitiche temporali (ISFIRST, LAST e LAG con DURATA LIMITE)

Ripristino attività da guasto del nodo, incluso l'aggiornamento del sistema operativo

Ogni volta che un lavoro di Stream Analytics viene eseguito, il servizio lo scala internamente per svolgere lavoro su più nodi di lavoro. Il servizio controlla lo stato di ogni nodo worker ogni pochi minuti, il che lo aiuta a recuperare in caso di guasto.

A volte, un determinato nodo worker può non riuscire, oppure si può verificare un aggiornamento del sistema operativo per quel nodo worker. Per eseguire il ripristino automatico, Stream Analytics acquisisce un nuovo nodo integro e ripristina lo stato del precedente nodo di lavoro a partire dall'ultimo checkpoint disponibile. Per riprendere il lavoro, il processo rielabora una piccola quantità di dati per ripristinare lo stato dall'ultimo checkpoint. In genere, il divario di ripristino è di pochi minuti. Quando selezioni un numero sufficiente di unità di streaming per l'operazione, la riesecuzione viene completata rapidamente.

In una query perfettamente parallela, il tempo necessario per il ripristino in caso di errore di un nodo di lavoro è proporzionale a:

[frequenza eventi di input] x [lunghezza del gap] / [numero di partizioni di elaborazione]

Se mai noti ritardi di elaborazione significativi a causa di guasti del nodo e aggiornamento del sistema operativo, considera di rendere la query completamente parallela e scala il lavoro per allocare più unità di streaming. Per altre informazioni, vedere Ridimensionare un processo di Analisi di flusso di Azure per aumentare la velocità effettiva.

Attualmente Stream Analytics non mostra un report quando avviene questo tipo di processo di recupero.

Recupero del lavoro dopo un aggiornamento del servizio

Microsoft aggiorna occasionalmente i file binari che eseguono i processi di Analisi di flusso nel servizio di Azure. In questi momenti, Microsoft aggiorna i lavori in esecuzione a una versione più recente e il lavoro si riavvia automaticamente.

Analisi di flusso di Azure utilizza punti di controllo ove possibile per ripristinare i dati dall'ultimo stato registrato. Quando Stream Analytics non può usare checkpoint interni, una tecnica di riproduzione ripristina l'intero stato della query di streaming. Per permettere ai lavori di Stream Analytics di riprodurre esattamente lo stesso input, imposta la politica di retention dei dati sorgente almeno alle dimensioni delle finestre della tua query. Non farlo potrebbe portare a risultati errati o parziali durante un aggiornamento del servizio, perché Stream Analytics potrebbe non conservare i dati sorgente abbastanza indietro da includere l'intera dimensione della finestra.

In generale, la quantità di riproduzione necessaria è proporzionale alla dimensione della finestra moltiplicata per la frequenza media degli eventi. Ad esempio, per un processo con un tasso di input di 1.000 eventi al secondo, una finestra superiore a un'ora ha una dimensione di replay elevata. Il servizio potrebbe dover rielaborare fino a un'ora di dati per inizializzare lo stato e poter produrre risultati completi e corretti, il che potrebbe causare ritardi in uscita (nessuna uscita) per un periodo prolungato. Le query senza finestre o altri operatori temporali, come JOIN o LAG, hanno replay pari a zero.

Stimare il tempo di ripristino

Per stimare la durata del ritardo dovuto a un aggiornamento del servizio, segui questa tecnica:

  • Carica l'hub eventi di input con dati sufficienti per coprire la dimensione di finestra più grande nella tua query, al tasso di evento atteso. Le marche temporali degli eventi dovrebbero essere vicine all'ora dell'orologio di sistema per tutta la durata di quel periodo, come se provenissero da un flusso di input in tempo reale. Ad esempio, se hai una finestra di tre giorni nella tua query, invia gli eventi all'event hub per tre giorni e continua a inviare eventi.
  • Inizia il lavoro usando Now come orario di inizio.
  • Misura il tempo tra l'inizio e il momento in cui il lavoro genera la sua prima produzione. Questo tempo corrisponde approssimativamente al ritardo che il lavoro subisce durante un aggiornamento del servizio.
  • Se il ritardo è troppo lungo, prova a suddividere il lavoro e ad aumentare il numero di unità di streaming in modo che il carico si distribuisca su più nodi. In alternativa, valuta la possibilità di ridurre le dimensioni delle finestre nella query ed eseguire ulteriori operazioni di aggregazione o altre elaborazioni con stato sull'output generato dal processo Stream Analytics nel sink a valle, ad esempio tramite database SQL di Azure.

Per problemi generali di stabilità del servizio durante l'aggiornamento di processi cruciali, prendere in considerazione l'esecuzione di processi duplicati nelle aree di Azure abbinate. Per altre informazioni, vedere Garantire l'affidabilità dei processi di Analisi di flusso durante gli aggiornamenti del servizio.

Recupero del lavoro da una fermata e avvio iniziata dall'utente

Per modificare la sintassi delle query su un lavoro di streaming, o per modificare input e output, devi fermare il job per apportare le modifiche e aggiornare il design del job. In questi casi, quando interrompi il lavoro di streaming e lo riavvii, lo scenario di recupero è simile a un aggiornamento del servizio.

Un riavvio di un lavoro avviato dall'utente non può usare i dati dei checkpoint. Per stimare il ritardo di uscita durante tale riavvio, si utilizza la stessa procedura descritta nella sezione precedente e applica una mitigazione simile se il ritardo è troppo lungo.

Contenuti correlati

Per altre informazioni sull'affidabilità e la scalabilità, vedere gli articoli seguenti:

  • Last updated on