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

In dit artikel wordt uitgelegd hoe u een Azure Stream Analytics query kunt afstemmen om de doorvoer te verhogen. Gebruik deze schaalpatronen om hogere belasting te verwerken met behulp van meer bandbreedte, CPU en geheugenresources.

Azure Stream Analytics meet de rekencapaciteit in streamingeenheden (SUs). Elke SU V2 vertegenwoordigt de volledige capaciteit van één rekenknooppunt. Een gênant parallelle query is een query waarbij elke invoerpartitie onafhankelijk kan worden verwerkt, zonder gegevens die worden gedeeld tussen partities.

Prerequisites

Lees deze artikelen voordat u begint:

Een volledig paralleliseerbare query schalen

Als uw query gênant parallel is voor invoerpartities, voert u de volgende stappen uit:

  1. Ontwerp uw query om het trefwoord PARTITION BY te gebruiken. Zie Queryparallelisatie gebruiken in Azure Stream Analytics voor meer informatie.

  2. 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. Configureer bijvoorbeeld uw uitvoer voor parallelle uitvoering. Niet alle uitvoertypen ondersteunen parallelle schrijfbewerkingen:

    Uitvoertype Ondersteuning voor parallelle uitvoering
    Azure Blob Storage, Azure-tabelopslag, Azure Data Lake Storage, Azure Service Bus, Azure Functions Automatic
    Azure SQL Database, Azure Synapse Analytics Optional. Configuratie vereist
    Azure Event Hubs Vereist dat deze PartitionKey overeenkomt met het veld PARTITION BY (meestal PartitionId). Stem het aantal invoer- en uitvoerpartities op elkaar af om kruisingen te voorkomen.
    Power BI Niet parallelleerbaar. Uitvoer wordt altijd samengevoegd voordat ze naar de sink worden verzonden

  3. Voer uw query uit met 1 SU V2 (de volledige capaciteit van één rekenknooppunt) om de maximale haalbare doorvoer te meten. Als u GROUP BY gebruikt, meet u hoeveel groepen (kardinaliteit) de taak kan verwerken.

  4. Controleer op systeemresourcelimieten. De volgende symptomen geven aan dat uw Azure Stream Analytics taak resourcelimieten bereikt:

    Symptoom Waarschijnlijke oorzaak Action
    Metrische gegevens voor SU-% gebruik overschrijden 80% Hoog geheugengebruik. Zie Streaming-eenheden begrijpen en aanpassen. Voeg meer SU V2's toe.
    Tijdstempel van uitvoer valt achter 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 in ongeveer hetzelfde tempo vooruitgaan. 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. Stream Analytics biedt op dit moment geen metrische gegevens over het CPU-gebruik, zodat het lastig kan zijn om de twee te onderscheiden. Als het probleem wordt veroorzaakt door sinkthrottling, verhoog dan het aantal uitvoerpartities (en invoerpartities om het parallellisme te behouden), of vergroot de resources van de sink (bijvoorbeeld Request Units voor Azure Cosmos DB).
    De backloggebeurtenismetriek per partitie blijft toenemen (zichtbaar in jobdiagram) Uitvoersinkbeperking of hoge CPU Hetzelfde als hierboven.

  5. Extrapoleer de capaciteit lineair. Nadat u hebt vastgesteld wat 1 SU V2 kan verwerken, voegt u proportioneel meer SU's toe, ervan uitgaand dat er geen scheef verdeelde gegevens over partities zijn.

Opmerking

Keuze het juiste aantal SU V2s: Azure Stream Analytics maakt één verwerkingsknooppunt voor elke SU V2. Maak het aantal SU V2's een deler van het aantal invoerpartities, zodat partities gelijkmatig worden verdeeld.

Voorbeeld: Een 1 SU V2-taak verwerkt 4 MB/s met 4 invoerpartities. Gebruik 2 SU V2's voor ~8 MB/s of 4 SU V2's voor ~16 MB/s. Kies het aantal SU V2 op basis van uw doelinvoersnelheid.

Schaal een niet-parallelle query

Als uw query niet gênant parallel is, voert u de volgende stappen uit:

  1. Begin zonder PARTITION BY om complexiteit te voorkomen. Voer de query uit met 1 SU V2 om de maximale doorvoer te meten. Controleer op dezelfde resourcelimietsymptomen die worden beschreven in de vorige sectie (SU-gebruik meer dan 80%, vertraging van uitvoertijdstempel, toenemende achterstand).

  2. Als u uw doeldoorvoer bereikt, bent u klaar. Test eventueel met 2/3 SU V2 en 1/3 SU V2 om het minimale aantal SU V2 voor uw scenario te vinden.

  3. Als u de gewenste doorvoer niet kunt bereiken, breekt u de query op in meerdere stappen. Wijs maximaal 1 SU V2 toe voor elke stap. Een query met drie stappen heeft bijvoorbeeld 3 SU V2's nodig. Azure Stream Analytics elke stap op een eigen toegewezen knooppunt plaatst.

  4. Als u uw doorvoerdoel nog steeds niet hebt bereikt, voegt u PARTITION BY toe aan de stappen dichter bij de invoer. Voor GROUP BY-bewerkingen die niet op natuurlijke wijze kunnen worden gepartitioneerd, gebruikt u het lokale/globale statistische patroon: voer eerst een gepartitioneerde GROUP BY uit en vervolgens een niet-gepartitioneerde GROUP BY. Als u bijvoorbeeld auto's elke 3 minuten door elke tolstand wilt tellen wanneer het volume overschrijdt wat 1 SU V2 kan verwerken:

    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

    Met deze query worden auto's per tolcel per partitie in Stap1 geteld en worden vervolgens de gepartitioneerde aantallen samengevoegd in de laatste stap.

    Nadat u de query hebt gepartitioneerde, wijst u 1 SU V2 toe voor elke partitie van elke stap, zodat elke partitie wordt uitgevoerd op een eigen verwerkingsknooppunt.

    Opmerking

    Als uw query niet kan worden gepartitioneerd, wordt de doorvoer mogelijk niet verbeterd door meer SU V2's toe te voegen in een query met meerdere stappen. Voor betere prestaties vermindert u het volume in de eerste stappen met behulp van het lokale/globale statistische patroon dat wordt weergegeven in stap 4.

Meerdere onafhankelijke query’s schalen binnen één taak

Voor ISV-scenario's (Multitenant Independent Software Vendor) waarbij u gegevens van meerdere tenants in één Azure Stream Analytics taak (met afzonderlijke invoer en uitvoer per tenant) verwerkt, is de belasting van elke subquery doorgaans klein. Volg deze stappen:

  1. Gebruik PARTITION BY niet in de query.

  2. Als u Azure Event Hubs gebruikt, vermindert u het aantal invoerpartities tot de minimumwaarde van 2.

  3. Voer de query uit met 1 SU V2. Voeg subquery's toe totdat de taak de resourcelimieten bereikt. De symptomen zijn hetzelfde als voor een volledig paralleliseerbare query: SU-gebruik van meer dan 80%, vertraging in de uitvoertijdstempel of een toenemende achterstand.

  4. Nadat u de limiet voor subquery hebt bereikt, voegt u nieuwe subquery's toe aan een afzonderlijke taak. Het aantal taken neemt lineair toe met het aantal onafhankelijke query’s (ervan uitgaande dat er geen scheve verdeling van de belasting optreedt). Vervolgens kunt u voorspellen hoeveel SU V2-taken u moet uitvoeren als een functie van het aantal tenants dat u wilt bedienen.

  5. Voor referentiegegevensdeelnames voegt u alle invoer samen voordat u met de referentiegegevens deelneemt en splitst u de gebeurtenissen daarna op. Anders bewaart elke referentiegegevensdeelname een afzonderlijke kopie van referentiegegevens in het geheugen, wat onnodig geheugengebruik kan veroorzaken.

Opmerking

Maximum aantal tenants per taak: Blijf onder de 40 tenants voor een 1/3 SU V2-taak en 60 tenants voor 2/3- en 1 SU V2-taken. Grote aantallen subquery's maken complexe topologieën die de taakcontroller mogelijk niet verwerkt, waardoor de taak niet kan worden gestart.

Hulp krijgen

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

Verwante inhoud

  • Last updated on