Uw taak Stream Analytics schalen met Machine Learning Studio-functies (klassiek)

In dit artikel wordt beschreven hoe u efficiënt taken Azure Stream Analytics die gebruikmaken van Machine Learning Studio-functies (klassiek). Zie het artikel Taken schalen Stream Analytics voor meer informatie over het schalen van taken in het algemeen.

Wat is een Studio-functie (klassiek) in Stream Analytics?

Een Machine Learning Studio-functie (klassiek) in Stream Analytics kan worden gebruikt als een reguliere functie-aanroep in de Stream Analytics querytaal. Achter de schermen zijn deze functie-aanroepen echter eigenlijk Studio-webserviceaanvragen (klassiek).

U kunt de doorvoer van Studio-webserviceaanvragen (klassiek) verbeteren door meerdere rijen samen te 'batchen' in dezelfde API-aanroep voor de webservice. Deze groepering wordt een mini-batch genoemd. Zie webservices van Machine Learning Studio (klassiek) voor meer informatie. Ondersteuning voor Studio (klassiek) in Stream Analytics.

Een Stream Analytics configureren met Studio-functies (klassiek)

Er zijn twee parameters voor het configureren van de Studio-functie (klassiek) die wordt gebruikt door Stream Analytics taak:

• Batchgrootte van de (klassieke) Studio-functie-aanroepen.
• Het aantal streaming-eenheden dat is ingericht voor de Stream Analytics taak.

Bepaal of u de latentie van de Stream Analytics taak of de doorvoer van elke SU wilt optimaliseren om de juiste waarden voor SU's te bepalen. SE's kunnen altijd worden toegevoegd aan een taak om de doorvoer van een goed gepart partitioneerde query Stream Analytics verhogen. Extra SUS's verhogen de kosten voor het uitvoeren van de taak.

Bepaal de latentietolerantie voor uw Stream Analytics taak. Als u de batchgrootte verhoogt, neemt de latentie van uw Studio-aanvragen (klassiek) en de latentie van de Stream Analytics toe.

Door de batchgrootte te vergroten, Stream Analytics taak meer gebeurtenissen verwerken met hetzelfde aantal Studio-webserviceaanvragen (klassiek). De toename van de latentie van de Studio-webservice (klassiek) is meestal sublijn door de toename van de batchgrootte.

Het is belangrijk om in een bepaalde situatie rekening te houden met de meest rendabele batchgrootte voor een Studio-webservice (klassiek). De standaardbatchgrootte voor webserviceaanvragen is 1000. U kunt deze standaardgrootte wijzigen met behulp van de Stream Analytics REST API of de PowerShell-client voor Stream Analytics.

Zodra u een batchgrootte hebt gekozen, kunt u het aantal streaming-eenheden (SUS's) instellen op basis van het aantal gebeurtenissen dat de functie per seconde moet verwerken. Zie voor meer informatie over streaming-eenheden Stream Analytics taken te schalen.

Elke 6 SE's krijgen 20 gelijktijdige verbindingen met de Studio-webservice (klassiek). 1 SU-taak en 3 SU-taken krijgen echter 20 gelijktijdige verbindingen.

Als uw toepassing 200.000 gebeurtenissen per seconde genereert en de batchgrootte 1000 is, is de resulterende latentie van de webservice 200 ms. Deze snelheid betekent dat elke verbinding elke seconde vijf aanvragen kan indienen bij de Studio-webservice (klassiek). Met 20 verbindingen kan de Stream Analytics-taak 20.000 gebeurtenissen verwerken in 200 ms en 100.000 gebeurtenissen in een seconde.

Voor het verwerken van 200.000 gebeurtenissen per seconde heeft de Stream Analytics-taak 40 gelijktijdige verbindingen nodig, wat uit 12 SE's komt. In het volgende diagram ziet u de aanvragen van de Stream Analytics-taak naar het Studio-webservice-eindpunt (klassiek). Elke 6 SE's heeft maximaal 20 gelijktijdige verbindingen met de Studio-webservice (klassiek).

Over het algemeen is B _ voor batchgrootte _L_ voor de latentie van de webservice bij batchgrootte B in milliseconden, de doorvoer van een Stream Analytics-taak met _ N SUS:

U kunt ook het maximum aantal gelijktijdige aanroepen configureren in de Studio-webservice (klassiek). Het is raadzaam om deze parameter in te stellen op de maximumwaarde (momenteel 200).

Lees het artikel Schalen voor webservices van Machine Learning Studio (klassiek)voor meer informatie over deze instelling.

Voorbeeld: Sentimentanalyse

Het volgende voorbeeld bevat een Stream Analytics taak met de sentimentanalyse Studio-functie (klassiek), zoals beschreven in de zelfstudie over integratie Stream Analytics Machine Learning Studio (klassiek).

De query is een eenvoudige, volledig gepart partitioneerde query, gevolgd door de sentimentfunctie, zoals wordt weergegeven in het volgende voorbeeld:

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

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

Laten we eens kijken naar de configuratie die nodig is om een Stream Analytics-taak te maken, waarmee sentimentanalyse van tweets wordt uitgevoerd met een snelheid van 10.000 tweets per seconde.

Met behulp van 1 SU kan Stream Analytics taak het verkeer verwerken? De taak kan de invoer bij houden met behulp van de standaardbatchgrootte van 1000. De standaardlatentie van de sentimentanalyse studio(klassieke) webservice (met een standaard batchgrootte van 1000) maakt niet meer dan een seconde latentie.

De Stream Analytics of end-to-end-latentie van de taak is doorgaans een paar seconden. Bekijk deze taak gedetailleerder Stream Analytics, met name de functie-aanroepen van Studio (klassiek). Met een batchgrootte van 1000 duurt een doorvoer van 10.000 gebeurtenissen ongeveer 10 aanvragen naar de webservice. Zelfs met één SU zijn er voldoende gelijktijdige verbindingen om dit invoerverkeer mogelijk te maken.

Als het aantal invoergebeurtenissen met 100x toeneemt, moet de Stream Analytics-taak 1.000.000 tweets per seconde verwerken. Er zijn twee opties om de grotere schaal te bereiken:

1. Vergroot de batchgrootte.
2. Partitioneren van de invoerstroom om de gebeurtenissen parallel te verwerken.

Met de eerste optie neemt de latentie van de taak toe.

Met de tweede optie moet u meer SE's inrichten om meer gelijktijdige Studio-webserviceaanvragen (klassiek) te hebben. Dit grotere aantal SE's verhoogt de taakkosten.

Laten we eens kijken naar het schalen met behulp van de volgende latentiemetingen voor elke batchgrootte:

1. Met behulp van de eerste optie (niet meer SUS inrichten). De batchgrootte kan worden verhoogd tot 25.000. Door de batchgrootte op deze manier te vergroten, kan de taak 1.000.000 gebeurtenissen verwerken met 20 gelijktijdige verbindingen met de Studio-webservice (klassiek) (met een latentie van 500 ms per aanroep). De extra latentie van de Stream Analytics-taak vanwege de sentimentfunctieaanvragen voor de Studio-webserviceaanvragen (klassiek) zou dus worden verhoogd van 200 ms naar 500 ms. Batchgrootte kan echter niet oneindig worden verhoogd, omdat voor de Studio-webservices (klassiek) de payloadgrootte van een aanvraag 4 MB of kleiner is en er een time-out voor webserviceaanvragen is na 100 seconden bewerking.
2. Met de tweede optie blijft de batchgrootte op 1000, met een latentie van 200 ms voor de webservice, en kunnen elke 20 gelijktijdige verbindingen met de webservice 1000 * 20 * 5 gebeurtenissen verwerken = 100.000 per seconde. Als u dus 1.000.000 gebeurtenissen per seconde wilt verwerken, heeft de taak 60 SUS's nodig. Vergeleken met de eerste optie zou Stream Analytics meer webservicebatchaanvragen doen, waardoor de kosten hoger worden.

Hieronder vindt u een tabel voor de doorvoer van de Stream Analytics taak voor verschillende SUS's en batchgrootten (in het aantal gebeurtenissen per seconde).

U hebt nu al een goed begrip van de manier waarop Studio (klassiek) werkt in Stream Analytics werken. U begrijpt waarschijnlijk ook dat Stream Analytics taken gegevens uit gegevensbronnen 'pullen' en elke 'pull' een batch gebeurtenissen retourneert die door de Stream Analytics worden verwerkt. Wat is de invloed van dit pull-model op de webserviceaanvragen van Studio (klassiek) ?

Normaal gesproken is de batchgrootte die we hebben ingesteld voor Studio-functies (klassiek) niet precies deelbaar door het aantal gebeurtenissen dat wordt geretourneerd door elke Stream Analytics taak 'pull'. Als dit het geval is, wordt de Studio-webservice (klassiek) aangeroepen met 'gedeeltelijke' batches. Als u gedeeltelijke batches gebruikt, wordt voorkomen dat er extra overhead voor de latentie van de taak nodig is bij het samensmen van gebeurtenissen van pull naar pull.

Nieuwe metrische bewakingsgegevens met betrekking tot functies

In het gebied Bewaken van een Stream Analytics taak zijn drie extra metrische gegevens met betrekking tot functies toegevoegd. Dit zijn FUNCTIEAANVRAGEN, FUNCTIEGEBEURTENISSEN EN MISLUKTE FUNCTIEAANVRAGEN, zoals wordt weergegeven in de onderstaande afbeelding.

De worden als volgt gedefinieerd:

FUNCTIEAANVRAGEN: het aantal functieaanvragen.

FUNCTIEGEBEURTENISSEN: het aantal gebeurtenissen in de functieaanvragen.

MISLUKTE FUNCTIEAANVRAGEN: het aantal mislukte functieaanvragen.

Belangrijke punten

Als u een Stream Analytics wilt schalen met Studio-functies (klassiek), moet u rekening houden met de volgende factoren:

1. De invoergebeurtenissnelheid.
2. De getolereerde latentie voor de Stream Analytics taak (en dus de batchgrootte van de Studio-webserviceaanvragen (klassiek).
3. De inrichtende Stream Analytics-SE's en het aantal Studio-webserviceaanvragen (klassiek) (de extra functiegerelateerde kosten).

Een volledig gepart partitioneerde Stream Analytics query is als voorbeeld gebruikt. Als u een complexere query nodig hebt, is de Microsoft Q&A-vragenpagina voor Azure Stream Analytics een uitstekende resource voor extra hulp van het Stream Analytics team.

Volgende stappen

Voor meer informatie over Stream Analytics, zie:

• Aan de slag met Azure Stream Analytics
• Azure Stream Analytics-taken schalen
• Naslaggids voor Azure Stream Analytics Query
• REST API-naslaggids voor Azure Stream Analytics Management