Een Azure Stream Analytics-taak schalen om de doorvoer te verhogen

In dit artikel leest u hoe u een Stream Analytics-query kunt afstemmen om de doorvoer voor Streaming Analytics-taken te verhogen. U kunt de volgende handleiding gebruiken om uw taak te schalen om hogere belasting af te handelen en te profiteren van meer systeemresources (zoals meer bandbreedte, meer CPU-resources, meer geheugen).

Lees de volgende artikelen als een vereiste:

Case 1: uw query is inherent volledig parallelleerbaar voor invoerpartities

Als uw query inherent volledig parallelliseerbaar is voor invoerpartities, kunt u de volgende stappen uitvoeren:

  • Ontwerp uw query om gênant parallel te zijn met behulp van PARTITION BY-trefwoord . Zie Queryparallelisatie gebruiken in Azure Stream Analytics voor meer informatie.
  • Afhankelijk van de uitvoertypen die in uw query worden gebruikt, kan sommige uitvoer niet parallel worden uitgevoerd of moet er een verdere configuratie worden uitgevoerd om gênant parallel te zijn. Power BI-uitvoer kan bijvoorbeeld niet parallell worden uitgevoerd. Uitvoer wordt altijd samengevoegd voordat ze naar de uitvoersink worden verzonden. Blobs, Tabellen, Azure Data Lake Storage, Service Bus en Azure Function worden automatisch geparallelliseerd. SQL- en Azure Synapse Analytics-uitvoer hebben een optie voor parallelle uitvoering. Een Event Hub moet de PartitionKey-configuratie zo hebben ingesteld dat deze overeenkomt met het veld PARTITION BY (meestal PartitionId). Voor Event Hubs moet u ook extra aandacht besteden aan het aantal partities voor alle invoer en alle uitvoer om cross-over tussen partities te voorkomen.
  • Voer uw query uit met 1 streaming-eenheid (SU) V2 (de volledige capaciteit van één rekenknooppunt) om de maximale haalbare doorvoer te meten en als u GROUP BY gebruikt, meet u hoeveel groepen (kardinaliteit) de taak kan verwerken. Algemene symptomen van de taak die de systeemresourcelimieten raken, zijn het volgende.
    • Metrische gegevens over het gebruik van streameenheden (SU) zijn meer dan 80%. Het geeft aan dat het geheugengebruik hoog is. De factoren die bijdragen aan de toename van deze metrische waarde worden beschreven : Begrijpen en aanpassen van Stream Analytics-streaming-eenheden.
    • De tijdstempel van de uitvoer valt achter met betrekking tot de kloktijd van de muur. Afhankelijk van uw querylogica kan de tijdstempel van de uitvoer een logische verschuiving hebben van de kloktijd van de wand. Ze moeten echter met ongeveer hetzelfde tarief worden voortgezet. Als de tijdstempel van de uitvoer verder en verder achterloopt, is het een indicator dat het systeem overwerkt. Dit kan het gevolg zijn van downstream-uitvoerinkbeperking of een hoog CPU-gebruik. We bieden op dit moment geen metrische gegevens over het CPU-gebruik, zodat het lastig kan zijn om de twee te onderscheiden.
      • Als het probleem te wijten is aan sinkbeperking, moet u het aantal uitvoerpartities (en ook invoerpartities verhogen om de taak volledig parallelliseerbaar te houden) of de hoeveelheid resources van de sink verhogen (bijvoorbeeld het aantal aanvraageenheden voor Cosmos DB).
    • In het taakdiagram ziet u voor elke invoer een metrische gegevens voor backlog-gebeurtenissen per partitie. Als de metrische backloggebeurtenis blijft toenemen, is het ook een indicator dat de systeemresource wordt beperkt (vanwege een beperking van de uitvoersink of een hoge CPU).
  • Zodra u de limieten hebt bepaald van wat een SU V2-taak kan bereiken, kunt u lineair de verwerkingscapaciteit van de taak extrapoleren wanneer u meer RU's toevoegt, ervan uitgaande dat u geen scheeftrekken van gegevens hebt waardoor bepaalde partitie 'dynamisch' is.

Notitie

Kies het juiste aantal streaming-eenheden: Omdat Stream Analytics een verwerkingsknooppunt maakt voor elke toegevoegde 1 SU V2, kunt u het beste het aantal knooppunten een deler van het aantal invoerpartities maken, zodat de partities gelijkmatig over de knooppunten kunnen worden verdeeld. U hebt bijvoorbeeld uw 1 SU V2-taak gemeten, kan een verwerkingssnelheid van 4 MB/s bereiken en het aantal invoerpartities is 4. U kunt ervoor kiezen om uw taak uit te voeren met 2 SU V2's om ongeveer 8 MB/s verwerkingssnelheid te bereiken, of 4 SU V2's om 16 MB/s te bereiken. U kunt vervolgens bepalen wanneer u het SU-getal voor de taak wilt verhogen naar welke waarde, als functie van uw invoersnelheid.

Case 2: als uw query niet gênant parallel is.

Als uw query niet gênant parallel is, kunt u deze stappen volgen.

  • Begin met een query zonder PARTITION BY eerst om partitioneringscomplexiteit te voorkomen en voer uw query uit met 1 SU V2 om de maximale belasting te meten zoals in case 1.
  • Als u de verwachte belasting op het gebied van doorvoer kunt bereiken, bent u klaar. U kunt er ook voor kiezen om dezelfde taak te meten die wordt uitgevoerd met fractionele knooppunten op 2/3 SU V2 en 1/3 SU V2, om erachter te komen hoeveel streaming-eenheden voor uw scenario werken.
  • Als u de gewenste doorvoer niet kunt bereiken, probeert u de query in meerdere stappen op te splitsen als deze nog geen meerdere stappen heeft en maximaal één SU V2 toewijst voor elke stap in de query. Als u bijvoorbeeld drie stappen hebt, wijst u drie SU V2's toe in de optie 'Schalen'.
  • Als u een dergelijke taak wilt uitvoeren, plaatst Stream Analytics elke stap op een eigen knooppunt met een toegewezen SU V2-resource.
  • Als u het laaddoel nog steeds niet hebt bereikt, kunt u partitioneren door te beginnen met stappen dichter bij de invoer. Voor GROUP BY-operator die niet op natuurlijke wijze kan worden gepartitioneerd, kunt u het lokale/globale aggregatiepatroon gebruiken om een gepartitioneerde GROUP BY uit te voeren, gevolgd door een niet-gepartitioneerde GROUP BY. Als u bijvoorbeeld elke 3 minuten wilt tellen hoeveel auto's elke 3 minuten door elke tolcel gaan, en het volume van de gegevens is voorbij wat door één SU V2 kan worden verwerkt.

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 query telt u auto's per tolcel per partitie en voegt u vervolgens het aantal van alle partities samen toe.

Zodra de partitie is gepartitioneerd, wijst u voor elke partitie van de stap één SU V2 toe, zodat elke partitie op een eigen verwerkingsknooppunt kan worden geplaatst.

Notitie

Als uw query niet kan worden gepartitioneerd, kan het toevoegen van extra SU in een query met meerdere stappen de doorvoer mogelijk niet altijd verbeteren. Een manier om de prestaties te verbeteren, is het verminderen van het volume in de eerste stappen met behulp van een lokaal/globaal aggregaatpatroon, zoals beschreven in stap 5.

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

Voor bepaalde ISV-gebruiksscenario's, waarbij het rendabeler is om gegevens van meerdere tenants in één taak te verwerken, waarbij afzonderlijke invoer en uitvoer voor elke tenant worden gebruikt, krijgt u uiteindelijk nogal wat onafhankelijke query's (bijvoorbeeld 20) in één taak. De aanname is dat elke subquery relatief klein is.

In dit geval kunt u deze stappen volgen.

  • In dit geval gebruikt u PARTITION BY niet in de query
  • Verminder het aantal invoerpartities tot de laagst mogelijke waarde van 2 als u Event Hubs gebruikt.
  • Voer de query uit met één SU V2. Voeg bij verwachte belasting voor elke subquery zoveel mogelijk subquery's toe totdat de taak de systeemresourcelimieten bereikt. Raadpleeg Case 1 voor de symptomen wanneer dit gebeurt.
  • Zodra u de meting van de limiet voor subquery hebt bereikt, begint u met het toevoegen van de subquery aan een nieuwe taak. Het aantal taken dat moet worden uitgevoerd als een functie van het aantal onafhankelijke query's moet redelijk lineair zijn, ervan uitgaande dat u geen scheeftrekken van de belasting hebt. Vervolgens kunt u voorspellen hoeveel SU V2-taken u moet uitvoeren als een functie van het aantal tenants dat u wilt bedienen.
  • Wanneer u referentiegegevensdeelname met dergelijke query's gebruikt, moet u de invoer samenvoegen voordat u met dezelfde referentiegegevens samenvoegt. Splits vervolgens indien nodig de gebeurtenissen uit. Anders bewaart elke referentiegegevensdeelname een kopie van referentiegegevens in het geheugen, waardoor het geheugengebruik waarschijnlijk onnodig wordt opgeblazen.

Notitie

Hoeveel tenants moeten er in elke taak worden geplaatst? Dit querypatroon heeft vaak een groot aantal subquery's en resulteert in zeer grote en complexe topologie. De controller van de taak kan een dergelijke grote topologie mogelijk niet verwerken. Als vuistregel blijft u onder de 40 tenants voor een SU V2-taak van 1/3 en 60 tenants voor 2/3- en 1 SU V2-taken. Wanneer u de capaciteit van de controller overschrijdt, wordt de taak niet gestart.

Hulp vragen

Probeer onze microsoft Q&A-vragenpagina voor Azure Stream Analytics voor meer hulp.

Volgende stappen