Comprendere e regolare le unità di streaming in Analisi di flusso
Informazioni sull'unità di streaming e sul nodo di streaming
Le Unità di streaming (SU) rappresentano le risorse di calcolo allocate per eseguire un processo di analisi di flusso. Più alto è il numero di unità di streaming, maggiori sono le risorse di memoria e CPU allocate per il processo. Questa capacità consente di concentrarsi sulla logica di query, senza doversi preoccupare di gestire l'hardware, per eseguire il processo di Analisi di flusso nei tempi previsti.
Analisi di flusso di Azure supporta due strutture di unità di streaming: SU V1 (da deprecare) e SU V2 (scelta consigliata).
Il modello SU V1 è l'offerta originale di ASA in cui ogni 6 SU corrispondono a un singolo nodo di streaming per un processo. I processi possono essere eseguiti anche con 1 e 3 SU e corrispondono ai nodi di streaming frazionari. Il ridimensionamento si verifica in incrementi di 6 oltre 6 processi di SU, a 12, 18, 24 e oltre aggiungendo altri nodi di streaming che forniscono risorse di calcolo distribuite.
Il modello SU V2 (scelta consigliata) è una struttura semplificata con prezzi favorevoli per le stesse risorse di calcolo. Nel modello SU V2, 1 SU V2 corrisponde a un nodo di streaming per il processo. 2 SU V2 corrispondono a 2, 3 a 3 e così via. I processi con 1/3 e 2/3 SU V2 sono disponibili anche con un nodo di streaming, ma una frazione delle risorse di calcolo. I processi 1/3 e 2/3 SU V2 offrono un'opzione conveniente per i carichi di lavoro che richiedono una scalabilità inferiore.
La potenza di calcolo sottostante per le unità di streaming V1 e V2 è la seguente:
Per informazioni sui prezzi delle SU, visitare la pagina prezzi di Analisi di flusso di Azure.
Informazioni sulle conversioni delle unità di streaming e quando si applicano
È disponibile una conversione automatica delle Unità di streaming che avviene dal livello API REST all'interfaccia utente (portale di Azure e Visual Studio Code). Si noterà questa conversione nel log attività e ogni qualvolta i valori SU sono diversi dai valori nell'interfaccia utente. Questo è per progettazione, in quanto i campi dell'API REST sono limitati a valori interi e i processi ASA supportano nodi frazionari (1/3 e 2/3 Unità di streaming). L'interfaccia utente di ASA visualizza i valori dei nodi 1/3, 2/3, 1, 2, 3, ... e così via, mentre il back-end (log attività, livello API REST) visualizza gli stessi valori moltiplicati rispettivamente per 3, 7, 10, 20, 30.
| Standard | Standard V2 (interfaccia utente) | Standard V2 (back-end, ad esempio log, API REST e così via) |
|---|---|---|
| 1 | 1/3 | 3 |
| 3 | 2/3 | 7 |
| 6 | 1 | 10 |
| 12 | 2 | 20 |
| 18 | 3 | 30 |
| ... | ... | ... |
In questo modo è possibile comunicare la stessa granularità ed eliminare il separatore decimale a livello API per gli SKU V2. Questa conversione è automatica e non ha alcun impatto sulle prestazioni del processo.
Informazioni sull'utilizzo della memoria e sul consumo
Per ottenere l'elaborazione di flussi a bassa latenza, i processi di Analisi di flusso di Azure eseguono tutta l'elaborazione in memoria. Quando la memoria viene esaurita, il processo di streaming non riesce. Di conseguenza, per un processo di produzione è importante monitorare l'utilizzo delle risorse di un processo di streaming e assicurarsi che siano state allocate risorse sufficienti per mantenere il processo in esecuzione 24 ore su 24, 7 giorni su 7.
La metrica di utilizzo in percentuale delle unità di streaming, da 0% a 100%, descrive l'utilizzo di memoria del carico di lavoro. Per un processo di streaming con footprint minimo, questa metrica è in genere compresa tra 10% e 20%. Se l'utilizzo della percentuale di SU è elevato (superiore all'80%) o se gli eventi di input si accumulano (anche con un percentuale bassa di SU utilizzata, poiché non mostra l'utilizzo del CPU), il carico di lavoro richiede probabilmente più risorse di calcolo, il che richiede un aumento del numero di unità di streaming. È consigliabile mantenere la metrica delle SU al di sotto dell'80% in modo da tenere conto dei picchi occasionali. Per reagire a carichi di lavoro aumentati e aumentare le unità di streaming, valutare la possibilità di impostare un avviso dell'80% sulla metrica Utilizzo delle SU. Inoltre, è possibile usare metriche di ritardo limite ed eventi accumulati per verificare un eventuale impatto.
Configurare le unità di streaming (SU) di Analisi di flusso
Accedi al portale di Azure.
Nell'elenco delle risorse trovare il processo di Analisi di flusso da ridimensionare e aprirlo.
Nell'intestazione Configura della pagina del processo selezionare Ridimensiona. Il numero predefinito di SU è 1 alla creazione di un processo.
Scegliere l'opzione SU nell'elenco a discesa per impostare le SU per il processo. Si noti il limite di un intervallo specifico delle SU.
È possibile modificare il numero di SU assegnate al processo durante la sua esecuzione. È possibile che la scelta sia limitata a un set di valori di SU quando il processo è in esecuzione, se il processo usa un non-partitioned output. oppure se è disponibile una query in più passaggi con diverse valori PARTITION BY.
Monitorare le prestazioni del processo
Usando il portale di Azure, è possibile tenere traccia delle metriche correlate alle prestazioni di un processo. Per informazioni sulla definizione delle metriche, vedere Metriche dei processi di Analisi di flusso di Azure. Per maggiori informazioni sul monitoraggio delle metriche nel portale, vedere Monitorare il processo di Analisi di flusso con il portale di Azure.
Calcolare la velocità effettiva prevista del carico di lavoro. Se la velocità effettiva è inferiore al previsto, ottimizzare la partizione di input e la query, quindi aggiungere unità di streaming al processo.
Quante unità di streaming sono necessarie per un processo?
Il numero di unità di streaming necessarie per un particolare processo dipende dalla configurazione della partizione per gli input e dalla query definita nel processo. La pagina Ridimensiona consente di impostare il numero corretto di unità di streaming. È consigliabile allocare più SU di quelle necessarie. Il motore di elaborazione di Analisi di flusso è ottimizzato per la latenza e la velocità effettiva al costo di allocazione di memoria aggiuntiva.
In generale, la procedura consigliata consiste nell'iniziare con 1 SU V2 per le query che non usano PARTITION BY. Determinare quindi il punto critico usando un metodo di valutazione e correzione degli errori con cui modificare il numero di unità di streaming dopo aver passato quantità rappresentative di dati e aver esaminato la metrica di utilizzo in percentuale delle unità di streaming. Il numero massimo di unità di streaming che possono essere usate da un processo di Analisi dei flussi dipende dal numero di passaggi nella query definita per il processo e dal numero di partizioni in ogni passaggio. Altre informazioni sui limiti sono disponibili qui.
Per maggiori informazioni sulla scelta del giusto numero di SU, vedere questa pagina: Ridimensionare i processi di Analisi di flusso di Azure per aumentare la velocità effettiva.
Nota
Il numero di unità di streaming necessarie per un particolare processo dipende dalla configurazione delle partizioni per gli input e dalla query definita per il processo. È prevista una quota massima di unità di streaming che è possibile selezionare per un processo. Per informazioni sulla quota di sottoscrizione di Analisi di flusso di Azure, vedere Limiti di Analisi di flusso. Per superare la quota massima di unità di streaming per le sottoscrizioni, contattare il supporto tecnico Microsoft. I valori validi per SU per processo sono 1/3, 2/3, 1, 2, 3 e così via.
Fattori che determinano un maggiore utilizzo in percentuale delle unità di streaming
Gli elementi di query temporali costituiscono il set principale degli operatori con stato forniti da Analisi di flusso. Analisi di flusso gestisce lo stato di queste operazioni internamente per conto dell'utente, controllando l'utilizzo della memoria, i checkpoint per la resilienza e il ripristino dello stato durante gli aggiornamenti del servizio. Anche se Analisi di flusso gestisce completamente gli stati, è opportuno che gli utenti prendano in considerazione alcune indicazioni relative alle procedure consigliate.
Si noti che un processo con logica di query complessa potrebbe presentare un'elevata percentuale di utilizzo di SU anche quando non riceve eventi di input in modo continuo. Questa situazione può verificarsi dopo un picco improvviso negli eventi di input e output. Se la query è complessa, il processo potrebbe continuare a mantenere lo stato in memoria.
La percentuale di utilizzo dell'unità di archiviazione può improvvisamente scendere a 0 per un breve periodo di tempo prima di tornare ai livelli previsti. Ciò si verifica a causa di errori temporanei o dell'avvio di aggiornamenti di sistema. L'aumento del numero di unità di streaming per un processo potrebbe non ridurre l'utilizzo della percentuale di SU se la query non è completamente parallela.
Durante il confronto dell'utilizzo in un periodo di tempo, usare le metriche della frequenza degli eventi. Le metriche InputEvents e OutputEvents mostrano il numero di eventi letti ed elaborati. Esistono metriche che indicano anche il numero di eventi di errore, ad esempio errori di deserializzazione. Quando il numero di eventi per unità di tempo aumenta, la percentuale di SU nella maggior parte dei casi aumenta.
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. 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 funzione DATEDIFF
Funzioni di analisi temporale: ISFIRST, LAST e LAG con LIMIT DURATION
I fattori seguenti influiscono sulla memoria usata (parte della metrica di unità di streaming) dai processi di Analisi di flusso:
Funzioni di aggregazione finestra
La memoria consumata (dimensione dello stato) per un aggregato a finestre non è sempre direttamente proporzionale alla dimensione della finestra. È invece proporzionale alla cardinalità dei dati o al numero di gruppi in ogni finestra temporale.
Ad esempio, nella query seguente il numero associato a clusterid è la cardinalità della query.
SELECT count(*)
FROM input
GROUP BY clusterid, tumblingwindow (minutes, 5)
Per risolvere i problemi causati dalla cardinalità elevata nella query precedente, è possibile inviare a Hub eventi gli eventi ripartiti in base a clusterid e aumentare il numero di query, consentendo al sistema di elaborare ogni partizione di input separatamente usando PARTITION BY, come mostrato nell'esempio seguente:
SELECT count(*)
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)
In seguito alla ripartizione, la query viene distribuita su più nodi. Di conseguenza, il numero di valori clusterid in arrivo in ogni nodo diminuisce, riducendo a sua volta la cardinalità dell'operatore GROUP BY.
Le partizioni di Hub eventi devono essere ripartite in base alla chiave di raggruppamento per evitare la necessità di un passaggio di riduzione. Per altre informazioni, vedere Panoramica di Hub eventi.
Join temporali
La memoria consumata (dimensione dello stato) di un join temporale è proporzionale al numero di eventi nella wiggle room temporale del join, che è il tasso di input degli eventi moltiplicato per la dimensione della wiggle room. In altre parole, la memoria utilizzata dai join è proporzionale all'intervallo di tempo DateDiff moltiplicato per la frequenza media degli eventi.
Il numero di eventi senza corrispondenza nel join influisce sull'utilizzo della memoria per la query. La query seguente cerca le impressioni di annunci che generano clic:
SELECT clicks.id
FROM clicks
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.
In questo esempio, potrebbero apparire molti annunci pubblicitari su cui pochi utenti cliccheranno, ed è necessario mantenere tutti gli eventi nell'intervallo di tempo. La memoria consumata è proporzionale alle dimensioni della finestra e alla frequenza degli eventi.
Per rimediare a questo problema, inviare gli eventi a Hub eventi ripartendoli in base alle chiavi di join (in questo caso l'ID) e aumentare il numero di query consentendo al sistema di elaborare ogni partizione di input separatamente usando PARTITION BY, come mostrato di seguito:
SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10
In seguito alla ripartizione, la query viene distribuita su più nodi. Di conseguenza, il numero di eventi in arrivo in ogni nodo diminuisce, riducendo a sua volta le dimensioni dello stato mantenuto nell'intervallo di join.
Funzioni di analisi temporale
La memoria utilizzata (dimensione dello stato) per una funzione di analisi temporale è proporzionale alla frequenza degli eventi moltiplicata per la durata. La memoria consumata dalle funzioni di analisi non è proporzionale alla dimensione della finestra, ma piuttosto al numero di partizioni in ogni finestra temporale.
La correzione è simile a quella per il join temporale. È possibile aumentare il numero di istanze per la query usando PARTITION BY.
Buffer non in ordine
L'utente può configurare le dimensioni del buffer non in ordine nel riquadro di configurazione Ordinamento eventi. Il buffer viene usato per contenere gli input per la durata dell'intervallo e per riordinarli. Le dimensioni del buffer sono proporzionali alla frequenza di input degli eventi moltiplicata per la dimensione dell'intervallo per l'ordine non corretto. La dimensione predefinita dell'intervallo è 0.
Per correggere l'overflow del buffer non in ordine, aumentare il numero di istanze per la query usando PARTITION BY. In seguito alla ripartizione, la query viene distribuita su più nodi. Di conseguenza, il numero di eventi in arrivo in ogni nodo diminuisce, riducendo a sua volta il numero di eventi in ogni buffer di riordinamento.
Conteggio delle partizioni di input
Ogni partizione di input di un processo ha un buffer. Maggiore è il numero di partizioni di input, maggiore è il numero di risorse utilizzate dal processo. Per ogni unità di streaming, Analisi di flusso di Azure può elaborare circa 7 MB di input al secondo. È pertanto possibile effettuare l’ottimizzaizone definendo una corrispondenza tra il numero di unità di streaming di Analisi di flusso e il numero di partizioni nell'istanza di hub eventi.
Un processo configurato con un’unità di streaming di 1/3 è in genere sufficiente per un'istanza di hub eventi con due partizioni (ovvero il numero minimo di partizioni per hub di eventi). Se l'istanza di hub eventi ha più partizioni, il processo di Analisi di flusso consuma più risorse, ma non necessariamente usa la velocità effettiva aggiuntiva fornita da Hub eventi.
Per un processo con 1 unità di streaming V2, possono essere necessarie 4 o 8 partizioni in hub eventi. È tuttavia opportuno evitare di configurare troppe partizioni non necessarie poiché ciò determina un utilizzo eccessivo delle risorse, Ad esempio, un'istanza di hub eventi con 16 o più partizioni in un processo di Analisi di flusso con una sola unità di streaming.
Dati di riferimento
I dati di riferimento in Analisi di flusso di Azure vengono caricati in memoria per consentire la ricerca rapida. Con l'implementazione corrente ogni operazione di join con dati di riferimento mantiene una copia dei dati di riferimento in memoria, anche se il join viene eseguito con gli stessi dati di riferimento più volte. Per le query con PARTITION BY, ogni partizione include una copia dei dati di riferimento, in modo che le partizioni siano completamente separate. Con l'effetto moltiplicatore l'utilizzo della memoria può aumentare rapidamente se si esegue il join con i dati di riferimento più volte con più partizioni.
Uso di funzioni definite dall'utente
Quando si aggiunge una funzione definita dall'utente, Analisi di flusso di Azure carica il runtime JavaScript in memoria. Questo comportamento influisce sulla percentuale di unità di streaming.
Passaggi successivi
- Create parallelizable queries in Azure Stream Analytics (Creare query eseguibili in parallelo in Analisi di flusso di Azure)
- Ridimensionare i processi di Analisi di flusso di Azure per aumentare la velocità effettiva dell'elaborazione dei flussi di dati
- Metriche dei processi di Analisi di flusso di Azure
- Dimensioni delle metriche dei processi di Analisi di flusso di Azure
- Monitorare il processo di Analisi di flusso con il portale di Azure
- Analizzare le prestazioni dei processi di Analisi di flusso con le dimensioni delle metriche
- Informazioni e modifica delle unità di streaming