Uw Stream Analytics-taak schalen met Machine Learning Studio-functies (klassiek)
Tip
Het wordt ten zeerste aanbevolen om Azure Machine Learning UDF's te gebruiken in plaats van Machine Learning Studio (klassiek) UDF voor verbeterde prestaties en betrouwbaarheid.
Belangrijk
Ondersteuning voor Azure Machine Learning Studio (klassiek) eindigt op 31 augustus 2024. U wordt aangeraden op die datum over te stappen naar Azure Machine Learning .
Vanaf 1 december 2021 kunt u geen nieuwe Machine Learning Studio-resources (klassiek) maken (werkruimte- en webserviceplan). Tot en met 31 augustus 2024 kunt u de bestaande Experimenten en webservices van Machine Learning Studio (klassiek) blijven gebruiken. Zie voor meer informatie:
- Migreren naar Azure Machine Learning vanuit Machine Learning Studio (klassiek)
- Wat is Azure Machine Learning?
Machine Learning Studio -documentatie (klassiek) wordt buiten gebruik gesteld en wordt in de toekomst mogelijk niet bijgewerkt.
In dit artikel wordt beschreven hoe u Azure Stream Analytics-taken efficiënt kunt schalen die gebruikmaken van Machine Learning Studio-functies (klassiek). Zie het artikel Schaaltaken schalen voor informatie over het schalen van Stream Analytics-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 webserviceaanvragen van Studio (klassiek) verbeteren door meerdere rijen samen te batcheren in dezelfde webservice-API-aanroep. Deze groepering wordt een minibatch genoemd. Zie Machine Learning Studio (klassiek) Web Services voor meer informatie. Ondersteuning voor Studio (klassiek) in Stream Analytics.
Een Stream Analytics-taak configureren met Studio-functies (klassiek)
Er zijn twee parameters voor het configureren van de Studio-functie (klassiek) die wordt gebruikt door uw Stream Analytics-taak:
- Batchgrootte van de aanroepen van de Studio-functie (klassiek).
- Het aantal streaming-eenheden (SU's) dat is ingericht voor de Stream Analytics-taak.
Als u de juiste waarden voor SU's wilt bepalen, moet u bepalen of u de latentie van de Stream Analytics-taak of de doorvoer van elke SU wilt optimaliseren. SUs kunnen altijd worden toegevoegd aan een taak om de doorvoer van een goed gepartitioneerde Stream Analytics-query te verhogen. Extra RU's verhogen de kosten voor het uitvoeren van de taak.
Bepaal de latentietolerantie voor uw Stream Analytics-taak. Door de batchgrootte te vergroten, wordt de latentie van uw Studio-aanvragen (klassiek) en de latentie van de Stream Analytics-taak verhoogd.
Door de batchgrootte te vergroten, kan de Stream Analytics-taak meer gebeurtenissen verwerken met hetzelfde aantal Studio-webserviceaanvragen (klassiek). De toename van de latentie van de webservice studio (klassiek) is meestal sublijnig tot de toename van de batchgrootte.
Het is belangrijk om rekening te houden met de meest kostenefficiënte batchgrootte voor een Studio-webservice (klassiek) in een bepaalde situatie. De standaard batchgrootte 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 (SU's) instellen op basis van het aantal gebeurtenissen dat de functie per seconde moet verwerken. Zie Stream Analytics-schaaltaken voor meer informatie over streaming-eenheden.
Elke 6 RU'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. Dit tarief 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, die uit 12 SUs komen. In het volgende diagram ziet u de aanvragen van de Stream Analytics-taak naar het eindpunt van de Studio-webservice (klassiek): elke 6 SU's heeft maximaal 20 gelijktijdige verbindingen met 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-RU's:
U kunt ook de 'max gelijktijdige aanroepen' configureren in de Studio-webservice (klassiek). Het is raadzaam om deze parameter in te stellen op de maximumwaarde (momenteel 200).
Raadpleeg het artikel Schalen voor Machine Learning Studio -webservices (klassiek) voor meer informatie over deze instelling.
Voorbeeld : sentimentanalyse
Het volgende voorbeeld bevat een Stream Analytics-taak met de functie sentimentanalyse studio (klassiek), zoals beschreven in de zelfstudie over integratie van Stream Analytics Machine Learning Studio (klassiek).
De query is een eenvoudige volledig gepartitioneerde query, gevolgd door de gevoelsfunctie , 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, die sentimentanalyse van tweets met een snelheid van 10.000 tweets per seconde doet.
Met behulp van 1 SU kan deze Stream Analytics-taak het verkeer verwerken? De taak kan de invoer bijhouden met behulp van de standaard batchgrootte van 1000. De standaardlatentie van de sentimentanalyse studio (klassieke) webservice (met een standaard batchgrootte van 1000) maakt niet meer dan een seconde latentie.
De algehele of end-to-end-latentie van de Stream Analytics-taak duurt doorgaans een paar seconden. Bekijk deze Stream Analytics-taak gedetailleerder, met name de aanroepen van de Studio-functie (klassiek). Met een batchgrootte van 1000 duurt een doorvoer van 10.000 gebeurtenissen ongeveer 10 aanvragen voor de webservice. Zelfs met één SU zijn er voldoende gelijktijdige verbindingen voor dit invoerverkeer.
Als de snelheid van de invoer gebeurtenis met 100x toeneemt, moet de Stream Analytics-taak 1000.000 tweets per seconde verwerken. Er zijn twee opties om de toegenomen schaal te bereiken:
- Verhoog de batchgrootte.
- Partitioneer 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 RU's inrichten om meer gelijktijdige webserviceaanvragen van Studio (klassiek) te hebben. Dit grotere aantal RU's verhoogt de taakkosten.
Laten we eens kijken naar de schaalaanpassing met behulp van de volgende latentiemetingen voor elke batchgrootte:
| Latentie | Batchgrootte |
|---|---|
| 200 ms | Batches van 1000-gebeurtenissen of lager |
| 250 ms | Batches van 5000 gebeurtenissen |
| 300 ms | Batches van 10.000 gebeurtenissen |
| 500 ms | Batches van 25.000 gebeurtenissen |
- Gebruik de eerste optie (geen inrichting van meer RU's). 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 als gevolg van de sentimentfunctieaanvragen voor de Studio-webserviceaanvragen (klassiek) wordt dus verhoogd van 200 ms tot 500 ms. De batchgrootte kan echter niet oneindig worden verhoogd omdat voor de Studio-webservices (klassiek) de nettoladinggrootte van een aanvraag 4 MB of kleiner is, en er is een time-out voor webserviceaanvragen na 100 seconden bewerking vereist.
- Met behulp van de tweede optie blijft de batchgrootte 1000, met latentie van 200 ms webservice, elke 20 gelijktijdige verbindingen met de webservice 1000 * 20 * 5 gebeurtenissen = 100.000 per seconde verwerken. Voor het verwerken van 1.000.000 gebeurtenissen per seconde zou de taak dus 60 RU's nodig hebben. In vergelijking met de eerste optie zou de Stream Analytics-taak meer batchaanvragen voor webservices maken, wat op zijn beurt hogere kosten genereert.
Hieronder ziet u een tabel voor de doorvoer van de Stream Analytics-taak voor verschillende RU's en batchgrootten (in aantal gebeurtenissen per seconde).
| batchgrootte (ML-latentie) | 500 (200 ms) | 1.000 (200 ms) | 5.000 (250 ms) | 10.000 (300 ms) | 25.000 (500 ms) |
|---|---|---|---|---|---|
| 1 SU | 2500 | 5.000 | 20,000 | 30,000 | 50,000 |
| 3 RU's | 2500 | 5.000 | 20,000 | 30,000 | 50,000 |
| 6 RU's | 2500 | 5.000 | 20,000 | 30,000 | 50,000 |
| 12 RU's | 5.000 | 10,000 | 40.000 | 60.000 | 100.000 |
| 18 RU's | 7500 | 15.000 | 60.000 | 90,000 | 150.000 |
| 24 RU's | 10,000 | 20,000 | 80,000 | 120.000 | 200.000 |
| ... | ... | ... | ... | ... | ... |
| 60 RU's | 25,000 | 50,000 | 200.000 | 300,000 | 500,000 |
U moet nu al een goed beeld hebben van de werking van Studio (klassiek) in Stream Analytics. U begrijpt waarschijnlijk ook dat Stream Analytics-taken gegevens ophalen uit gegevensbronnen en elke 'pull', retourneert een batch gebeurtenissen voor de Stream Analytics-taak die moet worden verwerkt. Hoe heeft dit pull-model invloed op de aanvragen van de Studio-webservice (klassiek)?
Normaal gesproken is de batchgrootte die we hebben ingesteld voor Studio-functies (klassiek) niet exact deelbaar door het aantal gebeurtenissen dat wordt geretourneerd door elke Stream Analytics-taak 'pull'. Wanneer dit gebeurt, wordt de Studio-webservice (klassiek) aangeroepen met 'gedeeltelijke' batches. Bij het gebruik van gedeeltelijke batches voorkomt u extra overhead voor taaklatentie bij het samenvoegen van gebeurtenissen van pull naar pull.
Nieuwe functiegerelateerde bewakingsgegevens
In het gebied Monitor van een Stream Analytics-taak zijn drie aanvullende metrische gegevens voor functies toegevoegd. Dit zijn FUNCTIEAANVRAGEN, FUNCTIEGEBEURTENISSEN en MISLUKTE FUNCTIEAANVRAGEN, zoals wordt weergegeven in de onderstaande afbeelding.
De waarden zijn als volgt gedefinieerd:
FUNCTIEAANVRAGEN: het aantal functieaanvragen.
FUNCTIE-GEBEURTENISSEN: de numerieke gebeurtenissen in de functieaanvragen.
MISLUKTE FUNCTIEAANVRAGEN: het aantal mislukte functieaanvragen.
Belangrijke punten
Als u een Stream Analytics-taak wilt schalen met Studio-functies (klassiek), moet u rekening houden met de volgende factoren:
- De snelheid van de invoer gebeurtenis.
- De getolereerde latentie voor de actieve Stream Analytics-taak (en dus de batchgrootte van de webserviceaanvragen van Studio (klassiek).
- De ingerichte Stream Analytics-SU's en het aantal webserviceaanvragen van Studio (klassiek) (de extra kosten voor functies).
Er is een volledig gepartitioneerde Stream Analytics-query gebruikt als voorbeeld. Als er een complexere query nodig is, is de Microsoft Q&A-vragenpagina voor Azure Stream Analytics een uitstekende resource voor extra hulp van het Stream Analytics-team.
Volgende stappen
Zie voor meer informatie over Stream Analytics: