Skalieren eines Azure Stream Analytics-Auftrags zum Erhöhen des Durchsatzes

In diesem Artikel wird erläutert, wie Sie eine Azure Stream Analytics Abfrage optimieren, um den Durchsatz zu erhöhen. Verwenden Sie diese Skalierungsmuster, um eine höhere Last zu verarbeiten, indem Sie mehr Bandbreite, CPU und Arbeitsspeicherressourcen verwenden.

Azure Stream Analytics misst die Berechnungskapazität in streaming units (SUs). Jede SU V2 stellt die volle Kapazität eines einzelnen Computeknotens dar. Eine völlig parallele Abfrage („embarrassingly parallel“) ist eine Abfrage, bei der jede Eingabepartition unabhängig verarbeitet werden kann, ohne dass Daten über Partitionen hinweg gemeinsam genutzt werden.

Voraussetzungen

Bevor Sie beginnen, lesen Sie die folgenden Artikel:

• Streaming-Einheiten verstehen und anpassen
• Erstellen parallelisierbarer Aufträge

Skalieren einer vollständig parallelisierbaren Abfrage

Wenn Ihre Abfrage peinlich parallel über Eingabepartitionen hinweg ist, führen Sie die folgenden Schritte aus:

1. Erstellen Sie Ihre Abfrage, um das Schlüsselwort PARTITION BY zu verwenden. Weitere Informationen finden Sie unter Verwenden der Abfrage-Parallelisierung in Azure Stream Analytics.

2. Abhängig von den in Ihrer Abfrage verwendeten Ausgabetypen kann eine Ausgabe entweder nicht parallelisierbar sein oder eine weitere Konfiguration erforderlich sein, um peinlich parallel zu sein. Konfigurieren Sie z. B. die Ausgaben für die parallele Verarbeitung. Nicht alle Ausgabetypen unterstützen parallele Schreibvorgänge:

   Ausgabetyp	Parallelisierungsunterstützung
   Azure Blob Storage, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions	Automatisch
   Azure SQL-Datenbank, Azure Synapse Analytics	Optional. Erfordert Konfiguration
   Azure Event Hubs	Erfordert, dass PartitionKey mit dem PARTITION BY-Feld übereinstimmt (in der Regel PartitionId). Stimmen Sie die Anzahl der Eingabe- und Ausgabepartitionen überein, um cross-over zu vermeiden.
   Power BI	Nicht parallelisierbar. Die Ausgaben werden immer zusammengeführt, bevor sie an den Sink gesendet werden.

3. Führen Sie Ihre Abfrage mit 1 SU V2 (die volle Kapazität eines einzelnen Computerknotens) aus, um den maximalen erreichbaren Durchsatz zu messen. Wenn Sie GROUP BY verwenden, messen Sie, wie viele Gruppen (Kardinalität) der Auftrag verarbeiten kann.

4. Überprüfen Sie die Grenzwerte für Systemressourcen. Die folgenden Symptome deuten darauf hin, dass Ihr Azure Stream Analytics Auftrag Ressourcengrenzwerte erreicht:

   Symptom	Wahrscheinliche Ursache	Action
   Die Su-%-Auslastungsmetrik überschreitet 80%	Hohe Arbeitsspeicherauslastung. Siehe Grundlegendes zu Streamingeinheiten und deren Anpassung.	Fügen Sie weitere SU V2s hinzu.
   Der Zeitstempel der Ausgabe hinkt der normalen Uhrzeit hinterher	Abhängig von Ihrer Abfragelogik kann der Ausgabezeitstempel einen logischen Offset von der Wanduhrzeit haben. Sie sollten jedoch ungefähr mit der gleichen Rate vorankommen. Wenn der Ausgabezeitstempel immer weiter zurückfällt, ist das ein Indikator dafür, dass das System überlastet ist. Dies kann die Folge einer Drosselung nachgeschalteter Ausgabesenken oder einer hohen CPU-Auslastung sein. Stream Analytics stellt zurzeit keine Metrik für die CPU-Auslastung bereit, sodass es schwierig sein kann, die beiden zu unterscheiden.	Wenn das Problem auf die Sink-Drosselung zurückzuführen ist, vergrößern Sie die Ausgabepartitionen (und die Eingabepartitionen, um die Parallelität aufrechtzuerhalten) oder vergrößern Sie die Ressourcen des Sinks (z.B. Request Units für Azure Cosmos DB).
   Die Metrik für das Ereignis „Backlog pro Partition“ steigt weiter an (sichtbar im Job-Diagramm)	Drosseln des Ausgabe-Sinks oder hohe CPU-Auslastung	Wie oben.

5. Kapazität linear extrapolieren. Nachdem Sie ermittelt haben, was 1 SU V2 verarbeiten kann, fügen Sie proportional weitere SUs hinzu, unter der Annahme, dass zwischen den Partitionen keine Datenungleichverteilung besteht.

Skalieren einer nichtparallelen Abfrage

Wenn Ihre Abfrage nicht völlig parallel ist, folgen Sie diesen Schritten:

1. Starten Sie ohne PARTITION BY , um Komplexität zu vermeiden. Führen Sie die Abfrage mit 1 SU V2 aus, um den maximalen Durchsatz zu messen. Überprüfen Sie die im vorherigen Abschnitt beschriebenen Symptome des Ressourcengrenzwerts (SU-Auslastung über 80%, Zeitstempelverzögerung der Ausgabe, erhöhung des Backlogs).

2. Wenn Sie den Zieldurchsatz erreichen, sind Sie fertig. Testen Sie optional mit 2/3 SU V2 und 1/3 SU V2, um die mindeste SU V2-Anzahl für Ihr Szenario zu ermitteln.

3. Wenn Sie den gewünschten Durchsatz nicht erreichen können, unterteilen Sie die Abfrage in mehrere Schritte. Weisen Sie für jeden Schritt bis zu 1 SU V2 zu. Beispielsweise benötigt eine dreistufige Abfrage 3 SU V2s. Azure Stream Analytics platziert jeden Schritt auf einem eigenen dedizierten Knoten.

4. Wenn Sie Ihr Durchsatzziel noch immer nicht erreicht haben, fügen Sie PARTITION BY bei Schritten hinzu, die näher am Input liegen. Verwenden Sie für GROUP BY-Vorgänge , die nicht natürlich partitionierbar sind, das lokale/globale Aggregatmuster: Führen Sie zuerst ein partitioniertes GROUP BY-Objekt und dann eine nicht partitionierte GROUP BY aus. Zum Beispiel, um die Autos zu zählen, die jede Mautstelle in 3-Minuten-Intervallen passieren, wenn das Verkehrsaufkommen das überschreitet, was 1 SU V2 verarbeiten kann:

   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
   

   Diese Abfrage zählt Autos pro Mautstand pro Partition in Schritt1 und aggregiert dann die partitionierten Anzahlen im letzten Schritt.

   Nachdem Sie die Abfrage partitionieren, weisen Sie 1 SU V2 für jede Partition jedes Schritts zu, sodass jede Partition auf ihrem eigenen Verarbeitungsknoten ausgeführt wird.

   Hinweis

   Wenn Ihre Abfrage nicht partitioniert werden kann, kann das Hinzufügen weiterer SU V2s in einer mehrstufigen Abfrage den Durchsatz möglicherweise nicht verbessern. Um die Leistung zu erzielen, verringern Sie das Volumen in den ersten Schritten, indem Sie das in Schritt 4 gezeigte lokale/globale Aggregatmuster verwenden.

Skalieren mehrerer unabhängiger Abfragen in einem einzigen Auftrag

In Szenarien für unabhängige Softwarehersteller (ISVs) mit mehreren Mandanten, in denen Sie Daten von mehreren Mandanten in einem einzigen Azure Stream Analytics-Job verarbeiten (mit separaten Eingaben und Ausgaben pro Mandant), ist die Last jeder Unterabfrage normalerweise gering. führen Sie die folgenden Schritte aus:

1. Verwenden Sie PARTITION BY nicht in der Abfrage.

2. Wenn Sie Azure Event Hubs verwenden, verringern Sie die Anzahl der Eingabepartitionen auf den Minimalwert 2.

3. Führen Sie die Abfrage mit 1 SU V2 aus. Fügen Sie Unterabfragen hinzu, bis der Auftrag auf Ressourcengrenzwerte trifft. Die Symptome sind identisch mit einer vollständig parallelisierbaren Abfrage: SU-Auslastung über 80%, Ausgabezeitstempelverzögerung oder erhöhung des Backlogs.

4. Nachdem Sie das Unterabfragelimit erreicht haben, fügen Sie einem separaten Auftrag neue Unterabfragen hinzu. Die Anzahl der Jobs skaliert linear mit der Anzahl der unabhängigen Abfragen (vorausgesetzt, es gibt keine ungleiche Lastverteilung). Sie können dann voraussagen, wie viele BLB-V2-Aufträge Sie in Abhängigkeit von der Anzahl der Mandanten, die Sie bedienen möchten, ausführen müssen.

5. Bei Referenzdatenverknüpfungen alle Eingaben vor dem Verknüpfen mit den Referenzdaten vereinigen und die Ereignisse danach wieder aufteilen. Andernfalls behält jede Referenzdatenverknnung eine separate Kopie von Referenzdaten im Arbeitsspeicher bei, was zu einer unnötigen Speicherauslastung führen kann.

Hilfe erhalten

Um weitere Hilfe zu erhalten, probieren Sie die Microsoft Q&A-Frageseite für Azure Stream Analytics aus.

Verwandte Inhalte

• Einführung in Azure Stream Analytics
• Erste Schritte mit Azure Stream Analytics
• Azure Stream Analytics Abfragesprache Referenz
• Referenz zur Azure Stream Analytics-Verwaltungs-REST-API