Opnieuw partitioneren gebruiken om de verwerking te optimaliseren met Azure Stream Analytics

  • Artikel

In dit artikel wordt beschreven hoe u opnieuw partitioneren kunt gebruiken om uw Azure Stream Analytics-query te schalen voor scenario's die niet volledig parallel kunnen worden geparallelliseerd.

Mogelijk kunt u geen parallelle uitvoering gebruiken als:

  • U bepaalt niet de partitiesleutel voor uw invoerstroom.
  • De bron 'sprayt' invoer over meerdere partities die later moeten worden samengevoegd.

Opnieuw partitioneren of opnieuw toewijzen is vereist wanneer u gegevens verwerkt in een stream die niet is geshard volgens een natuurlijk invoerschema, zoals PartitionId voor Event Hubs. Wanneer u repartitiont, kan elke shard onafhankelijk worden verwerkt, zodat u uw streaming-pijplijn lineair kunt uitschalen.

Opnieuw partitioneren

U kunt uw invoer op twee manieren opnieuw partitioneren:

  1. Een afzonderlijke Stream Analytics-taak gebruiken die de herpartitionering uitvoert
  2. Gebruik één taak, maar voer eerst de herpartitionering uit vóór uw aangepaste analyselogica

Een afzonderlijke Stream Analytics-taak maken om invoer opnieuw te partitioneren

U kunt een taak maken die invoer leest en schrijft naar een Event Hub-uitvoer met behulp van een partitiesleutel. Deze Event Hub kan vervolgens fungeren als invoer voor een andere Stream Analytics-taak waar u uw analyselogica implementeert. Wanneer u deze Event Hub-uitvoer in uw taak configureert, moet u de partitiesleutel opgeven waarmee Uw gegevens opnieuw worden gepartitioneerd in Stream Analytics.

-- For compat level 1.2 or higher
SELECT * 
INTO output
FROM input

--For compat level 1.1 or lower
SELECT *
INTO output
FROM input PARTITION BY PartitionId

Invoer opnieuw partitioneren binnen één Stream Analytics-taak

U kunt ook een stap in uw query introduceren waarmee de invoer eerst opnieuw wordt gepartitionseerd, die vervolgens kan worden gebruikt door andere stappen in uw query. Als u bijvoorbeeld invoer opnieuw wilt partitioneren op basis van DeviceId, is uw query:

WITH RepartitionedInput AS 
( 
    SELECT * 
    FROM input PARTITION BY DeviceID
)

SELECT DeviceID, AVG(Reading) as AvgNormalReading  
INTO output
FROM RepartitionedInput  
GROUP BY DeviceId, TumblingWindow(minute, 1)

Met de volgende voorbeeldquery worden twee streams met opnieuw gepartitioneerde gegevens samengevoegd. Wanneer u twee streams met opnieuw gepartitioneerde gegevens koppelt, moeten de streams dezelfde partitiesleutel en hetzelfde aantal hebben. Het resultaat is een stream met hetzelfde partitieschema.

WITH step1 AS 
(
    SELECT * FROM input1 
    PARTITION BY DeviceID
),
step2 AS 
(
    SELECT * FROM input2 
    PARTITION BY DeviceID
)

SELECT * INTO output 
FROM step1 PARTITION BY DeviceID 
UNION step2 PARTITION BY DeviceID

Het uitvoerschema moet overeenkomen met de sleutel en het aantal stroomschema's, zodat elke substroom onafhankelijk kan worden leeggemaakt. De stroom kan ook worden samengevoegd en opnieuw worden gepartitioneerd door een ander schema voordat u de stroom leegmaken, maar u moet deze methode vermijden omdat deze toevoegt aan de algemene latentie van de verwerking en het resourcegebruik verhoogt.

Streaming-eenheden voor opnieuw partitioneren

Experimenteer en bekijk het resourcegebruik van uw taak om het exacte aantal partities te bepalen dat u nodig hebt. Het aantal streaming-eenheden (SU) moet worden aangepast aan de fysieke resources die nodig zijn voor elke partitie. Over het algemeen zijn er zes RU's nodig voor elke partitie. Als er onvoldoende resources aan de taak zijn toegewezen, past het systeem alleen de repartitie toe als deze ten goede komt aan de taak.

Repartitions voor SQL-uitvoer

Wanneer uw taak SQL-database gebruikt voor uitvoer, gebruikt u expliciete herpartitionering om het optimale aantal partities te vinden om de doorvoer te maximaliseren. Omdat SQL het beste werkt met acht schrijvers, kan het herpartitioneren van de stroom naar acht voordat de stroom wordt leeggemaakt, of ergens hogerop, de prestaties van taken mogelijk verbeteren.

Wanneer er meer dan acht invoerpartities zijn, is het overnemen van het invoerpartitioneringsschema mogelijk geen geschikte keuze. Overweeg OM INTO in uw query te gebruiken om expliciet het aantal uitvoerschrijvers op te geven.

In het volgende voorbeeld wordt uit de invoer gelezen, ongeacht of deze op natuurlijke wijze wordt gepartitioneerd en wordt de stroom tien keer opnieuw gepartitioneerd volgens de DeviceID-dimensie en worden de gegevens naar uitvoer gewist.

SELECT * INTO [output] 
FROM [input] 
PARTITION BY DeviceID INTO 10

Zie De uitvoer van Azure Stream Analytics naar Azure SQL Database voor meer informatie.

Volgende stappen