Condividi tramite

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

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.
  • Il tuo input di origine distribuisce i dati tra più partizioni che devono essere successivamente unite.

Il ripartizionamento o il rimescolamento è necessario quando si elaborano dati in un flusso non partizionato secondo uno schema di input naturale, come ad esempio PartitionId per Event Hubs. Quando si ripartiziona, ogni frammento può essere elaborato in modo indipendente, il che consente di espandere linearmente 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 compito unico, ma eseguire la suddivisione prima della logica analitica personalizzata

Creare un processo di Stream Analytics separato per ripartizionare l'input

È 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 all'interno del processo di lavoro, è necessario specificare la chiave di partizione in base alla quale Stream Analytics 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

Ripartizione dell'input all'interno di un singolo processo Stream Analytics

È 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 desidera ripartizionare l'input basandosi su 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 affinché ogni sottoflusso possa essere svuotato autonomamente. 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 SU 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 utilizza il database SQL per l'output, utilizza il ripartizionamento esplicito per corrispondere al numero ottimale di partizioni al fine di massimizzare 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 scrittori di output.

L'esempio seguente legge dall'input, indipendentemente dal fatto che sia partizionato naturalmente, e ripartiziona il flusso dieci volte in base alla dimensione del DeviceID e sblocca 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

  • Last updated on