Skala ditt Stream Analytics jobb med Machine Learning Studio-funktioner (klassisk)

Den här artikeln beskriver hur du effektivt kan skala Azure Stream Analytics jobb som använder Machine Learning Studio-funktioner (klassisk). Information om hur du skalar Stream Analytics jobb i allmänhet finns i artikeln Skala jobb.

Vad är en Studio-funktion (klassisk) i Stream Analytics?

En Machine Learning Studio-funktion (klassisk) Stream Analytics kan användas som ett vanligt funktionsanrop i det Stream Analytics frågespråket. I bakgrunden är dock dessa funktionsanrop faktiskt Studio-webbtjänstbegäranden (klassisk).

Du kan förbättra dataflödet för Studio-webbtjänstbegäranden genom att "batcha" flera rader tillsammans i samma webbtjänst-API-anrop. Den här gruppningen kallas för en minibatch. Mer information finns i Machine Learning Studio Web Services (klassisk). Stöd för Studio (klassisk) i Stream Analytics.

Konfigurera ett Stream Analytics jobb med Studio-funktioner (klassisk)

Det finns två parametrar för att konfigurera studiofunktionen (klassisk) som används av Stream Analytics jobbet:

• Batchstorleken för funktionsanropen i Studio (klassisk).
• Antalet enheter för strömning (SUS) som etablerats för Stream Analytics jobbet.

För att fastställa lämpliga värden för SU:er bestämmer du om du vill optimera svarstiden för Stream Analytics-jobbet eller dataflödet för varje SU. SUs kan alltid läggas till i ett jobb för att öka dataflödet för en välpartitionerad Stream Analytics fråga. Ytterligare SUs ökar kostnaden för att köra jobbet.

Fastställ svarstidstoleransen för ditt Stream Analytics jobb. Om du ökar batchstorleken ökar svarstiden för dina Studio-begäranden (klassisk) och svarstiden för Stream Analytics jobbet.

Genom att öka batchstorleken kan Stream Analytics att bearbeta fler händelser med samma antal Studio-webbtjänstbegäranden (klassisk). Ökningen av svarstiden för studiowebbtjänsten (klassisk) är vanligtvis underrad till ökningen av batchstorleken.

Det är viktigt att överväga den mest kostnadseffektiva batchstorleken för en Studio-webbtjänst (klassisk) i en viss situation. Standardstorleken för batchar för webbtjänstbegäranden är 1 000. Du kan ändra standardstorleken med hjälp av Stream Analytics REST API eller PowerShell-klienten för Stream Analytics.

När du har valt batchstorlek kan du ange antalet enheter för strömning (SUS) baserat på antalet händelser som funktionen behöver bearbeta per sekund. Mer information om strömningsenheter finns i Stream Analytics skalningsjobb.

Var 6:e SUs får 20 samtidiga anslutningar till Studio-webbtjänsten (klassisk). 1 SU-jobb och 3 SU-jobb får dock 20 samtidiga anslutningar.

Om programmet genererar 200 000 händelser per sekund och batchstorleken är 1 000 blir webbtjänstens svarstid 200 ms. Den här frekvensen innebär att varje anslutning kan göra fem begäranden till Studio-webbtjänsten (klassisk) varje sekund. Med 20 anslutningar kan Stream Analytics bearbeta 20 000 händelser på 200 ms och 100 000 händelser på en sekund.

För att bearbeta 200 000 händelser per sekund behöver Stream Analytics 40 samtidiga anslutningar, vilket blir 12 SUS:er. Följande diagram illustrerar begäranden från Stream Analytics-jobbet till webbtjänstslutpunkten Studio (klassisk) – var 6:e SUs har 20 samtidiga anslutningar till Studio-webbtjänsten (klassisk) som max.

I allmänhet är B _ för batchstorlek, _L_ för webbtjänstens svarstid vid batchstorlek B i millisekunder, dataflödet för ett Stream Analytics-jobb med _ N SUS:er:

Du kan också konfigurera "maximalt antal samtidiga anrop" i Studio-webbtjänsten (klassisk). Vi rekommenderar att du ställer in den här parametern på det högsta värdet (200 för närvarande).

Mer information om den här inställningen finns i skalningsartikeln för Machine Learning Studio-webbtjänster (klassisk).

Exempel – Attitydanalys

Följande exempel innehåller ett Stream Analytics jobb med funktionen sentiment analysis Studio (klassisk), enligt beskrivningen i självstudien för Stream Analytics Machine Learning Studio-integrering (klassisk).

Frågan är en enkel fullständigt partitionerad fråga följt av sentimentfunktionen, som du ser i följande exempel:

    WITH subquery AS (
        SELECT text, sentiment(text) as result from input
    )

    Select text, result.[Score]
    Into output
    From subquery

Nu ska vi undersöka konfigurationen som krävs för att skapa ett Stream Analytics-jobb, som gör attitydanalys av tweets med en frekvens på 10 000 tweets per sekund.

Kan det här Stream Analytics hantera trafiken med hjälp av 1 SU? Jobbet kan hålla koll på indata med standardbatchstorleken 1 000. Standardsvarstid för sentiment analysis Studio-webbtjänsten (klassisk) (med en standardbatchstorlek på 1 000) skapar högst en sekunds svarstid.

Den Stream Analytics för jobbets övergripande svarstid eller svarstid från slutet till slut skulle vanligtvis vara några sekunder. Ta en mer detaljerad titt på den här Stream Analytics jobb, särskilt Studio-funktionsanropen (klassisk). Med en batchstorlek på 1 000 tar ett dataflöde på 10 000 händelser cirka 10 begäranden till webbtjänsten. Även med en SU finns det tillräckligt med samtidiga anslutningar för att hantera den här indatatrafiken.

Om indatahändelsefrekvensen ökar med 100 x måste Stream Analytics bearbeta 1 000 000 tweets per sekund. Det finns två alternativ för att åstadkomma den ökade skalan:

1. Öka batchstorleken.
2. Partitionera indataströmmen för att bearbeta händelserna parallellt.

Med det första alternativet ökar jobbets svarstid.

Med det andra alternativet måste du etablera fler SUS:er för att ha fler samtidiga Studio-webbtjänstbegäranden (klassisk). Det här större antalet SUS:er ökar jobbkostnaden.

Nu ska vi titta på skalningen med hjälp av följande svarstidsmått för varje batchstorlek:

1. Använda det första alternativet (inte att etablera fler SUS:er). Batchstorleken kan ökas till 25 000. Genom att öka batchstorleken på det här sättet kan jobbet bearbeta 1 000 000 händelser med 20 samtidiga anslutningar till Studio-webbtjänsten (klassisk) (med en svarstid på 500 ms per anrop). Den ytterligare svarstiden för Stream Analytics-jobbet på grund av sentimentfunktionsbegäranden mot Studio-webbtjänstbegäranden (klassisk) skulle därför ökas från 200 ms till 500 ms. Batchstorleken kan dock inte ökas obegränsat eftersom Studio-webbtjänsterna (klassiska) kräver att nyttolastens storlek är 4 MB eller mindre, och webbtjänstbegäranden tar för lång tid efter 100 sekunders drift.
2. Med det andra alternativet lämnas batchstorleken på 1 000, med en svarstid på 200 ms webbtjänst, var 20:e samtidiga anslutning till webbtjänsten kan bearbeta 1 000 * 20 * 5 händelser = 100 000 per sekund. För att bearbeta 1 000 000 händelser per sekund skulle jobbet alltså behöva 60 SUs. Jämfört med det första alternativet skulle Stream Analytics jobb göra fler web service batch-begäranden, vilket i sin tur genererar en ökad kostnad.

Nedan visas en tabell för dataflödet för Stream Analytics jobb för olika SUS:er och batchstorlekar (i antal händelser per sekund).

Vid det här laget bör du redan ha en god förståelse för hur Studio -funktioner (klassisk) Stream Analytics fungerar. Du förstår förmodligen också att Stream Analytics jobb "hämtar" data från datakällor och att varje "pull" returnerar en batch med händelser för Stream Analytics jobb att bearbeta. Hur påverkar den här pull-modellen Studio-webbtjänstbegäranden?

Normalt är batchstorleken som vi anger för Studio-funktioner (klassisk) inte exakt delbar med antalet händelser som returneras av varje Stream Analytics jobb "pull". När detta inträffar anropas Studio-webbtjänsten (klassisk) med "partiella" batchar. Om du använder partiella batchar undviks ytterligare arbetsfördröjningskostnader vid sammanfällning av händelser från pull till pull.

Nya funktionsrelaterade övervakningsmått

I området Övervaka i ett Stream Analytics jobb har ytterligare tre funktionsrelaterade mått lagts till. De är FUNKTIONSBEGÄRANDEN, FUNKTIONSHÄNDELSER och MISSLYCKADE FUNKTIONSBEGÄRANDEN, enligt bilden nedan.

definieras på följande sätt:

FUNKTIONSBEGÄRANDEN: Antalet funktionsbegäranden.

FUNCTION EVENTS: Antalet händelser i funktionsbegäranden.

FAILED FUNCTION REQUESTS (MISSLYCKADE FUNKTIONSBEGÄRANDEN): Antalet misslyckade funktionsbegäranden.

Viktiga inhämtningar

Om du vill Stream Analytics ett jobb med Studio-funktioner (klassisk) bör du tänka på följande faktorer:

1. Händelsefrekvensen för indata.
2. Den tolererade svarstiden för det Stream Analytics jobb (och därmed batchstorleken för Studio-webbtjänstbegäranden (klassisk).
3. Den etablerade Stream Analytics-SUS:er och antalet studiowebbtjänstbegäranden (de ytterligare funktionsrelaterade kostnaderna).

En fullständigt partitionerad Stream Analytics-fråga användes som exempel. Om en mer komplex fråga behövs är Microsoft Q&En frågesida för Azure Stream Analytics en bra resurs för att få ytterligare hjälp från Stream Analytics-teamet.

Nästa steg

Mer information om Stream Analytics finns i:

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