Freigeben über

Prüfpunkt- und Wiedergabekonzepte in Azure Stream Analytics-Aufträgen

In diesem Artikel werden die internen Prüfpunkt- und Wiedergabekonzepte in Azure Stream Analytics und die Auswirkungen auf die Wiederherstellung von Arbeitsplätzen beschrieben. Jedes Mal, wenn ein Stream Analytics-Auftrag ausgeführt wird, werden Statusinformationen intern verwaltet. Diese Statusinformationen werden in regelmäßigen Abständen in einem Prüfpunkt gespeichert. In einigen Szenarien werden die Prüfpunktinformationen für die Auftragswiederherstellung verwendet, wenn ein Auftragsfehler oder ein Upgrade auftritt. Unter anderen Umständen kann der Prüfpunkt nicht für die Wiederherstellung verwendet werden, und eine Wiedergabe ist erforderlich.

Zustandsbehaftete Abfragelogik in temporalen Elementen

Eine der einzigartigen Fähigkeiten von Azure Stream Analytics ist die Durchführung zustandsbehafteter Verarbeitung, wie zum Beispiel fensterbasierte Aggregationen, zeitliche Verknüpfungen und zeitliche Analysefunktionen. Jeder dieser Operatoren speichert Zustandsinformationen, wenn der Auftrag ausgeführt wird. Die maximale Fenstergröße für diese Abfrageelemente beträgt sieben Tage.

Der Begriff der temporalen Fenster kommt in mehreren Stream Analytics-Abfrageelementen vor:

  1. Fensteraggregate (GROUP BY bei Tumbling-, Hopping- und Gleitfenstern)

  2. Zeitliche Verknüpfungen (JOIN mit DATEDIFF)

  3. Zeitbezogene Analysefunktionen (ISFIRST, LAST und LAG mit LIMIT DURATION)

Auftragswiederherstellung nach einem Knotenfehler, einschließlich Betriebssystemupgrade

Jedes Mal, wenn ein Stream Analytics-Auftrag ausgeführt wird, wird er intern so skaliert, dass er über mehrere Arbeitsknoten hinweg funktioniert. Der Zustand jedes Arbeitsknotens wird alle paar Minuten überprüft, wodurch das System bei einem Fehler wiederhergestellt werden kann.

Manchmal kann ein bestimmter Workerknoten ausfallen, oder ein Betriebssystemupgrade kann für diesen Workerknoten durchgeführt werden. Um sich automatisch wiederherzustellen, erwirbt Stream Analytics einen neuen funktionsfähigen Knoten, und der Status des vorherigen Arbeitsknoten wird vom neuesten verfügbaren Prüfpunkt wiederhergestellt. Um die Arbeit fortzusetzen, ist eine kleine Menge an Wiedergabe erforderlich, um den Zustand ab dem Zeitpunkt wiederherzustellen, zu dem der Prüfpunkt genommen wird. In der Regel beträgt die Wiederherstellungslücke nur ein paar Minuten. Wenn genügend Streamingeinheiten für den Auftrag ausgewählt werden, sollte die Wiedergabe schnell abgeschlossen sein.

In einer vollständig parallelen Abfrage ist die Zeit, die benötigt wird, um sich nach einem Arbeitsknotenfehler wieder anzupassen, proportional zu:

[die Eingabeereignisrate] x [die Abstandslänge] / [Anzahl der Verarbeitungspartitionen]

Wenn Sie aufgrund eines Knotenfehlers und eines Betriebssystemupgrades erhebliche Verarbeitungsverzögerungen feststellen, sollten Sie die Abfrage vollständig parallel durchführen und den Auftrag skalieren, um weitere Streamingeinheiten zuzuweisen. Weitere Informationen finden Sie unter Skalieren eines Azure Stream Analytics-Auftrags, um den Durchsatz zu erhöhen.

Aktuelle Stream Analytics zeigt keinen Bericht an, wenn diese Art von Wiederherstellungsprozess stattfindet.

Wiederherstellung von Aufgaben nach einem Dienstupgrade

Microsoft aktualisiert gelegentlich die Binärdateien, die die Stream Analytics-Aufträge im Azure-Dienst ausführen. Zu diesen Zeiten werden die ausgeführten Aufträge der Benutzer auf eine neuere Version aktualisiert, und der Auftrag wird automatisch neu gestartet.

Azure Stream Analytics verwendet Prüfpunkte, sofern möglich, um Daten aus dem letzten prüfpunktierten Zustand wiederherzustellen. In Szenarien, in denen interne Prüfpunkte nicht verwendet werden können, wird der Status der Streamingabfrage vollständig mithilfe einer Wiedergabetechnik wiederhergestellt. Damit Stream Analytics-Aufträge dieselbe Eingabe wie zuvor wiedergeben können, ist es wichtig, die Aufbewahrungsrichtlinie für die Quelldaten auf mindestens die Fenstergrößen in Ihrer Abfrage festzulegen. Andernfalls kann dies zu falschen oder teilweisen Ergebnissen während des Dienstupgrades führen, da die Quelldaten möglicherweise nicht weit genug aufbewahrt werden, um die vollständige Fenstergröße einzuschließen.

Im Allgemeinen ist die erforderliche Wiedergabemenge proportional zur Größe des Fensters, multipliziert mit der durchschnittlichen Ereignisrate. Beispielsweise wird bei einem Auftrag mit einer Eingaberate von 1000 Ereignissen pro Sekunde eine Fenstergröße von mehr als einer Stunde als große Wiedergabegröße betrachtet. Bis zu einer Stunde Daten müssen möglicherweise erneut verarbeitet werden, um den Zustand zu initialisieren, sodass vollständige und korrekte Ergebnisse erzeugt werden können. Dies kann zu einer verzögerten Ausgabe oder zu keiner Ausgabe für einen längeren Zeitraum führen. Abfragen ohne Fenster oder andere zeitliche Operatoren, wie JOIN oder LAG, hätten keine Verarbeitung.

Abschätzen der Replay-Nachholzeit

Um die Länge der Verzögerung aufgrund eines Dienstupgrades zu schätzen, können Sie die folgende Technik ausführen:

  1. Laden Sie die Eingabe-Event-Hubs mit ausreichenden Daten, um die größte Fenstergröße in Ihrer Abfrage bei der erwarteten Ereignisrate abzudecken. Der Zeitstempel der Ereignisse sollte sich während dieses Zeitraums in der Nähe der Wanduhrzeit befinden, als ob es sich um einen Live-Eingabefeed handelt. Wenn Sie beispielsweise in Ihrer Abfrage ein 3-tägiges Zeitfenster haben, senden Sie Ereignisse für drei Tage an Event Hubs und setzen das Senden von Ereignissen fort.

  2. Starten Sie den Auftrag mit "Jetzt" als Startzeit.

  3. Messen Sie die Zeit zwischen der Startzeit und dem Zeitpunkt, zu dem die erste Ausgabe generiert wird. Die geschätzte Zeit, die der Auftrag während einer Serviceaktualisierung verzögert würde, ist ungefähr.

  4. Wenn die Verzögerung zu lang ist, versuchen Sie, Ihren Auftrag zu partitionieren und die Anzahl der SUs zu erhöhen, sodass die Last auf mehr Knoten verteilt wird. Alternativ können Sie die Fenstergrößen in Ihrer Abfrage reduzieren und eine weitere Aggregation oder eine andere zustandsbehaftete Verarbeitung für die ausgabe durchführen, die vom Stream Analytics-Auftrag in der Downstream-Spüle erzeugt wird (z. B. mithilfe von Azure SQL-Datenbank).

Für allgemeine Anliegen zur Dienstverfügbarkeit beim Upgrade von geschäftskritischen Aufgaben empfiehlt es sich, duplicate Jobs in gekoppelten Azure-Regionen auszuführen. Weitere Informationen finden Sie unter Garantie der Zuverlässigkeit des Stream Analytics-Auftrags während Dienstupdates.

Wiederherstellung des Jobs von einem vom Benutzer initiierten Stopp und Start

Um die Abfragesyntax für einen Streamingauftrag zu bearbeiten oder Eingaben und Ausgaben anzupassen, muss der Auftrag beendet werden, um die Änderungen vorzunehmen und das Auftragsdesign zu aktualisieren. In solchen Szenarien ähnelt das Wiederherstellungsszenario dem Dienstupgrade, wenn ein Benutzer den Streamingauftrag beendet und erneut startet.

Prüfpunktdaten können nicht für einen vom Benutzer initiierten Auftragsneustart verwendet werden. Um die Verzögerung der Ausgabe während eines solchen Neustarts zu schätzen, verwenden Sie das gleiche Verfahren wie im vorherigen Abschnitt beschrieben und ergreifen Sie ähnliche Maßnahmen, wenn die Verzögerung zu lang ist.

Nächste Schritte

Weitere Informationen zu Zuverlässigkeit und Skalierbarkeit finden Sie in den folgenden Artikeln:

  • Last updated on