Concetti di checkpoint e riproduzione nei processi di Analisi di flusso di Azure
Questo articolo illustra i concetti di checkpoint interno e riproduzione in Analisi di flusso di Azure e il relativo impatto sul ripristino dei processi. Ogni volta che viene eseguito un processo di Analisi di flusso, le informazioni sullo stato vengono mantenute all'interno del servizio e salvate periodicamente in un checkpoint. In alcuni scenari le informazioni dei checkpoint vengono usate per il ripristino dei processi in caso di errore o di aggiornamento. In altre circostanze il checkpoint non può essere usato per il ripristino ed è necessario procedere alla riproduzione.
Logica di query con stato negli elementi temporali
Una delle esclusive funzionalità dei processi di Analisi di flusso di Azure è l'esecuzione dell'elaborazione con stato, ad esempio per funzioni di aggregazione finestra, join temporali e funzioni di analisi 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 di analisi temporale (ISFIRST, LAST e LAG con LIMIT DURATION)
Ripristino di un processo in seguito a errore del nodo e aggiornamento del sistema operativo
Ogni volta che viene eseguito un processo di Analisi di flusso, all'interno del servizio il processo viene scalato orizzontalmente per l'elaborazione su più nodi di lavoro. Per ogni nodo di lavoro viene generato un checkpoint dello stato ogni pochi minuti, in modo da facilitare il ripristino del sistema in caso di errore.
Talvolta può verificarsi un errore su un determinato nodo di lavoro oppure un aggiornamento del sistema operativo per il nodo. In tal caso, Analisi di flusso acquisisce un nuovo nodo integro e ripristina automaticamente lo stato del nodo di lavoro precedente in base al checkpoint disponibile più recente. Per riprendere il lavoro, è necessario eseguire una breve riproduzione che consenta di ripristinare lo stato a partire dal momento in cui è stato acquisito il checkpoint. L'intervallo di ripristino è in genere di solo pochi minuti. Quando è selezionata una quantità sufficiente di unità di streaming per il processo, la riproduzione viene in genere completata in modo rapido.
In una query perfettamente parallela, il tempo necessario per il ripristino in caso di errore di un nodo di lavoro è proporzionale a:
[frequenza di input degli eventi] x [durata dell'intervallo] / [numero di partizioni di elaborazione]
Se si nota un ritardo significativo nell'elaborazione a causa di un errore del nodo e dell'aggiornamento del sistema operativo, valutare l'opportunità rendere la query perfettamente parallela e di ridimensionare il processo per allocare altre unità di streaming. Per altre informazioni, vedere Ridimensionare un processo di Analisi di flusso di Azure per aumentare la velocità effettiva.
La versione corrente di Analisi di flusso non visualizza un report quando viene eseguito questo tipo di ripristino.
Ripristino di un processo in seguito a un aggiornamento del servizio
Occasionalmente Microsoft aggiorna i file binari che eseguono i processi di Analisi di flusso nel servizio di Azure. In questi casi, i processi in esecuzione degli utenti vengono aggiornati a una versione più recente e il processo viene riavviato automaticamente.
Analisi di flusso di Azure usa checkpoint, se possibile per ripristinare i dati dall'ultimo stato di checkpoint. Negli scenari in cui non è possibile usare checkpoint interni, lo stato della query di streaming viene ripristinato interamente usando una tecnica di riproduzione. Per consentire i processi di Analisi di flusso di riprodurre esattamente lo stesso input precedente, è importante impostare i criteri di conservazione dei dati di origine almeno sulla dimensione della finestra temporale nella query. In caso contrario, è possibile che durante l'aggiornamento del servizio vengano restituiti risultati parziali o non corretti perché i dati di origine potrebbero non essere stati conservati abbastanza a lungo da includere la dimensione dell'intera finestra temporale.
La quantità di riproduzione necessaria è in genere proporzionale alla dimensione della finestra moltiplicata per la frequenza media degli eventi. Ad esempio, per un processo con una frequenza di input di 1000 eventi al secondo, una dimensione della finestra superiore a un'ora richiede un'ampia dimensione di riproduzione. Potrebbe essere necessaria un'ora di rielaborazione dei dati per inizializzare lo stato in modo da produrre risultati completi e corretti, che potrebbe causare un ritardo dell'output (nessun output) per un periodo di tempo prolungato. Per le query senza finestre o di altri operatori temporali, come JOIN o LAG, non è prevista nessuna riproduzione.
Stimare il tempo di ripristino
Per stimare la durata del ritardo a causa di un aggiornamento del servizio, è possibile adottare questa tecnica:
Caricare hub eventi di input con dati sufficienti per coprire le dimensioni più grandi della finestra nella query, a frequenza di eventi prevista. Il timestamp degli eventi deve corrispondere approssimativamente all'ora reale durante tale periodo, come per un feed di input in tempo reale. Ad esempio, se nella query è presente una finestra di 3 giorni, inviare eventi a Hub eventi per tre giorni e continuare a inviare eventi.
Avviare il processo usando Now come ora di inizio.
Misurare il tempo tra l'ora di inizio e il momento in cui viene generato il primo output. Questo tempo corrisponde approssimativamente al ritardo che subirebbe il processo durante un aggiornamento del servizio.
Se il ritardo è troppo lungo, provare a suddividere il processo e ad aumentare il numero di unità di streaming, in modo da distribuire il carico a più nodi. In alternativa, è consigliabile ridurre le dimensioni delle finestre nella query ed eseguire ulteriori aggregazioni o altre elaborazioni con stato sull'output prodotto dal processo di Analisi di flusso nel sink downstream, ad esempio usando Azure SQL Database.
In caso di problemi di stabilità generale del servizio durante l'aggiornamento di processi di importanza cruciale, valutare l'opportunità di eseguire processi duplicati in aree di Azure abbinate. Per altre informazioni, vedere Garantire l'affidabilità dei processi di Analisi di flusso durante gli aggiornamenti del servizio.
Ripristino di un processo in seguito all'arresto e al riavvio da parte di un utente
Per modificare la sintassi di query in un processo di streaming o per modificare gli input e gli output, è necessario arrestare il processo per apportare le modifiche e aggiornare la progettazione. In scenari di questo tipo, quando un utente arresta e riavvia il processo di streaming, lo scenario di ripristino è simile a quello relativo all'aggiornamento del servizio.
Quando un processo viene riavviato da un utente, i dati dei checkpoint non possono essere utilizzati. Per stimare il ritardo dell'output durante il riavvio, seguire la stessa procedura descritta nella sezione precedente e adottare un approccio di mitigazione analogo se il ritardo è troppo lungo.
Passaggi successivi
Per altre informazioni sulla scalabilità e sull'affidabilità, vedere questi articoli: