Använda ompartitionering för att optimera bearbetningen med Azure Stream Analytics

Den här artikeln visar hur du använder ompartitionering för att skala din Azure Stream Analytics-fråga för scenarier som inte kan parallelliseras helt.

Du kanske inte kan använda parallellisering om:

  • Du styr inte partitionsnyckeln för indataströmmen.
  • Källan "sprutar" indata över flera partitioner som senare måste sammanfogas.

Ompartitionering eller omfördelning krävs när du bearbetar data på en dataström som inte är fragmenterad enligt ett naturligt indataschema, till exempel PartitionId för Event Hubs. När du partitioneras om kan varje fragment bearbetas separat, vilket gör att du kan skala ut din strömningspipeline linjärt.

Så här partitionerar du om

Du kan partitionera om dina indata på två sätt:

  1. Använd ett separat Stream Analytics-jobb som gör ompartitioneringen
  2. Använd ett enda jobb men gör ompartitioneringen först före din anpassade analyslogik

Skapa ett separat Stream Analytics-jobb för att partitionera om indata

Du kan skapa ett jobb som läser indata och skrivningar till en händelsehubbutdata med hjälp av en partitionsnyckel. Den här händelsehubben kan sedan fungera som indata för ett annat Stream Analytics-jobb där du implementerar din analyslogik. När du konfigurerar händelsehubbens utdata i jobbet måste du ange partitionsnyckeln som Stream Analytics ska partitionera om dina data med.

-- 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

Ompartitionsindata i ett enda Stream Analytics-jobb

Du kan också introducera ett steg i din fråga som först partitioneras om indata, som sedan kan användas av andra steg i frågan. Om du till exempel vill partitionera om indata baserat på DeviceId är frågan:

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)  

I följande exempelfråga kopplas två strömmar med ompartitionerade data. När du ansluter två strömmar med ompartitionerade data måste strömmarna ha samma partitionsnyckel och antal. Resultatet är en ström som har samma partitionsschema.

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

Utdataschemat ska matcha strömschemanyckeln och antalet så att varje underström kan tömmas oberoende av varandra. Dataströmmen kan också sammanfogas och partitioneras igen av ett annat schema före tömning, men du bör undvika den metoden eftersom den lägger till den allmänna svarstiden för bearbetningen och ökar resursanvändningen.

Strömningsenheter för ompartitioner

Experimentera och observera resursanvändningen för ditt jobb för att fastställa det exakta antalet partitioner som du behöver. Antalet strömningsenheter (SU) måste justeras enligt de fysiska resurser som behövs för varje partition. I allmänhet behövs sex SU:er för varje partition. Om det inte finns tillräckligt med resurser som tilldelats jobbet tillämpar systemet endast ompartitionen om den gynnar jobbet.

Ompartitioner för SQL-utdata

När ditt jobb använder SQL-databas för utdata använder du explicit ompartitionering för att matcha det optimala partitionsantalet för att maximera dataflödet. Eftersom SQL fungerar bäst med åtta skrivare kan ompartitionering av flödet till åtta före tömning, eller någonstans längre uppströms, gynna jobbprestanda.

Om det finns fler än åtta indatapartitioner kanske det inte är lämpligt att ärva indatapartitioneringsschemat. Överväg att använda INTO i din fråga för att uttryckligen ange antalet utdataskrivare.

Följande exempel läser från indata, oavsett om den partitioneras naturligt, och ompartitionerar strömmen tiofaldigt enligt DeviceID-dimensionen och tömmer data till utdata.

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

Mer information finns i Azure Stream Analytics-utdata till Azure SQL Database.

Nästa steg