Een Azure Stream Analytics taak schalen om de door voer te verhogen

In dit artikel wordt beschreven hoe u een Stream Analytics query kunt afstemmen om de door Voer voor streaming Analytics-taken te verhogen. U kunt de volgende hand leiding gebruiken om uw taak te schalen om een hogere belasting te verwerken en te profiteren van meer systeem bronnen (zoals meer band breedte, meer CPU-bronnen, meer geheugen). Als vereiste moet u mogelijk de volgende artikelen lezen:

• Streaming-eenheden begrijpen en aanpassen
• Kan worden opgestart-taken maken

Voor beeld 1: uw query is inherent volledig kan worden opgestart over de verschillende invoer partities

Als uw query volledig kan worden opgestart over alle invoer partities beschikt, kunt u de volgende stappen volgen:

1. Ontwerp uw query zodanig dat deze ongebruik maakt van een partitie per sleutel woord. Zie de sectie verlegen parallelle taken op deze pagina voormeer informatie.
2. Afhankelijk van de uitvoer typen die in uw query worden gebruikt, is het mogelijk dat een bepaalde uitvoer niet kan worden opgestart is of dat de verdere configuratie nog te maken heeft. Bijvoorbeeld, de Power bi-uitvoer is niet kan worden opgestart. Uitvoer wordt altijd samengevoegd voordat deze naar de uitvoer sink wordt verzonden. Blobs, Tables, ADLS, Service Bus en Azure function worden automatisch geparallelleerd. SQL en Azure Synapse Analytics-uitvoer hebben een optie voor parallel Lise ring. Voor de Event hub moet de configuratie van PartitionKey zijn ingesteld op overeenkomen met het veld Partition by (meestal PartitionId). Voor Event hub moet u ook extra aandacht best Eden aan het aantal partities voor alle invoer en alle uitvoer om te voor komen dat er kruisen tussen partities worden uitgevoerd.
3. Voer uw query uit met 6 su (dit is de volledige capaciteit van een knoop punt met één computer) om de maximale Haal bare door voer te meten. Als u Group by gebruikt, meet u hoeveel groepen (kardinaliteit) de taak kan verwerken. Algemene symptomen van de systeem resource limieten voor taak beheer zijn het volgende.
   • De metrische gegevens over het gebruik van% zijn meer dan 80%. Dit geeft aan dat het geheugen gebruik hoog is. De factoren die bijdragen aan de toename van deze metriek worden hierbeschreven.
   • Uitvoer tempel ligt achter met betrekking tot de klok tijd van de wand. Afhankelijk van uw query logica, kan het uitvoer tijds tempel een logische offset hebben van de klok tijd van de wand. Ze moeten echter op ongeveer dezelfde snelheid worden uitgevoerd. Als het tijds tempel van de uitvoer verder en verder ligt, is het een indicatie dat het systeem overwerkt. Dit kan een resultaat zijn van de stroomafwaartse beperking van het uitvoer filter of een hoog CPU-gebruik. We bieden op dit moment geen CPU-gebruik, dus het kan lastig zijn om de twee te onderscheiden.
     • Als het probleem wordt veroorzaakt door limieten voor sinks, moet u mogelijk het aantal uitvoer partities (en ook de invoer partities om de taak volledig te kan worden opgestart) verg Roten of de hoeveelheid resources van de Sink verhogen (bijvoorbeeld aantal aanvraag eenheden voor CosmosDB).
   • In taak diagram is er een gebeurtenis metriek per partitie achterstand voor elke invoer. Als de gebeurtenis metriek van de achterstand blijft toenemen, is het ook een indicatie dat de systeem bron is beperkt (als gevolg van beperking van de uitvoer-sink of een hoge CPU).
4. Zodra u hebt bepaald hoe een 6 SU-taak kan bereiken, kunt u lineair de verwerkings capaciteit van de taak extrapoleren wanneer u meer SUs toevoegt, ervan uitgaande dat u geen gegevens scheef hebt die een bepaalde partitie ' hot ' maakt.

Voor beeld 2: als uw query niet-verlegen parallel is.

Als uw query niet verlegen parallel is, kunt u de volgende stappen volgen.

1. Begin met een query zonder partitie door eerst te voor komen dat u de complexiteit partitioneert en voer de query uit met 6 su om de maximale belasting te meten als in het geval 1.
2. Als u in de loop van de door Voer een verwachte belasting kunt krijgen, bent u klaar. U kunt er ook voor kiezen om de taak die wordt uitgevoerd op 3 SU en 1 SU te meten om het minimale aantal SU te bepalen dat geschikt is voor uw scenario.
3. Als de gewenste door Voer niet kan worden bereikt, probeert u de query in meerdere stappen indien mogelijk te verstoren, als deze nog niet meerdere stappen bevat, en u kunt Maxi maal 6 SU toewijzen voor elke stap in de query. Als u bijvoorbeeld drie stappen hebt, wijst u 18 SU toe in de optie schalen.
4. Wanneer een dergelijke taak wordt uitgevoerd, plaatst Stream Analytics elke stap op een eigen knoop punt met toegewezen 6 SU-resources.
5. Als u nog steeds het laad doel hebt bereikt, kunt u proberen om de partitie te gebruiken door te beginnen bij de stappen in de invoer. Voor Group by -operator die niet op natuurlijke wijze kan worden gepartitioneerd, kunt u het lokale/globale aggregatie patroon gebruiken voor het uitvoeren van een gepartitioneerde groep door een niet-GEpartitioneerde groep door te volgen. Bijvoorbeeld, als u wilt tellen hoeveel auto's elke drie minuten elk uur duren, en het volume van de gegevens niet meer kan worden verwerkt door 6 SU.

Query:

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

In de bovenstaande query telt u auto's per gelaagde stand per partitie en voegt u vervolgens het aantal in alle partities samen toe.

Zodra een partitie is gepartitioneerd, wijst u voor elke partitie van de stap Maxi maal 6 SU toe, elke partitie met 6 SU is het maximum, zodat elke partitie kan worden geplaatst op een eigen verwerkings knooppunt.

Case 3: u voert veel onafhankelijke query's uit in een taak.

Voor bepaalde ISV-use-cases, waarbij het rendabeler is om gegevens van meerdere tenants in één taak te verwerken, met behulp van afzonderlijke invoer en uitvoer voor elke Tenant, kunt u uiteindelijk enkele enkele (bijvoorbeeld 20) onafhankelijke query's uitvoeren in één taak. De veronderstelling is dat de belasting van deze subquery relatief klein is. In dit geval kunt u de volgende stappen volgen.

1. Gebruik in dit geval geen partitie door in de query
2. Verminder het aantal invoer partities tot de laagst mogelijke waarde 2 als u Event hub gebruikt.
3. Voer de query uit met 6 SU. Met een verwachte belasting voor elke subquery, voegt u zoveel mogelijk subquery's toe, totdat de taak limieten voor systeem bronnen wordt bereikt. Raadpleeg Case 1 voor de symptomen wanneer dit gebeurt.
4. Zodra u de hierboven gemeten subquery-limiet hebt bereikt, begint u met het toevoegen van de subquery aan een nieuwe taak. Het aantal taken om uit te voeren als een functie van het aantal onafhankelijke query's moet tamelijk lineair zijn, ervan uitgaande dat u geen taak verschil hebt. U kunt vervolgens een prognose maken van het aantal 6 SU-taken dat u moet uitvoeren als een functie van het aantal tenants dat u wilt gebruiken.
5. Wanneer u referentie gegevens samenvoegt met dergelijke query's, moet u de invoer samen voegen voordat u met dezelfde referentie gegevens samenvoegt. Daarna kunt u de gebeurtenissen zo nodig opsplitsen. Anders houdt elke samen voeging met referentie gegevens een kopie van referentie gegevens in het geheugen, waardoor het geheugen gebruik waarschijnlijk onnodig wordt.

Hulp vragen

Probeer voor meer hulp onze micro soft Q&een vraag pagina voor Azure stream Analytics.

Volgende stappen

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