Teilen über

Skalieren eines Azure Stream Analytics-Auftrags zur Erhöhung des Durchsatzes

  • Artikel

In diesem Artikel erfahren Sie, wie Sie eine Stream Analytics-Abfrage zur Steigerung des Durchsatzes für Stream Analytics-Aufträge optimieren. Im folgenden Leitfaden wird erläutert, wie Sie Ihren Auftrag zur Verarbeitung höherer Lasten skalieren und von einer größeren Menge an Systemressourcen (z.B. Bandbreite, CPU-Ressourcen, Arbeitsspeicher) profitieren können.

Als Voraussetzung sollten Sie die folgenden Artikel lesen:

Fall 1: Ihre Abfrage ist prinzipiell über alle Eingabepartitionen hinweg vollständig parallelisierbar.

Wenn Ihre Abfrage prinzipiell über alle Eingabepartitionen hinweg vollständig parallelisierbar ist, können Sie folgende Schritte durchführen:

  • Erstellen Sie mithilfe des Schlüsselworts PARTITION BY eine Abfrage mit hohem Parallelitätsgrad. Weitere Informationen finden Sie unter Verwendung der Abfrageparallelisierung in Azure Stream Analytics.
  • Je nach den in Ihrer Abfrage verwendeten Ausgabetypen sind einige Ausgaben entweder nicht parallelisierbar oder müssen weiter konfiguriert werden, um hochgradig parallel zu sein. Die Power BI-Ausgabe ist beispielsweise nicht parallelisierbar. Ausgaben werden immer zusammengeführt, bevor sie an die Ausgabesenke gesendet werden. Blobs, Tabellen, Azure Data Lake Storage, Service Bus und Azure Function werden automatisch parallelisiert. SQL- und Azure Synapse Analytics-Ausgaben verfügen über eine Option zur Parallelisierung. Bei einem Event Hub muss die PartitionKey-Konfiguration so eingestellt sein, dass sie mit dem Feld PARTITION BY übereinstimmt (normalerweisePartitionId ). Achten Sie bei Event Hubs insbesondere darauf, dass die Anzahl der Partitionen für alle Eingaben der Anzahl der Partitionen für alle Ausgaben entspricht, um eine Überkreuzung zwischen den Partitionen zu verhindern.
  • Führen Sie Ihre Abfrage mit 1 Streamingeinheit (SU) V2 (das ist die volle Kapazität eines einzelnen Rechenknotens) aus, um den maximal erreichbaren Durchsatz zu messen, und wenn Sie GROUP BY verwenden, messen Sie, wie viele Gruppen (Kardinalität) der Auftrag verarbeiten kann. Zu den allgemeinen Symptomen, die bei Erreichen der Systemressourcenlimits durch den Auftrag auftreten, zählen Folgende:
    • Die Datenstromeinheit (SU) %-Auslastungsmetrik beträgt über 80 %. Es zeigt an, dass die Speicherauslastung hoch ist. Die Faktoren, die zum Anstieg dieser Metrik beitragen, werden in Verstehen und Anpassen von Stream Analytics-Streamingeinheiten beschrieben.
    • Der Ausgabezeitstempel liegt gegenüber der Gesamtbetrachtungszeit im Rückstand. Abhängig von Ihrer Abfragelogik kann der Ausgabezeitstempel einen logischen Offset von der Wanduhrzeit haben. Diese sollten jedoch in ungefähr derselben Geschwindigkeit verlaufen. Wenn der Ausgabezeitstempel immer weiter zurückfällt, weist dies auf eine Überlastung des Systems hin. Dies kann die Folge einer Drosselung nachgeschalteter Ausgabesenken oder einer hohen CPU-Auslastung sein. Zurzeit stellen wir nicht die Metrik „CPU-Auslastung“ bereit, sodass es schwierig sein kann, zwischen beiden Ursachen zu differenzieren.
      • Wenn das Problem auf die Bandbreiteneinschränkung der Senke zurückzuführen ist, müssen Sie die Anzahl der Ausgabepartitionen erhöhen (und auch die Eingabepartitionen, um den Auftrag vollständig parallelisierbar zu halten) oder die Anzahl der Ressourcen der Senke erhöhen (z. B. die Anzahl der Anforderungseinheiten für Cosmos DB).
    • Das Auftragsdiagramm enthält für jede Eingabe eine Backlog-Ereignismetrik pro Partition. Wenn die Backlogereignismetrik weiter steigt, ist dies auch ein Indikator dafür, dass die Systemressource eingeschränkt ist (entweder aufgrund einer Drosselung der Ausgabesenke oder einer hohen CPU-Auslastung).
  • Sobald Sie die Grenzen eines V2-Auftrags mit einer SU ermittelt haben, können Sie die Verarbeitungskapazität des Auftrags linear extrapolieren, wenn Sie weitere SUs hinzufügen, vorausgesetzt, Sie haben keine Datenschieflage, die bestimmte Partitionen „heiß“ macht.

Hinweis

Wählen Sie die richtige Anzahl von Streamingeinheiten: Da Stream Analytics für jede hinzugefügte 1 SU V2 einen Verarbeitungsknoten erstellt, ist es am besten, die Anzahl der Knoten durch die Anzahl der Eingabepartitionen zu teilen, damit die Partitionen gleichmäßig auf die Knoten verteilt werden können. Beispiel: Sie haben gemessen, dass Ihr 1-SU-V2-Auftrag eine Verarbeitungsrate von 4 MB/s erreichen kann. Die Anzahl Ihrer Eingabepartitionen beträgt 4. Sie können festlegen, dass Aufträge mit 2 SU V2 ungefähr eine Verarbeitungsrate von 8 MB/s erreichen und Aufträge mit 4 SU V2 16 MB/s erreichen sollen. Anschließend können Sie entscheiden, auf welchen Wert die Anzahl der SUs für den Auftrag in Abhängigkeit von der Eingangsrate erhöht werden soll.

Fall 2: Ihre Abfrage ist nicht hochgradig parallel.

Wenn Ihre Anfrage nicht hochgradig parallel ist, können Sie diese Schritte befolgen.

  • Beginnen Sie zuerst mit einer Abfrage ohne PARTITION BY, um die Komplexität der Partitionierung gering zu halten, und führen Sie Ihre Abfrage mit 1 SU V2 aus, um wie in Fall 1 die maximale Last zu messen.
  • Wenn Sie Ihre erwartete Last im Hinblick auf den Durchsatz erreichen können, sind Sie fertig. Alternativ können Sie denselben Auftrag auch mit Teilknoten bei 2/3 SU V2 und 1/3 SU V2 messen, um die minimale Anzahl von Streamingeinheiten zu ermitteln, die für Ihr Szenario geeignet ist.
  • Wenn Sie den gewünschten Durchsatz nicht erreichen können, versuchen Sie, Ihre Abfrage in mehrere Schritte aufzuteilen, wenn sie nicht bereits mehrere Schritte hat, und weisen Sie jedem Schritt der Abfrage bis zu einer SU V2 zu. Wenn Sie beispielsweise drei Schritte ausführen, weisen Sie drei SU V2s in der Option „Skalieren“ zu.
  • Um einen solchen Auftrag auszuführen, legt Stream Analytics jeden Schritt auf einen eigenen Knoten mit einer dedizierten SU V2-Ressource.
  • Wenn Sie Ihr Lastziel dennoch nicht erreicht haben, können Sie versuchen, PARTITION BY beginnend mit den Schritten näher an der Eingabe zu verwenden. Für GROUP BY-Operatoren, die nicht natürlich partitionierbar sind, können Sie das lokale/globale Aggregatmuster verwenden, um ein partitioniertes GROUP BY gefolgt von einem nicht partitionierten GROUP BY durchzuführen. Wenn Sie z. B. zählen möchten, wie viele Fahrzeuge alle 3 Minuten durch eine Mautstelle fahren, und das Datenvolumen übersteigt die Möglichkeiten einer SU V2.

Abfrage:

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 der Abfrage zählen Sie die Fahrzeuge pro Mautstelle und pro Partition und addieren dann die Anzahl aller Partitionen zusammen.

Nach der Partitionierung weisen Sie für jede Partition des Schritts eine SU V2 zu, so dass jede Partition auf ihrem eigenen Verarbeitungsknoten platziert werden kann.

Hinweis

Wenn Ihre Abfrage nicht partitioniert werden kann, kann der Durchsatz nicht immer durch Hinzufügen zusätzlicher SUs in einer Abfrage mit mehreren Schritten verbessert werden. Eine Möglichkeit, die Leistung zu steigern, ist die Reduzierung des Volumens bei den ersten Schritten mit Hilfe lokaler/globaler Aggregatmuster, wie in Schritt 5 beschrieben.

Fall 3: Sie führen eine Vielzahl von unabhängigen Abfragen in einem Auftrag aus.

In bestimmten ISV-Anwendungsfällen, in denen es kosteneffizienter ist, Daten von mehreren Mandanten in einem einzigen Auftrag zu verarbeiten und dabei separate Ein- und Ausgaben für jeden Mandanten zu verwenden, führen Sie am Ende eine ganze Reihe (z. B. 20) unabhängiger Abfragen in einem einzigen Auftrag aus. Es wird davon ausgegangen, dass die Last der einzelnen Unterabfragen relativ gering ist.

In diesem Fall können Sie diese Schritte ausführen.

  • Verwenden Sie in diesem Fall nicht PARTITION BY in der Abfrage.
  • Wenn Sie den Event Hub verwenden, reduzieren Sie die Anzahl der Eingabepartitionen auf den kleinstmöglichen Wert 2.
  • Führen Sie die Abfrage mit einem SU V2 aus. Fügen Sie bei erwarteten Lasten für jede Unterabfrage möglichst viele Unterabfragen hinzu, bis der Auftrag die Systemressourcengrenzen erreicht. Siehe Fall 1 für die Symptome, wenn dies geschieht.
  • Sobald Sie das gemessene Limit für Unterabfragen erreicht haben, fügen Sie die Unterabfrage zu einem neuen Auftrag hinzu. Die Anzahl der Aufträge, die in Abhängigkeit von der Anzahl der unabhängigen Abfragen ausgeführt werden muss, sollte relativ linear sein. Dies gilt nur unter der Voraussetzung, dass keine Datenschiefe vorliegt. 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.
  • Wenn Sie bei solchen Abfragen die JOIN-Anweisung für Verweisdaten verwenden, fassen Sie die Eingaben zusammen, bevor Sie sie mit den gleichen Verweisdaten zusammenfassen. Gliedern Sie anschließend die Ereignisse bei Bedarf aus. Andernfalls wird bei jeder JOIN-Anweisung für Verweisdaten eine Kopie der Verweisdaten im Arbeitsspeicher gespeichert, wodurch aller Wahrscheinlichkeit nach die Speicherauslastung unnötig in die Höhe schießt.

Hinweis

Wie viele Mandanten sollten in einem Auftrag aufgenommen werden? Dieses Abfragemuster weist häufig eine große Anzahl von Unterabfragen auf und führt zu einer sehr großen und komplexen Topologie. Der Controller des Auftrags ist dann eventuell nicht in der Lage, eine derart große Topologie zu verarbeiten. Als Faustregel gilt daher, maximal 40 Mandanten bei einem 1/3-SU-V2-Auftrag und 60 Mandanten bei Aufträgen mit 2/3 SU V2 und 1 SU V2 aufzunehmen. Wenn Sie die Kapazität des Controllers überschreiten, wird der Auftrag nicht erfolgreich gestartet.

Hilfe erhalten

Weitere Unterstützung finden Sie auf der Frageseite von Microsoft Q&A (Fragen und Antworten) zu Azure Stream Analytics.

Nächste Schritte