Ridimensionare un processo di Analisi di flusso di Azure per aumentare la velocità effettiva

Questo articolo illustra come ottimizzare una query Analisi di flusso di Azure per aumentare la velocità effettiva. Usare questi modelli di ridimensionamento per gestire un carico maggiore usando più larghezza di banda, CPU e risorse di memoria.

Analisi di flusso di Azure misura la capacità di calcolo in unità di streaming (SUs). Ogni unità SU V2 rappresenta la capacità completa di un singolo nodo di calcolo. Una query embarrassingly parallel è una query in cui ogni partizione di input può essere elaborata in modo indipendente, senza condivisione di dati tra le partizioni.

Prerequisiti

Prima di iniziare, vedere questi articoli:

• Comprendere e regolare le unità di streaming
• Creare processi parallelizzabili

Ridimensionare una query completamente parallelizzabile

Se la query è perfettamente parallela tra le partizioni di input, seguire questa procedura:

1. Scrivere la query in modo che utilizzi la parola chiave PARTITION BY. Per altre informazioni, vedere Usare la parallelizzazione delle query in Analisi di flusso di Azure.

2. A seconda dei tipi di output usati nella query, alcuni output possono non essere parallelizzabili o richiedere un'ulteriore configurazione per essere perfettamente paralleli. Ad esempio, configurare gli output per la parallelizzazione. Non tutti i tipi di output supportano scritture parallele:

   Tipo di output	Supporto per la parallelizzazione
   Archiviazione BLOB di Azure, Archiviazione tabelle di Azure, Azure Data Lake Storage, bus di servizio di Azure, Funzioni di Azure	Automatico
   database SQL di Azure, Azure Synapse Analytics	Optional. Richiede la configurazione
   Hub eventi di Azure	Richiede PartitionKey che sia impostato in modo che corrisponda al campo PARTITION BY (in genere PartitionId). Fare in modo che il numero di partizioni di input e output corrisponda per evitare incroci.
   Power BI	Non parallelizzabile. Gli output vengono sempre uniti prima dell'invio al sink

3. Eseguire la query con 1 SU V2 (ovvero la capacità completa di un singolo nodo di calcolo) per misurare la velocità effettiva massima ottenibile. Se si usa GROUP BY, valutare quanti gruppi (cardinalità) il processo può gestire.

4. Verificare la presenza di limiti delle risorse di sistema. I sintomi seguenti indicano che il processo Analisi di flusso di Azure sta raggiungendo i limiti delle risorse:

   Sintomo	Causa possibile	Action
   La metrica di utilizzo % di SU supera l'80%	Utilizzo elevato della memoria. Vedere Comprendere e regolare le unità di streaming.	Aggiungere altre unità SU V2s.
   Il timestamp di output è in ritardo rispetto all'ora di sistema	A seconda della logica della query, il timestamp di output può avere un offset della logica dall'ora. Tuttavia, dovrebbero progredire approssimativamente allo stesso tasso. Se il timestamp di output sta diventando sempre più arretrato, è un indicatore che il sistema è sovraccarico. Può trattarsi di un risultato della limitazione del sink di output di downstream o dell'uso elevato del CPU. Analisi di flusso non fornisce attualmente la metrica di utilizzo della CPU, quindi può essere difficile distinguere i due elementi.	Se il problema è dovuto al throttling del sink, aumentare le partizioni di output (e le partizioni di input per mantenere il parallelismo) oppure aumentare le risorse del sink (ad esempio, le Unità richiesta per Azure Cosmos DB).
   La metrica dell'evento backlog per partizione continua ad aumentare (visibile nel diagramma dei processi)	Limitazione del sink di output o CPU elevata	Come sopra.

5. Estrapolare la capacità in modo lineare. Dopo aver determinato cosa può gestire 1 SU V2, aggiungi altre SU in modo proporzionale, supponendo che non vi sia alcuno sbilanciamento dei dati tra le partizioni.

Ridimensionare una query nonparallel

Se la query non è perfettamente parallela, seguire questa procedura:

1. Iniziare senza PARTITION BY per evitare complessità. Eseguire la query con 1 SU V2 per misurare la velocità effettiva massima. Controlla la presenza degli stessi sintomi di limite delle risorse descritti nella sezione precedente (utilizzo SU oltre l'80%, ritardo del timestamp di output, aumento del backlog).

2. Se raggiungi il throughput obiettivo, hai finito. Facoltativamente, esegui un test con 2/3 di SU V2 e poi con 1/3 di SU V2 per trovare il numero minimo di SU V2 per il tuo scenario.

3. Se non è possibile ottenere la velocità effettiva desiderata, suddividere la query in più passaggi. Alloca fino a 1 SU V2 per ogni fase. Ad esempio, una query a tre passaggi richiede 3 SU V2. Analisi di flusso di Azure inserisce ogni passaggio nel proprio nodo dedicato.

4. Se non hai ancora raggiunto il tuo obiettivo di throughput, aggiungi PARTITION BY ai passaggi più vicini all'input. Per le operazioni GROUP BY che non sono naturalmente partizionabili, usare il modello di aggregazione locale/globale: eseguire prima un GROUP BY partizionato, quindi un GROUP BY non partizionato. Ad esempio, per contare le auto che passano attraverso ogni casello ogni 3 minuti quando il volume supera quello che può gestire 1 SU V2:

   WITH Step1 AS (
   SELECT COUNT(*) AS Count, TollBoothId, PartitionId
   FROM Input1 Partition By PartitionId
   GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
   )
   SELECT SUM(Count) AS Count, TollBoothId
   FROM Step1
   GROUP BY TumblingWindow(minute, 3), TollBoothId
   

   Questa query conta le automobili per casello e per partizione nella fase Step1, quindi aggrega i conteggi per partizione nel passaggio finale.

   Dopo aver partizionato la query, assegna 1 SU V2 a ogni partizione di ogni fase, in modo che ogni partizione venga eseguita sul proprio nodo di elaborazione.

   Annotazioni

   Se la query non può essere partizionata, l'aggiunta di altre SU V2 in una query in più fasi potrebbe non migliorare la velocità di elaborazione. Per ottenere prestazioni, ridurre il volume nei passaggi iniziali usando il modello di aggregazione locale/globale illustrato nel passaggio 4.

Ridimensionare più query indipendenti in un singolo processo

Per gli scenari ISV (Independent Software Vendor) multi-tenant in cui si elaborano i dati da più tenant in un singolo processo di Analisi di flusso di Azure (con input e output separati per tenant), il carico di ogni sottoquery è in genere ridotto. Segui questi passaggi:

1. Non usare PARTITION BY nella query.

2. Se si usa Hub eventi di Azure, ridurre il numero di partizioni di input al valore minimo di 2.

3. Esegui la query con 1 SU V2. Aggiungi subquery finché il job non raggiunge i limiti di risorse. I sintomi sono gli stessi di quelli di una query completamente parallelizzabile: utilizzo delle SU superiore all'80%, ritardo nel timestamp di output o backlog in aumento.

4. Dopo aver raggiunto il limite di subquery, aggiungi nuove subquery a un processo distinto. Il numero di processi viene ridimensionato in modo lineare con il numero di query indipendenti (presupponendo che non si sia eseguita alcuna asimmetria di carico). È quindi possibile prevedere il numero di processi di unità di archiviazione V2 necessari ad eseguire come una funzione del numero di tenant che si desidera gestire.

5. Per le operazioni di join con i dati di riferimento, unire prima tutti gli input tra loro, quindi eseguire il join con i dati di riferimento e successivamente suddividere gli eventi. In caso contrario, ogni join di dati di riferimento mantiene una copia separata dei dati di riferimento in memoria, che può causare un utilizzo della memoria non necessario.

Ottenere assistenza

Per ulteriore assistenza, provare la pagina delle domande di Microsoft Q&A per Analisi di flusso di Azure.

Contenuti correlati

• Introduzione ad Analisi dei flussi di Azure
• Introduzione all'uso di Analisi dei flussi di Azure
• Informazioni di riferimento sul linguaggio di query di Analisi di flusso di Azure
• Informazioni di riferimento sulle API REST di gestione di Analisi di flusso di Azure