Freigeben über

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

In diesem Artikel erfahren Sie, wie Sie eine Stream Analytics-Abfrage optimieren, um den Durchsatz für Streaming Analytics-Aufträge zu erhöhen. Sie können den folgenden Leitfaden verwenden, um Ihren Auftrag zu skalieren, um höhere Last zu verarbeiten und mehr Systemressourcen zu nutzen (z. B. mehr Bandbreite, mehr CPU-Ressourcen, mehr Arbeitsspeicher).

Lesen Sie als Voraussetzung die folgenden Artikel:

Fall 1 – Ihre Abfrage ist inhärent vollständig parallelisierbar über Eingabepartitionen hinweg

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 Verwenden der Abfrage-Parallelisierung in Azure Stream Analytics.
  • 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. Beispielsweise ist die Power BI-Ausgabe nicht parallelisierbar. Ausgaben werden immer zusammengeführt, bevor sie an den Ausgabepuffer gesendet werden. Blobs, Tabellen, Azure Data Lake Storage, Service Bus und Azure Function werden automatisch parallelisiert. SQL- und Azure Synapse Analytics-Ausgaben haben eine Option für die Parallelisierung. Für einen Event Hub muss die PartitionKey-Konfiguration so festgelegt sein, dass sie mit dem Feld PARTITION BY übereinstimmt (in der Regel PartitionId). Achten Sie für Event Hubs auch besonders darauf, die Anzahl der Partitionen sowohl bei allen Eingaben als auch bei allen Ausgaben abzugleichen, um Überschneidungen zwischen Partitionen zu vermeiden.
  • Führen Sie Ihre Abfrage mit einer Streamingeinheit (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. Allgemeine Symptome eines Auftrags, der die Systemressourcengrenzen erreicht – sind die folgenden:
    • Die Datenstromeinheit (SU) %-Auslastungsmetrik beträgt über 80 %. Dies weist darauf hin, dass die Speicherauslastung hoch ist. Die Faktoren, die zur Erhöhung 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. 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. Wir stellen zurzeit keine Metrik für die CPU-Auslastung bereit, sodass es schwierig sein kann, die beiden zu unterscheiden.
      • 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).
    • Im Jobdiagramm gibt es eine Backlog-Ereignismetrik pro Partition für jede Eingabe. 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 aus: Da Stream Analytics für jede hinzugefügte SU V2 einen Verarbeitungsknoten erstellt, ist es am besten, die Anzahl der Knoten zu einem Divisor der Anzahl der Eingabepartitionen zu machen, sodass die Partitionen gleichmäßig über die Knoten verteilt werden können. Beispielsweise haben Sie gemessen, dass Ihr 1 SU V2-Auftrag eine Verarbeitungsrate von 4 MB/s erreichen kann, und die Anzahl der Eingabepartitionen beträgt 4. Sie können Ihren Auftrag mit 2 SU V2s ausführen, um ungefähr 8 MB/s Verarbeitungsrate zu erreichen, oder 4 SU V2s, um 16 MB/s zu erreichen. 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 Abfrage nicht peinlich parallel ist, können Sie diese Schritte ausführen.

  • Beginnen Sie zunächst mit einer Abfrage ohne PARTITION BY , um Partitionierungskomplexität zu vermeiden, und führen Sie Ihre Abfrage mit 1 SU V2 aus, um die maximale Auslastung wie in Fall 1 zu messen.
  • Wenn Sie ihre erwartete Last als 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, Die Abfrage in mehrere Schritte zu unterteilen, wenn sie noch nicht mehrere Schritte enthält, und weisen Sie für jeden Schritt in der Abfrage bis zu einem 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, platziert Stream Analytics jeden Schritt auf einem eigenen Knoten mit einer dedizierten SU V2-Ressource.
  • Wenn Sie Ihr Ladeziel noch nicht erreicht haben, können Sie versuchen, PARTITION BY zu verwenden, indem Sie mit den Schritten näher an der Eingabe beginnen. Für GROUP BY-Operator , der nicht natürlich partitionierbar ist, können Sie das lokale/globale Aggregatmuster verwenden, um eine partitionierte GROUP BY gefolgt von einer nicht partitionierten GROUP BY auszuführen. Wenn Sie z. B. ermitteln möchten, wie viele Autos alle 3 Minuten durch die einzelnen Mautstellen gehen, und die Datenmenge geht über das hinaus, was von einem SU V2 verarbeitet werden kann.

Frage:

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 einen SU V2 zu, damit jede Partition auf ihrem eigenen Verarbeitungsknoten platziert werden kann.

Hinweis

Wenn Ihre Abfrage nicht partitioniert werden kann, kann das Hinzufügen zusätzlicher SU in einer Abfrage mit mehreren Schritten möglicherweise nicht immer den Durchsatz verbessern. Eine Möglichkeit zur Leistungssteigerung besteht darin, das Volumen der ersten Schritte mithilfe des lokalen/globalen Aggregatmusters zu reduzieren, wie in Schritt 5 beschrieben.

Fall 3 : Sie führen viele unabhängige Abfragen in einem Auftrag aus.

Bei bestimmten ISV-Anwendungsfällen, in denen es kosteneffizienter ist, Daten aus mehreren Mandanten in einem einzigen Auftrag zu verarbeiten, indem Sie separate Eingaben und Ausgaben für jeden Mandanten verwenden, führen Sie einige unabhängige Abfragen (z. B. 20) in einem einzigen Auftrag aus. Es wird davon ausgegangen, dass die Belastung jeder solchen Unterabfrage relativ gering ist.

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

  • Verwenden Sie in diesem Fall nicht PARTITION BY in der Abfrage.
  • Verringern Sie die Anzahl der Eingabepartitionen auf den niedrigsten möglichen Wert von 2, wenn Sie Event Hubs verwenden.
  • Führen Sie die Abfrage mit einem SU V2 aus. Fügen Sie bei erwarteter Auslastung für jede Unterabfrage so viele unterabfragen wie möglich hinzu, bis der Auftrag auf Systemressourcengrenzwerte trifft. Beziehen Sie sich auf Fall 1 für die Symptome, wenn dies geschieht.
  • Sobald Sie den gemessenen Grenzwert für Unterabfragen erreicht haben, beginnen Sie mit dem Hinzufügen der Unterabfrage zu einem neuen Auftrag. 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. Teilen Sie dann die Ereignisse bei Bedarf auf. Andernfalls behält jede Referenzdatenverknüpfung eine Kopie der Referenzdaten im Arbeitsspeicher bei, was wahrscheinlich die Speicherauslastung unnötig aufbläht.

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 kann eine solche große Topologie möglicherweise nicht 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

  • Last updated on