Condividi tramite

Usare il ripartizionamento per ottimizzare l'elaborazione con Analisi di flusso di Azure

  • Articolo

Questo articolo illustra come usare il ripartizionamento per ridimensionare la query di Analisi di flusso di Azure per scenari che non possono essere completamente parallelizzati.

Potrebbe non essere possibile usare la parallelizzazione se:

  • Non è possibile controllare la chiave di partizione per il flusso di input.
  • L'input di origine "spruzza" tra più partizioni che devono essere unite in un secondo momento.

Il ripartizionamento o il rimshuffing è necessario quando si elaborano dati in un flusso non partizionato in base a uno schema di input naturale, ad esempio PartitionId per Hub eventi. Quando si ripartiziona, ogni partizione può essere elaborata in modo indipendente, che consente di aumentare in modo lineare la pipeline di streaming.

Come ripartizionare

È possibile ripartizionare l'input in due modi:

  1. Usare un processo di Analisi di flusso separato che esegue il ripartizionamento
  2. Usare un singolo processo, ma eseguire la suddivisione prima della logica di analisi personalizzata

Creazione di un processo di Analisi di flusso separato per l'input di ripartizione

È possibile creare un processo che legge l'input e scrive in un output dell'hub eventi usando una chiave di partizione. Questo hub eventi può quindi fungere da input per un altro processo di Analisi di flusso in cui si implementa la logica di analisi. Quando si configura l'output dell'hub eventi nel processo, è necessario specificare la chiave di partizione in base alla quale Analisi di flusso ripartizionerà i dati.

-- For compat level 1.2 or higher
SELECT * 
INTO output
FROM input

--For compat level 1.1 or lower
SELECT *
INTO output
FROM input PARTITION BY PartitionId

Input di ripartizione all'interno di un singolo processo di Analisi di flusso

È anche possibile introdurre un passaggio nella query che prima ripartiziona l'input, che può quindi essere usato da altri passaggi della query. Ad esempio, se si vuole ripartizionare l'input in base a DeviceId, la query sarà:

WITH RepartitionedInput AS 
( 
    SELECT * 
    FROM input PARTITION BY DeviceID
)

SELECT DeviceID, AVG(Reading) as AvgNormalReading  
INTO output
FROM RepartitionedInput  
GROUP BY DeviceId, TumblingWindow(minute, 1)

La query di esempio seguente unisce due flussi di dati ripartizionati. Quando si uniscono due flussi di dati ripartizionati, i flussi devono avere la stessa chiave di partizione e lo stesso numero di partizioni. Il risultato è un flusso con lo stesso schema di partizione.

WITH step1 AS 
(
    SELECT * FROM input1 
    PARTITION BY DeviceID
),
step2 AS 
(
    SELECT * FROM input2 
    PARTITION BY DeviceID
)

SELECT * INTO output 
FROM step1 PARTITION BY DeviceID 
UNION step2 PARTITION BY DeviceID

Lo schema di output deve corrispondere alla chiave di partizione del flusso e al numero di partizioni in modo che ogni sottostream possa essere scaricato in modo indipendente. Il flusso può anche essere unito e ripartizionato di nuovo da uno schema diverso prima dello scaricamento, ma è consigliabile evitare tale metodo perché aggiunge alla latenza generale dell'elaborazione e aumenta l'utilizzo delle risorse.

Unità di streaming per le ripartizioni

Sperimentare e osservare l'utilizzo delle risorse del processo per determinare il numero esatto di partizioni necessarie. Il numero di unità di streaming (SU) deve essere regolato in base alle risorse fisiche necessarie per ogni partizione. In generale, sono necessarie sei UR per ogni partizione. Se al processo sono assegnate risorse insufficienti, il sistema applicherà la ripartizione solo se beneficia del processo.

Ripartizioni per l'output SQL

Quando il processo usa il database SQL per l'output, usare il ripartizionamento esplicito per trovare la corrispondenza con il numero di partizioni ottimale per ottimizzare la velocità effettiva. Poiché SQL funziona meglio con otto writer, la ripartizione del flusso a otto prima dello scaricamento o in un punto più a monte può migliorare le prestazioni del processo.

Quando sono presenti più di otto partizioni di input, l'ereditarietà dello schema di partizionamento di input potrebbe non essere una scelta appropriata. Prendere in considerazione l'uso di INTO nella query per specificare in modo esplicito il numero di writer di output.

L'esempio seguente legge dall'input, indipendentemente dal fatto che sia partizionato naturalmente e ripartiziona il flusso in base alla dimensione DeviceID e scarica i dati nell'output.

SELECT * INTO [output] 
FROM [input] 
PARTITION BY DeviceID INTO 10

Per altre informazioni, consultare Output di Analisi di flusso di Azure in Database SQL di Azure.

Passaggi successivi