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

  • Articolo

Questo articolo illustra come ottimizzare una query per aumentare la velocità effettiva per i processi di Analisi di flusso. È possibile usare la seguente guida per ridimensionare il processo per gestire carichi più elevati e sfruttare i vantaggi di più risorse di sistema (ad esempio maggiore larghezza di banda, più risorse della CPU, una maggiore memoria). Come prerequisito, è necessario leggere gli articoli seguenti:

Caso 1: la query è intrinsecamente completamente eseguibile in parallelo tra le partizioni di input

Se la query è intrinsecamente completamente eseguibile in parallelo tra le partizioni di input, è possibile seguire la procedura seguente:

  1. Creare la query in modo che sia perfettamente parallela usando la parola chiave PARTITION BY. Visualizzare altri dettagli nella sezione dei processi perfettamente paralleli in questa pagina.
  2. A seconda dei tipi di output usati nella query, alcuni output potrebbero non essere eseguibili in parallelo, o richiederebbero un'altra configurazione perfettamente parallela. Ad esempio, l'output di Power BI non è parallelizzabile. Gli output vengono sempre uniti prima di essere inviati al sink di output. I BLOB, le tabelle, l'ADLS, il Bus di servizio e la funzione di Azure vengono parallelizzati automaticamente. Gli output di SQL e Azure Synapse Analytics hanno un'opzione per la parallelizzazione. Hub eventi deve avere la configurazione PartitionKey impostata in modo che corrisponda al campo PARTITION BY (in genere PartitionId). Per Hub eventi, prestare particolare attenzione anche al numero di partizioni per tutti gli input e tutti gli output per evitare il cross-over tra le partizioni.
  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 e, se si usa GROUP BY, misurare il numero di gruppi (cardinalità) che il processo può gestire. Di seguito sono elencati i sintomi generali dei limiti della risorsa del sistema nel raggiungere il processo.
    • La metrica di utilizzo % SU è superiore all'80%. Indica che l'uso della memoria è elevato. I fattori che contribuiscono all'aumento della metrica sono descritti qui.
    • Il timestamp di output è in ritardo rispetto all'ora. A seconda della logica della query, il timestamp di output potrebbe avere un offset della logica dall'ora. Tuttavia, dovrebbero procedere approssimativamente allo stesso ritmo. Se il timestamp di output è sempre più in ritardo, è un indicatore del fatto che il sistema è in overworking. Può trattarsi di un risultato della limitazione del sink di output di downstream o dell'uso elevato del CPU. Non si fornisce una metrica di utilizzo del CPU in questa fase, pertanto può essere difficile distinguere i due.
      • Se il problema è dovuto alla limitazione del sink, potrebbe essere necessario aumentare il numero di partizioni di output (e anche le partizioni di input per mantenere il processo completamente parallelizzabile) o aumentare la quantità di risorse del sink ,ad esempio il numero di unità richiesta per Cosmos DB.
    • Nel diagramma del processo è presente una metrica dell'evento backlog per partizione per ogni input. Se la metrica dell'evento di backlog continua ad aumentare, è anche un indicatore del fatto che la risorsa del sistema è vincolata (o a causa della limitazione del sink di output o a causa del CPU elevato).
  4. Dopo aver determinato i limiti del raggiungimento di un processo 1 SU V2, è possibile estrapolare in modo lineare la capacità di elaborazione del processo quando si aggiungono altre unità di streaming, presupponendo che non si disponga di alcuna asimmetria dei dati che rende una determinata partizione "ad accesso frequente".

Nota

Scegliere il numero corretto di unità di streaming: poiché Analisi di flusso crea un nodo di elaborazione per ogni 1 UNITÀ di streaming V2 aggiunte, è consigliabile rendere il numero di nodi un divisore del numero di partizioni di input, in modo che le partizioni possano essere distribuite uniformemente tra i nodi. Ad esempio, il processo 1 SU V2 può raggiungere una velocità di elaborazione di 4 MB/s e il numero di partizioni di input è 4. È possibile scegliere di eseguire il processo con 2 unità di streaming V2 per ottenere una velocità di elaborazione di circa 8 MB/s o 4 UNITÀ di streaming V2 per ottenere 16 MB/s. È possibile decidere quando aumentare il numero di unità di ricerca per il processo a qualsiasi valore, come una funzione del tasso di input.

Caso 2: se la query non è imbarazzante.

Se la query non è imbarazzantemente parallela, è possibile seguire questa procedura.

  1. Iniziare con una query senza PARTITION BY per evitare prima di tutto la complessità del partizionamento ed eseguire la query con 1 SU V2 per misurare il carico massimo come nel caso 1.
  2. Se è possibile ottenere il carico previsto in termini di velocità effettiva, è possibile farlo. In alternativa, è possibile scegliere di misurare lo stesso processo in esecuzione con nodi frazionari a 2/3 SU V2 e 1/3 SU V2 per individuare il numero minimo di unità di streaming che funzionano per lo scenario.
  3. Se non è possibile ottenere la velocità effettiva desiderata, provare a suddividere la query in più passaggi, se possibile, se non sono già presenti più passaggi e allocare fino a 1 SU V2 per ogni passaggio della query. Ad esempio, se sono presenti 3 passaggi, allocare 3 unità di streaming V2 nell'opzione "Scala".
  4. Quando si esegue un processo di questo tipo, Analisi di flusso inserisce ogni passaggio nel proprio nodo con una risorsa dedicata su 1 SU V2.
  5. Se ancora non è stata raggiunta la destinazione del carico, è possibile tentare di usare PARTITION BY a partire dai passaggi più vicini all'input. Per l'operatore GROUP BY che non può essere partizionabile naturalmente, è possibile usare il modello di aggregazione globale o locale per eseguire un GROUP BY partizionato seguito da un GROUP BY non partizionato. Ad esempio, se si vuole contare il numero di automobili che passano attraverso ogni casello ogni 3 minuti e il volume dei dati supera quello che può essere gestito da 1 SU V2.

Query:

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

Nella query precedente si contano le automobili per ogni casello per partizione e quindi si aggiunge il conteggio da tutte le partizioni.

Una volta partizionato, per ogni partizione del passaggio, allocare 1 SU V2 in modo che ogni partizione possa essere inserita nel proprio nodo di elaborazione.

Nota

Se la query non può essere partizionata, l'aggiunta di altre unità di risorse in una query a più passaggi non sempre servirà a migliorare la velocità effettiva. Un modo per ottenere prestazioni è quello di ridurre il volume sui passaggi iniziali usando il modello di aggregazione locale o globale, come descritto in precedenza nel passaggio 5.

Caso 3: si eseguono molte query indipendenti in un processo.

Per determinati casi d'uso ISV, in cui è più conveniente elaborare dati da più tenant in un singolo processo, usando input e output separati per ogni tenant, si finisce per eseguire delle query (ad esempio 20) indipendenti in un singolo processo. Il presupposto è che ogni carico di tale sottoquery è relativamente piccolo. In questo caso, è possibile seguire la procedura seguente.

  1. In questo caso, non usare PARTITION BY nella query
  2. Ridurre il numero di partizioni di input al valore più basso possibile di 2 se si usano Hub eventi.
  3. Eseguire la query con 1 SU V2. Con il carico previsto per ogni sottoquery, aggiungere più sottoquery possibili, fino a quando il processo non supera i limiti delle risorse di sistema. Fare riferimento al Caso 1 per i sintomi riportati in questo caso.
  4. Dopo aver raggiunto il limite di sottoquery misurato in precedenza, iniziare ad aggiungere la sottoquery a un nuovo processo. Il numero di processi per l'esecuzione come una funzione del numero di query indipendente dovrebbe essere piuttosto lineare, presupponendo che non siano presenti asimmetrie del carico. È quindi possibile prevedere il numero di 1 processi SU V2 che è necessario eseguire come funzione del numero di tenant che si vuole gestire.
  5. Quando si usano i join dei dati di riferimento con tali query, unire gli input insieme, prima di creare un join con gli stessi dati di riferimento. Quindi, se necessario, suddividere gli eventi. In caso contrario, ogni join dei dati di riferimento mantiene una copia dei dati di riferimento nella memoria, probabilmente ingrandendo inutilmente l'uso della memoria.

Nota

Quanti tenant inserire in ogni processo? Questo modello di query spesso ha un numero elevato di sottoquery e ciò comporta una topologia molto grande e complessa. Il controller del processo potrebbe non essere in grado di gestire una topologia di così grandi dimensioni. Come regola generale, rimanere sotto 40 tenant per un processo su 1/3 SU V2 e 60 tenant per processi da 2/3 e 1 SU V2. Quando si supera la capacità del controller, il processo non verrà avviato correttamente.

Come ottenere assistenza

Per maggiore supporto, provare la Pagina delle domande di Domande e risposte Microsoft per Analisi di flusso di Azure.

Passaggi successivi