Skala ett Azure Stream Analytics-jobb för att öka dataflödet

Den här artikeln beskriver hur du justerar en Azure Stream Analytics fråga för att öka dataflödet. Använd dessa skalningsmönster för att hantera högre belastning med hjälp av mer bandbredd, processor och minnesresurser.

Azure Stream Analytics mäter beräkningskapaciteten i streaming units (SUs). Varje SU V2 representerar den fullständiga kapaciteten för en enda beräkningsnod. En pinsamt parallell fråga är en fråga där varje indatapartition kan bearbetas oberoende av varandra, utan att några data delas mellan partitioner.

Förutsättningar

Läs följande artiklar innan du börjar:

Skala en fullständigt parallelliserbar fråga

Om frågan är pinsamt parallell mellan indatapartitioner följer du dessa steg:

Skapa din fråga för att använda nyckelordet PARTITION BY . Mer information finns i Använda frågeparallellisering i Azure Stream Analytics.

Beroende på utdatatyper som används i din fråga kan vissa utdata antingen inte vara parallella eller behöva ytterligare konfiguration för att vara pinsamt parallella. Konfigurera till exempel dina utdata för parallellisering. Alla utdatatyper stöder inte parallella skrivningar:

Utdatatyp	Stöd för parallellisering
Azure Blob Storage, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions	Automatiskt
Azure SQL Database, Azure Synapse Analytics	Valfritt. Kräver konfiguration
Azure Event Hubs	Kräver `PartitionKey` inställd på att matcha fältet PARTITION BY (vanligtvis `PartitionId`). Matcha antalet in- och utdatapartitioner för att undvika korsningar.
Power BI	Inte parallelliserbar. Utdata sammanfogas alltid innan de skickas till mottagaren

Kör frågan med 1 SU V2 (som är den fullständiga kapaciteten för en enda beräkningsnod) för att mäta maximalt uppnåeligt dataflöde. Om du använder GROUP BY mäter du hur många grupper (kardinalitet) jobbet kan hantera.

Sök efter systemresursgränser. Följande symptom tyder på att ditt Azure Stream Analytics jobb når resursgränserna:

Symptom	Sannolik orsak	Action
Mätvärdet för SU-utnyttjandegrad överstiger 80 %	Hög minnesanvändning. Se Förstå och justera strömningsenheter.	Lägg till fler SU V2s.
Tidsstämpeln för utdata hamnar bakom klocktiden på väggen	Beroende på din frågelogik kan tidsstämpeln för utdata ha en logikförskjutning från klocktiden på väggen. De bör dock utvecklas i ungefär samma takt. Om tidsstämpeln för utdata hamnar längre och längre efter är det en indikator på att systemet överarbetar. Det kan bero på begränsning av mottagare nedströms eller hög CPU-användning. Stream Analytics tillhandahåller inte cpu-användningsmått just nu, så det kan vara svårt att särskilja de två.	Om problemet beror på begränsning i målsänkan ökar du antalet utdatapartitioner (och indatapartitioner för att bibehålla parallellitet), eller så ökar du resurserna för målsänkan (till exempel Request Units för Azure Cosmos DB).
Händelsemått för kvarvarande uppgifter per partition fortsätter att öka (visas i jobbdiagram)	Strypning av utdatamål eller hög CPU	Samma som ovan.

Extrapolera kapaciteten linjärt. När du har fastställt vad 1 SU V2 kan hantera lägger du till fler SUs proportionellt, förutsatt att inga data skevar över partitioner.

Anmärkning

Välj rätt antal SU V2: Azure Stream Analytics skapar en bearbetningsnod för varje SU V2. Gör antalet SU V2:er till en divisor för antalet indatapartitioner så att partitionerna fördelas jämnt.

Exempel: Ett 1 SU V2-jobb bearbetar 4 MB/s med 4 indatapartitioner. Använd 2 SU V2s för ~8 MB/s eller 4 SU V2 för ~16 MB/s. Välj SU V2-antalet baserat på din målindatafrekvens.

Skala en icke-parallell fråga

Om frågan inte är pinsamt parallell följer du dessa steg:

Starta utan PARTITION BY för att undvika komplexitet. Kör frågan med 1 SU V2 för att mäta maximalt dataflöde. Kontrollera om det finns samma resursgränsssymptom som beskrivs i föregående avsnitt (SU-användning över 80%, tidsstämpelfördröjning för utdata, ökad kvarvarande loggning).
Om du uppnår din målgenomströmning, är du klar. Valfritt kan du testa med 2/3 SU V2 och 1/3 SU V2 för att hitta det minsta antalet SU V2 för ditt scenario.
Om du inte kan uppnå önskat dataflöde kan du dela upp frågan i flera steg. Allokera upp till 1 SU V2 för varje steg. En trestegsfråga behöver till exempel 3 SU V2s. Azure Stream Analytics placerar varje steg på sin egen dedikerade nod.
Om du fortfarande inte har nått dataflödesmålet lägger du till PARTITION BY för att gå närmare indata. För GROUP BY-åtgärder som inte är naturligt partitionerbara använder du det lokala/globala aggregeringsmönstret: utför först en partitionerad GROUP BY och sedan en icke-partitionerad GROUP BY. Till exempel för att räkna bilar som passerar genom varje avgiftsbelagd monter var 3:e minut när volymen överskrider vad 1 SU V2 kan hantera:
```
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
```
Den här frågan räknar bilar per tullstation och partition i steg 1 och aggregerar sedan antalen från partitionerna i slutsteget.

När du har partitionerat frågan allokerar du 1 SU V2 för varje partition i varje steg så att varje partition körs på sin egen bearbetningsnod.

Anmärkning

Om frågan inte kan partitioneras kanske det inte förbättrar dataflödet genom att lägga till fler SU V2:er i en flerstegsfråga. För att få prestanda kan du minska volymen i de första stegen med hjälp av det lokala/globala aggregeringsmönstret som visas i steg 4.

Skala upp flera oberoende förfrågningar inom ett och samma jobb

För scenarier med oberoende programvaruleverantör (ISV) för flera klienter där du bearbetar data från flera klienter i ett enda Azure Stream Analytics jobb (med separata indata och utdata per klientorganisation) är varje underfrågas belastning vanligtvis liten. Följ dessa steg:

Använd inte PARTITION BY i frågan.
Om du använder Azure Event Hubs minskar du antalet indatapartitioner till minimivärdet 2.
Kör frågan med 1 SU V2. Lägg till underfrågor tills jobbet når resursgränserna. Symptomen är desamma som för en fullständigt parallelliserbar fråga: SU-användning över 80%, tidsstämpelfördröjning för utdata eller ökad kvarvarande uppgifter.
När du har nått underfrågans gräns lägger du till nya underfrågor i ett separat jobb. Antalet jobb skalas linjärt med antalet oberoende frågor (förutsatt att det inte finns någon belastningssnedvridning). Du kan sedan prognostisera hur många SU V2-jobb du behöver köra som en funktion av det antal klienter som du vill hantera.
För referensdataanslutningar kan du koppla alla indata innan du ansluter till referensdata och sedan dela händelserna efteråt. Annars behåller varje referensdatakoppling en separat kopia av referensdata i minnet, vilket kan orsaka onödig minnesanvändning.

Anmärkning

Maximalt antal klienter per jobb: Håll dig under 40 klienter för ett 1/3 SU V2-jobb och 60 klienter för 2/3- och 1 SU V2-jobb. Ett stort antal underfrågor skapar komplexa topologier som jobbstyrenheten kanske inte hanterar, vilket hindrar jobbet från att starta.

Få hjälp

Om du vill ha mer hjälp kan du prova microsofts Q&A-frågesida för Azure Stream Analytics.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-06-03