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. In anderen Fällen kann der Prüfpunkt nicht für die Wiederherstellung verwendet werden, sodass eine Wiedergabe erforderlich ist.

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 von rollierenden, springenden und gleitenden Fenstern)

  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. Für den Zustand der einzelnen Workerknoten wird alle paar Minuten ein Prüfpunkt erstellt, was eine Systemwiederherstellung nach einem Ausfall vereinfacht.

In einigen Fällen tritt bei einem bestimmten Workerknoten möglicherweise ein Fehler auf oder ein Betriebssystemupgrade für diesen Workerknoten kann stattfinden. Für die automatische Wiederherstellung erhält Stream Analytics einen neuen fehlerfreien Knoten, und der vorherige Zustand des Workerknotens seit dem letzten verfügbaren Prüfpunkt wird wiederhergestellt. Um fortzufahren, ist eine kleine Wiedergabemenge erforderlich, um den Zustand ab dem Zeitpunkt der Prüfpunkterstellung wiederherzustellen. 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 verhält sich der Zeitaufwand nach einem Ausfall des Workerknotens proportional zu Folgendem:

[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. Beispiel: Bei einem Auftrag mit einer Eingangsrate von 1000 Ereignissen pro Sekunde gilt eine Fenstergröße von mehr als einer Stunde als große Wiedergabegröße. 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 temporale Operatoren, wie JOIN oder LAG würden eine Wiedergabemenge von 0 haben.

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. Der Zeitraum ist ein ungefährer Schätzwert dafür, wie lang die Verzögerung bei einem Auftrag im Falle eines Dienstupgrades wäre.

  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 verkürzen und weitere Aggregationen oder andere zustandsbehaftete Verarbeitungen für die Ausgabe ausführen, die vom Stream Analytics-Auftrag in der Downstreamsenke (z. B. mithilfe von Azure SQL-Datenbank) erzeugt werden.

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.

Auftragswiederherstellung bei einem vom Benutzer initiierten Vorgang zum Beenden und Starten

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