Comprendere e modificare le unità di streaming di Analisi di flusso

Informazioni sull'unità di streaming e sul nodo di streaming

Le unità di streaming 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 unità di streaming corrispondono a un singolo nodo di streaming per un processo. I processi possono essere eseguiti anche con 1 e 3 unità di streaming e corrispondono ai nodi di streaming frazionari. Il ridimensionamento si verifica in incrementi di 6 oltre 6 processi su 6, a 12, 18, 24 e versioni successive 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 V2s corrisponde 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 unità di streaming, visitare la pagina prezzi di Analisi di flusso di Azure.

Informazioni sulle conversioni delle unità di streaming e sulla posizione in cui si applicano

È disponibile una conversione automatica delle unità di streaming che si verificano dal livello API REST all'interfaccia utente (portale di Azure e Visual Studio Code). Si noterà questa conversione nel log attività e in cui i valori di UNITÀ di streaming sono diversi dai valori dell'interfaccia utente. Questo è per progettazione e il motivo è che 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, ... 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 (UI)	V2 standard (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 sia disponibile una risorsa sufficiente allocata per mantenere i processi in esecuzione 24/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 delle unità di streaming è elevato (superiore all'80%) o se gli eventi di input vengono registrati (anche con un basso utilizzo su% poiché non mostra l'utilizzo della CPU), il carico di lavoro richiede probabilmente più risorse di calcolo, che richiede un aumento del numero di unità di streaming. È consigliabile mantenere la metrica su su inferiore all'80% per tenere conto di 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 unità di streaming. Inoltre, è possibile usare metriche di ritardo limite ed eventi registrati di nuovo per verificare se si verifica un impatto.

Configurare le unità di streaming di Analisi di flusso (UNITÀ di streaming)

1. Accedi al portale di Azure.

2. Nell'elenco delle risorse trovare il processo di Analisi di flusso da ridimensionare e aprirlo. 

3. Nell'intestazione Configura della pagina del processo selezionare Ridimensiona. Il numero predefinito di UR è 1 durante la creazione di un processo.

4. Scegliere l'opzione SU nell'elenco a discesa per impostare le UNITÀ di streaming per il processo. Si noti che si è limitati a un intervallo di unità di ricerca specifico. 

5. È possibile modificare il numero di UR assegnate al processo durante l'esecuzione. È possibile che sia possibile scegliere tra un set di valori di unità di streaming quando il processo è in esecuzione se il processo usa un output non partizionato. In alternativa, è disponibile una query in più passaggi con valori PARTITION BY diversi.

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 altre informazioni sul monitoraggio delle metriche nel portale, vedere Monitorare il processo di Analisi di flusso con 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ù UR rispetto alle esigenze. 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 altre informazioni sulla scelta del numero corretto di unità di streaming, 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 le unità di streaming 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, è consigliabile prendere in considerazione molti consigli sulle procedure consigliate.

Si noti che un processo con logica di query complessa potrebbe avere un utilizzo elevato della su% anche quando non riceve continuamente eventi di input. 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 unità di streaming 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 aumenta il numero di eventi per unità di tempo, la percentuale di unità di streaming aumenta nella maggior parte dei casi.

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:

1. Funzioni di aggregazione finestra: GROUP BY di finestre temporali scorrevoli, di salto e a cascata

2. Join temporali: JOIN con funzione DATEDIFF

3. 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 utilizzata (dimensioni dello stato) per un'aggregazione con finestra non è sempre proporzionale direttamente alle dimensioni 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 attenuare eventuali problemi causati da cardinalità elevata nella query precedente, è possibile inviare eventi a Hub eventi partizionati da clusteride aumentare il numero di istanze della query consentendo al sistema di elaborare ogni partizione di input separatamente usando PARTITION BY , come illustrato nell'esempio seguente:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Una volta partizionata, 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 partizionate dalla chiave di raggruppamento per evitare la necessità di un passaggio di riduzione. Per altre informazioni, vedere Panoramica di Hub eventi. 

Join temporali

La memoria utilizzata (dimensioni dello stato) di un join temporale è proporzionale al numero di eventi nella sala di disattivazione temporale del join, ovvero la frequenza di input degli eventi moltiplicata per le dimensioni della stanza. 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, è possibile che vengano visualizzati molti annunci e pochi clic su di esso e che sia necessario mantenere tutti gli eventi nell'intervallo di tempo. La memoria consumata è proporzionale alle dimensioni della finestra e alla frequenza degli eventi. 

Per risolvere questo problema, inviare eventi a Hub eventi partizionati dalle chiavi di join (ID in questo caso) e aumentare il numero di istanze della query consentendo al sistema di elaborare ogni partizione di input separatamente usando PARTITION BY , come illustrato 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 

Una volta partizionata, 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 utilizzata dalle funzioni analitiche non è proporzionale alle dimensioni della finestra, ma piuttosto al numero di partizioni in ogni intervallo di tempo.

La correzione è simile a quella per il join temporale. È possibile aumentare il numero di istanze per la query usando PARTITION BY. 

Buffer non ordinato

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. Una volta partizionata, 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. 

Numero di 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/s di input. È quindi possibile ottimizzare associando il numero di unità di streaming di Analisi di flusso al numero di partizioni nell'hub eventi.

In genere, un processo configurato con un'unità di streaming 1/3 è sufficiente per un hub eventi con due partizioni ,ovvero il valore minimo per l'hub eventi. Se l'hub eventi ha più partizioni, il processo di Analisi di flusso usa più risorse, ma non usa necessariamente la velocità effettiva aggiuntiva fornita da Hub eventi.

Per un processo con 1 unità di streaming V2, potrebbero essere necessarie 4 o 8 partizioni dall'hub eventi. È tuttavia opportuno evitare di configurare troppe partizioni non necessarie poiché ciò determina un utilizzo eccessivo delle risorse, Ad esempio, un hub eventi con 16 partizioni o più grandi in un processo di Analisi di flusso con 1 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 del processo 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 portale di Azure
• Analizzare le prestazioni dei processi di Analisi di flusso con le dimensioni delle metriche
• Informazioni e modifica delle unità di streaming