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

  • Artikel

Den här artikeln visar hur du justerar en Stream Analytics-fråga för att öka dataflödet för Streaming Analytics-jobb. Du kan använda följande guide för att skala ditt jobb för att hantera högre belastning och dra nytta av fler systemresurser (till exempel mer bandbredd, mer CPU-resurser, mer minne).

Läs följande artiklar som en förutsättning:

Fall 1 – Frågan är till sin natur helt parallelliserbar mellan indatapartitioner

Om frågan i sig är helt parallelliserbar mellan indatapartitioner kan du följa följande steg:

  • Skapa frågan så att den är pinsamt parallell med 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. Power BI-utdata kan till exempel inte parallelliseras. Utdata sammanfogas alltid innan de skickas till utdatamottagaren. Blobbar, tabeller, Azure Data Lake Storage, Service Bus och Azure Function parallelliseras automatiskt. SQL- och Azure Synapse Analytics-utdata har ett alternativ för parallellisering. En händelsehubb måste ha konfigurationen PartitionKey inställd för att matcha fältet PARTITION BY (vanligtvis PartitionId). För Event Hubs bör du också vara extra uppmärksam på att matcha antalet partitioner för alla indata och alla utdata för att undvika korsningar mellan partitioner.
  • Kör din fråga med 1 strömningsenhet (SU) V2 (som är den fullständiga kapaciteten för en enda beräkningsnod) för att mäta maximalt uppnåeligt dataflöde, och om du använder GROUP BY mäter du hur många grupper (kardinalitet) jobbet kan hantera. Allmänna symtom på att jobbet når systemets resursgränser är följande.
    • Måttet för streamenhet (SU) % är över 80 %. Det indikerar att minnesanvändningen är hög. De faktorer som bidrar till ökningen av det här måttet beskrivs Förstå och justera Stream Analytics-strömningsenheter.
    • Tidsstämpeln för utdata ligger efter när det gäller klocktid 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å nedströms begränsning av utdatamottagare eller hög CPU-användning. Vi tillhandahåller inte cpu-användningsmått just nu, så det kan vara svårt att skilja mellan de två.
      • Om problemet beror på begränsning av mottagare måste du öka antalet utdatapartitioner (och även indatapartitioner för att hålla jobbet helt parallelliserbart) eller öka mängden resurser i mottagaren (till exempel antalet enheter för begäran för Cosmos DB).
    • I jobbdiagrammet finns ett händelsemått per partition för varje indata. Om händelsemåttet för kvarvarande uppgifter fortsätter att öka är det också en indikator på att systemresursen är begränsad (antingen på grund av begränsning av utdatamottagare eller hög CPU).
  • När du har fastställt gränserna för vad ett SU V2-jobb kan nå kan du extrapolera linjärt bearbetningskapaciteten för jobbet när du lägger till fler SU:er, förutsatt att du inte har några sneda data som gör vissa partitioner "heta".

Kommentar

Välj rätt antal strömningsenheter: Eftersom Stream Analytics skapar en bearbetningsnod för varje 1 SU V2 som läggs till är det bäst att göra antalet noder till en divisor för antalet indatapartitioner, så att partitionerna kan fördelas jämnt över noderna. Du har till exempel mätt att ditt 1 SU V2-jobb kan uppnå 4 MB/s bearbetningshastighet och antalet indatapartitioner är 4. Du kan välja att köra jobbet med 2 SU V2 för att uppnå ungefär 8 MB/s bearbetningshastighet, eller 4 SU V2 för att uppnå 16 MB/s. Du kan sedan bestämma när du ska öka SU-talet för jobbet till vilket värde, som en funktion av din indatafrekvens.

Fall 2 – Om frågan inte är pinsamt parallell.

Om frågan inte är pinsamt parallell kan du följa de här stegen.

  • Börja med en fråga utan PARTITION BY först för att undvika partitioneringskomplexitet och kör frågan med 1 SU V2 för att mäta maximal belastning som i fall 1.
  • Om du kan uppnå din förväntade belastning under dataflödet är du klar. Du kan också välja att mäta samma jobb som körs med bråknoder på 2/3 SU V2 och 1/3 SU V2 för att ta reda på det minsta antalet strömningsenheter som fungerar för ditt scenario.
  • Om du inte kan uppnå önskat dataflöde kan du försöka dela upp frågan i flera steg om den inte redan har flera steg och allokera upp till en SU V2 för varje steg i frågan. Om du till exempel har tre steg kan du allokera tre SU V2:er i alternativet "Skala".
  • För att köra ett sådant jobb placerar Stream Analytics varje steg på sin egen nod med en dedikerad SU V2-resurs.
  • Om du fortfarande inte har uppnått belastningsmålet kan du försöka använda PARTITION GENOM att börja från steg närmare indata. För GROUP BY-operatorn som inte är naturligt partitionerbar kan du använda det lokala/globala aggregeringsmönstret för att utföra en partitionerad GROUP BY följt av en icke-partitionerad GROUP BY. Om du till exempel vill räkna hur många bilar som går igenom varje avgiftsbelagd monter var 3:e minut och datavolymen är större än vad som kan hanteras av en SU V2.

Fråga:

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

I frågan räknar du bilar per avgiftsbelagt bås per partition och lägger sedan till antalet från alla partitioner tillsammans.

När partitionen har partitionerats allokerar du en SU V2 för varje partition i steget så att varje partition kan placeras på sin egen bearbetningsnod.

Kommentar

Om frågan inte kan partitioneras kanske det inte alltid förbättrar dataflödet genom att lägga till ytterligare SU i en fråga med flera steg. Ett sätt att få prestanda är att minska volymen på de första stegen med hjälp av ett lokalt/globalt aggregeringsmönster, enligt beskrivningen i steg 5.

Fall 3 – Du kör många oberoende frågor i ett jobb.

För vissa ISV-användningsfall, där det är mer kostnadseffektivt att bearbeta data från flera klienter i ett enda jobb, med hjälp av separata indata och utdata för varje klientorganisation, körs ganska många (till exempel 20) oberoende frågor i ett enda jobb. Antagandet är att varje sådan underfrågas belastning är relativt liten.

I det här fallet kan du följa de här stegen.

  • I det här fallet ska du inte använda PARTITION BY i frågan
  • Minska antalet indatapartitioner till det lägsta möjliga värdet på 2 om du använder Event Hubs.
  • Kör frågan med en SU V2. Med förväntad belastning för varje underfråga lägger du till så många sådana underfrågor som möjligt tills jobbet når systemets resursgränser. Se fall 1 för symtomen när det händer.
  • När du når den uppmätta underfrågan börjar du lägga till underfrågan i ett nytt jobb. Antalet jobb som ska köras som en funktion av antalet oberoende frågor bör vara ganska linjärt, förutsatt att du inte har någon belastningssnedställning. 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.
  • När du använder referensdataanslutning med sådana frågor kan du koppla ihop indata innan du ansluter till samma referensdata. Dela sedan upp händelserna om det behövs. Annars behåller varje referensdatakoppling en kopia av referensdata i minnet, vilket sannolikt spränger minnesanvändningen i onödan.

Kommentar

Hur många klienter ska placeras i varje jobb? Det här frågemönstret har ofta ett stort antal underfrågor och resulterar i mycket stor och komplex topologi. Kontrollanten för jobbet kanske inte kan hantera en så stor topologi. Som tumregel bör du hålla dig under 40 klienter för ett 1/3 SU V2-jobb och 60 klientorganisationer för 2/3- och 1 SU V2-jobb. När du överskrider kapaciteten för kontrollanten startar inte jobbet.

Få hjälp

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

Nästa steg