Använd Query parallellisering i Azure Stream Analytics

Den här artikeln visar hur du kan dra nytta av parallellisering i Azure Stream Analytics. Du lär dig hur du skalar Stream Analytics jobb genom att konfigurera inpartitioner och justera analys frågans definition. Som ett krav kan du vilja vara bekant med begreppet enhet för strömning som beskrivs i förstå och justera strömnings enheter.

Vilka delar ingår i ett Stream Analytics jobb?

En Stream Analytics jobb definition innehåller minst en strömmande indata, en fråga och utdata. Indata är där jobbet läser data strömmen från. Frågan används för att transformera data inmatnings strömmen och utdata är där jobbet skickar jobb resultatet till.

Partitioner i indata och utdata

Med partitionering kan du dela upp data i del mängder baserat på en partitionsnyckel. Om InInformationen (till exempel Event Hubs) är partitionerad av en nyckel, rekommenderar vi starkt att du anger den här partitionsnyckel när du lägger till ininformation till ditt Stream Analytics-jobb. Skalning av ett Stream Analytics jobb drar nytta av partitioner i indata och utdata. Ett Stream Analytics jobb kan använda och skriva olika partitioner parallellt, vilket ökar data flödet.

Indata

Alla Azure Stream Analytics-ingångar kan dra nytta av partitionering:

• EventHub (du måste ange partitionsnyckel explicit med PARTITION med nyckelord om du använder kompatibilitetsnivå 1,1 eller lägre)
• IoT Hub (du måste ange partitionsnyckel explicit med PARTITION med hjälp av nyckelord om du använder kompatibilitetsnivå 1,1 eller lägre)
• Blob Storage

Utdata

När du arbetar med Stream Analytics kan du dra nytta av partitionering i utdata:

• Azure Data Lake Storage
• Azure Functions
• Azure-tabell
• Blob Storage (kan ange partitionsnyckel explicit)
• Cosmos DB (du måste uttryckligen ange partitionsnyckel)
• Event Hubs (du måste uttryckligen ange partitionsnyckel)
• IoT Hub (du måste uttryckligen ange partitionsnyckel)
• Service Bus
• SQL-och Azure Synapse-analys med valfri partitionering: Mer information finns på sidan utdata till Azure SQL Database.

Power BI stöder inte partitionering. Du kan dock fortfarande partitionera indatamängden enligt beskrivningen i det här avsnittet

Mer information om partitioner finns i följande artiklar:

• Översikt över Event Hubs-funktioner
• Datapartitionering

Köras parallella jobb

Ett köras parallellt jobb är det mest skalbara scenariot i Azure Stream Analytics. Den ansluter en partition av indata till en instans av frågan till en partition av utdata. Den här parallellen har följande krav:

1. Om din fråge logik är beroende av samma nyckel som bearbetas av samma instans, måste du se till att händelserna går till samma partition som du har angett. För Event Hubs eller IoT Hub innebär det att händelse data måste ha PartitionKey -värdet inställt. Du kan också använda partitionerade avsändare. För Blob Storage innebär detta att händelserna skickas till samma partition-mapp. Ett exempel är en instans instans som samlar in data per userID där indata-händelsehubben partitioneras med hjälp av userID som partitionsnyckel. Men om din fråge logik inte kräver samma nyckel som ska bearbetas av samma instans, kan du ignorera det här kravet. Ett exempel på den här logiken är en enkel Select-Project-filter-fråga.

2. Nästa steg är att göra din fråga partitionerad. För jobb med kompatibilitetsnivå 1,2 eller högre (rekommenderas) kan anpassade kolumner anges som partitionsnyckel i inkompatibla inställningar och jobbet kommer att paralellized automatiskt. Jobb med kompatibilitetsnivå 1,0 eller 1,1, kräver att du använder partition av PartitionID i alla steg i frågan. Flera steg är tillåtna, men alla måste vara partitionerade med samma nyckel.

3. De flesta utdata som stöds i Stream Analytics kan dra nytta av partitionering. Om du använder en utdatatyp som inte stöder partitionering kan du inte köras parallellt. För Event Hub-utdata ser du till att kolumnen partitionsnyckel har angetts till samma partitionsnyckel som används i frågan. Mer information finns i avsnittet utdata .

4. Antalet indata-partitioner måste vara lika med antalet utgående partitioner. Blob Storage-utdata kan stödja partitioner och ärver partitionerings schema för överordnad fråga. När du anger en partitionsnyckel för Blob Storage, partitioneras data per partition, vilket innebär att resultatet fortfarande är helt parallellt. Här är exempel på partitionsalternativ som tillåter ett helt parallellt jobb:

   • 8 indata-partitioner för händelsehubben och 8 Event Hub-utdataparametrar
   • 8 indata-partitioner för händelsehubben och Blob Storage-utdata
   • 8 indata-partitioner för händelsehubben och Blob Storage-utdata partitionerade med ett anpassat fält med godtycklig kardinalitet
   • 8 Blob Storage-datapartitioner och Blob Storage-utdata
   • 8 indata-partitioner för blob-lagring och 8 Event Hub-utdataparametrar

I följande avsnitt beskrivs några exempel scenarier som är köras parallella.

Exempelfråga

• Inmatade: Event Hub med 8 partitioner
• Utdata: Event Hub med 8 partitioner ("partitionsnyckel" måste anges för att använda "PartitionId")

Fråga:

    --Using compatibility level 1.2 or above
    SELECT TollBoothId
    FROM Input1
    WHERE TollBoothId > 100
    
    --Using compatibility level 1.0 or 1.1
    SELECT TollBoothId
    FROM Input1 PARTITION BY PartitionId
    WHERE TollBoothId > 100

Den här frågan är ett enkelt filter. Därför behöver vi inte bekymra dig om att partitionera de inloggade indatamängdarna som skickas till Event Hub. Observera att jobb med kompatibilitetsnivå före 1,2 måste innehålla partition by PartitionID -sats, så att den uppfyller kravet #2 från tidigare. För utdata måste vi konfigurera Event Hub-utdata i jobbet så att partitionsnyckel anges till PartitionID. En sista kontroll är att se till att antalet indata-partitioner är lika med antalet utgående partitioner.

Fråga med en grupperings nyckel

• Inmatade: Event Hub med 8 partitioner
• Utdata: Blob Storage

Fråga:

    --Using compatibility level 1.2 or above
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    
    --Using compatibility level 1.0 or 1.1
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Den här frågan har en grupperings nyckel. Därför måste de händelser som grupper ATS tillsammans skickas till samma Event Hub-partition. Eftersom vi i det här exemplet grupperar av TollBoothID bör vi se till att TollBoothID används som partitionsnyckel när händelserna skickas till Event Hub. I ASA kan vi använda partition av PartitionID för att ärva från det här partitionsnamnet och aktivera fullständig parallellisering. Eftersom utdata är Blob Storage behöver vi inte bekymra dig om att konfigurera ett nyckel värde för partitionen, enligt kravet #4.

Exempel på scenarier som inte är köras parallella

I föregående avsnitt visade vi vissa köras-parallella scenarier. I det här avsnittet diskuterar vi scenarier som inte uppfyller alla krav som ska köras parallellt.

Antal felaktiga partitioner

• Inmatade: Event Hub med 8 partitioner
• Utdata: Event Hub med 32 partitioner

Om antalet partitioner för indata inte matchar antalet utdata, är topologin inte köras parallell oberoende av frågan. Vi kan dock fortfarande hämta vissa nivåer eller parallellisering.

Fråga med icke-partitionerade utdata

• Inmatade: Event Hub med 8 partitioner
• Utdata: Power BI

Power BI-utdata stöder för närvarande inte partitionering. Därför är det här scenariot inte köras parallellt.

Fråga i flera steg med en annan PARTITION utifrån värden

• Inmatade: Event Hub med 8 partitioner
• Utdata: Event Hub med 8 partitioner
• Kompatibilitetsnivå: 1,0 eller 1,1

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 Partition By TollBoothId
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Som du kan se använder det andra steget TollBoothId som partitionerings nyckel. Det här steget är inte detsamma som det första steget, och därför kräver vi att vi gör ett blandat.

Fråga i flera steg med en annan PARTITION utifrån värden

• Inmatade: Event Hub med 8 partitioner
• Utdata: Event Hub med 8 partitioner ("partitionsnyckel" måste anges för att använda "TollBoothId")
• Kompatibilitetsnivå – 1,2 eller senare

Fråga:

    WITH Step1 AS (
    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    )

    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId

Kompatibilitetsnivån 1,2 eller senare aktiverar parallell frågekörningen som standard. Till exempel är fråga från föregående avsnitt partitionerat så länge som "TollBoothId"-kolumnen har angetts som indatamängds nyckel. PARTITION BY PartitionId-sats krävs inte.

Beräkna det maximala antalet enheter för strömning av ett jobb

Det totala antalet enheter för strömning som kan användas av ett Stream Analytics jobb beror på antalet steg i frågan som definierats för jobbet och antalet partitioner för varje steg.

Steg i en fråga

En fråga kan innehålla ett eller flera steg. Varje steg är en under fråga som definierats av nyckelordet with . Frågan som ligger utanför with -nyckelordet (endast en fråga) räknas också som ett steg, till exempel Select -uttrycket i följande fråga:

Fråga:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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 har två steg.

Partitionera ett steg

Att partitionera ett steg kräver följande villkor:

• Indatakällan måste vara partitionerad.
• Select -uttrycket för frågan måste läsa från en partitionerad indatakälla.
• Frågan i steget måste ha partitionen med nyckelord.

När en fråga är partitionerad, bearbetas inmatnings händelser och sammanställs i separata partitionsuppsättningar och utgående händelser skapas för varje grupp. Om du vill ha en kombinerad agg regering måste du skapa ett andra icke-partitionerat steg att aggregera.

Beräkna max enheter för strömning för ett jobb

Alla icke-partitionerade steg kan skala upp till sex strömnings enheter (SUs) för ett Stream Analytics jobb. Förutom detta kan du lägga till 6 SUs för varje partition i ett partitionerat steg. Du kan se några exempel i tabellen nedan.

Exempel på skalning

Följande fråga beräknar antalet bilar i ett 3-minuters fönster som går via en avgifts station som har tre tollbooths. Den här frågan kan skalas upp till sex SUs.

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

Om du vill använda mer SUs för frågan måste både indata strömmen och frågan vara partitionerade. Eftersom Datastream-partitionen har angetts till 3 kan följande ändrade fråga skalas upp till 18 SUs:

    SELECT COUNT(*) AS Count, TollBoothId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId

När en fråga har partitionerats bearbetas inloggade händelser och sammanställs i separata partitionsuppsättningar. Utmatnings händelser skapas också för varje grupp. Partitionering kan orsaka oväntade resultat när fältet Gruppera efter inte är partitionsnyckel i indata-dataströmmen. Fältet TollBoothId i föregående fråga är till exempel inte partitionsnyckel för INPUT1. Resultatet är att data från TollBooth #1 kan spridas i flera partitioner.

Var och en av INPUT1 -partitionerna bearbetas separat genom att Stream Analytics. Därför skapas flera poster av antalet bilar för samma Tollbooth i samma rullande-fönster. Om du inte kan ändra den här nyckeln kan du lösa det här problemet genom att lägga till ett icke-partitionerings-steg för att aggregera värden mellan partitioner, som i följande exempel:

    WITH Step1 AS (
        SELECT COUNT(*) AS Count, TollBoothId
        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 kan skalas till 24 SUs.

Uppnå högre data flöden i stor skala

Ett köras parallellt jobb är nödvändigt men inte tillräckligt för att hantera ett högre data flöde i stor skala. Varje lagrings system och dess motsvarande Stream Analytics-utdata har variationer i hur du uppnår bästa möjliga Skriv data flöde. Precis som med alla storskaliga scenarier finns det vissa utmaningar som kan lösas med hjälp av rätt konfigurationer. I det här avsnittet beskrivs konfigurationer för några vanliga utdata och innehåller exempel på hur man kan ta del av förbruknings frekvensen på 1 KB, 5 K och 10 000 händelser per sekund.

I följande observationer används ett Stream Analytics jobb med en tillstånds lös (direkt lagrings fråga), en grundläggande JavaScript-UDF som skriver till Event Hub, Azure SQL DB eller Cosmos DB.

Händelsehubb

Event Hub -lösningen skalas linjärt i termer av strömnings enheter (SU) och data flöde, vilket gör det till det mest effektiva och bästa sättet att analysera och strömma data från Stream Analytics. Jobb kan skalas upp till 192 SU, som ungefär översätts till att bearbeta upp till 200 MB/s, eller 19 000 000 000 000 händelser per dag.

Azure SQL

Azure SQL har stöd för skrivning parallellt, som kallas Ärv partitionering, men är inte aktiverat som standard. Att aktivera ärva partitionering, tillsammans med en helt parallell fråga, är dock inte tillräckligt för att uppnå högre data flöden. SQL Write-dataflödena är beroende av databas konfigurationen och tabell schemat. I artikeln SQL-utdata finns mer information om de parametrar som kan maximera Skriv data flödet. Som anges i Azure Stream Analytics utdata till Azure SQL Database artikel skalar den här lösningen inte linjärt som en helt parallell pipeline utöver 8 partitioner och kan behöva partitionera om innan SQL-utdata (se i). Premium SKU: er krävs för att hantera höga IO-priser tillsammans med kostnader för att logga säkerhets kopieringar på några minuter.

Cosmos DB

Cosmos DB utdata från Stream Analytics har uppdaterats för att använda inbyggd integrering under kompatibilitetsnivå 1,2. Kompatibilitetsnivån 1,2 möjliggör betydligt högre genomflöde och minskar RU-förbrukningen jämfört med 1,1, vilket är standard kompatibilitetsnivån för nya jobb. Lösningen använder CosmosDB-behållare partitionerade på/deviceId och resten av lösningen har kon figurer ATS identiskt.

Alla strömningar i Azure-exempel använder en händelsehubben som indata som matas genom belastnings simulerings test klienter. Varje indata-händelse är ett 1 KB JSON-dokument, som översätter de konfigurerade inmatnings priserna till data flödes nivåerna (1 MB/s, 5 MB/s och 10 MB/s) enkelt. Händelser simulerar en IoT-enhet som skickar följande JSON-data (i ett förkortat format) för upp till 1 kB-enheter:

{
    "eventId": "b81d241f-5187-40b0-ab2a-940faf9757c0",
    "complexData": {
        "moreData0": 51.3068118685458,
        "moreData22": 45.34076957651598
    },
    "value": 49.02278128887753,
    "deviceId": "contoso://device-id-1554",
    "type": "CO2",
    "createdAt": "2019-05-16T17:16:40.000003Z"
}

Identifiera Flask halsar

Använd fönstret mått i ditt Azure Stream Analytics jobb för att identifiera Flask halsar i din pipeline. Granska indata/utdata-händelser för data flöde och "fördröjning av vattenstämpel" eller eftersläpande händelser för att se om jobbet hålls i takt med indata. För Event Hub-mått söker du efter begränsade begär Anden och justerar tröskel enheterna enligt detta. För Cosmos DB Mät värden granskar du Max förbrukade ru/s per nyckel intervall under genomflödet för att se till att dina partitionerings nyckel intervall är enhetligt förbrukade. Övervaka logg-i/o och CPU för Azure SQL DB.

Få hjälp

Om du behöver ytterligare hjälp kan du prova vår Microsoft Q&en fråge sida för Azure Stream Analytics.

Nästa steg

• Introduktion till Azure Stream Analytics
• Komma igång med Azure Stream Analytics
• Referens för Azure Stream Analytics-frågespråket
• Referens för Azure Stream Analytics Management REST-API:et