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

Azure Stream Analytics verwaltet bei jeder Ausführung eines Jobs intern Zustandsinformationen und speichert diesen Zustand regelmäßig in einem Prüfpunkt. Wenn ein Job fehlschlägt oder aktualisiert wird, kann Stream Analytics den neuesten Checkpoint zur Wiederherstellung verwenden. Wenn der Job den Checkpoint nicht nutzen kann, führt er stattdessen eine Wiederholung durch und verarbeitet die letzten Eingabeereignisse erneut, um seinen Zustand wiederherzustellen.

Dieser Artikel erklärt, wie Checkpoints und Wiederholungen in Azure Stream Analytics funktionieren und wie sie die Zeit beeinflussen, die ein Job zur Erholung benötigt.

Zustandsbehaftete Abfragelogik in temporalen Elementen

Eine der einzigartigen Möglichkeiten eines Azure Stream Analytics-Jobs besteht darin, zustandsbehaftete Verarbeitung durchzuführen, etwa Fensteraggregationen, zeitliche Joins und temporale 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:

  • Fensteraggregate (GROUP BY von rollierenden, springenden und gleitenden Fenstern)
  • Zeitliche Verknüpfungen (JOIN mit DATEDIFF)
  • 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, skaliert der Dienst ihn intern hoch, um die Verarbeitung auf mehrere Workerknoten zu verteilen. Der Service speichert alle paar Minuten den Zustand jedes Worker-Knotens, sodass er sich bei einem Ausfall wiederherstellen kann.

Manchmal kann ein bestimmter Worker-Knoten ausfallen oder ein Betriebssystem-Upgrade für diesen Worker-Knoten erfolgen. Zur automatischen Wiederherstellung stellt Stream Analytics einen neuen funktionsfähigen Knoten bereit und stellt den Zustand des vorherigen Workerknotens anhand des zuletzt verfügbaren Prüfpunktes wieder her. Um die Arbeit fortzusetzen, spielt der Job eine kleine Datenmenge erneut ab, um den Zustand vom letzten Checkpoint wiederherzustellen. In der Regel beträgt die Wiederherstellungslücke nur ein paar Minuten. Wenn du genug Streaming-Einheiten für den Auftrag ausgewählt hast, ist die Wiederholung schnell abgeschlossen.

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 jemals eine erhebliche Verarbeitungsverzögerung aufgrund eines Knotenausfalls und eines Betriebssystem-Upgrades feststellen, sollten Sie die Abfrage vollständig parallel machen und den Job so skalieren, dass mehr Streaming-Einheiten zugeteilt werden. Weitere Informationen finden Sie unter Skalieren eines Azure Stream Analytics-Auftrags, um den Durchsatz zu erhöhen.

Stream Analytics zeigt derzeit keinen Bericht an, wenn ein solcher 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 aktualisiert Microsoft die laufenden Jobs auf eine neuere Version, und der Job startet automatisch neu.

Azure Stream Analytics verwendet Prüfpunkte, sofern möglich, um Daten aus dem letzten prüfpunktierten Zustand wiederherzustellen. Wenn Stream Analytics keine internen Checkpoints verwenden kann, stellt eine Replay-Technik den gesamten Zustand der Streaming-Abfrage wieder her. Damit Stream-Analytics-Jobs exakt dieselbe Eingabe wiederholen können, stellen Sie die Speicherungsrichtlinie für die Quelldaten auf mindestens die Fenstergrößen Ihrer Abfrage ein. Wenn dies nicht gelingt, kann dies zu falschen oder teilweisen Ergebnissen während eines Service-Upgrades führen, da Stream Analytics die Quelldaten möglicherweise nicht weit genug zurücklegt, um die gesamte Fenstergröße einzubeziehen.

Im Allgemeinen ist die erforderliche Wiedergabemenge proportional zur Größe des Fensters, multipliziert mit der durchschnittlichen Ereignisrate. Zum Beispiel hat für einen Job mit einer Eingaberate von 1.000 Ereignissen pro Sekunde eine Fenstergröße von mehr als einer Stunde eine große Wiederholungsgröße. Der Dienst muss möglicherweise bis zu einer Stunde Daten neu verarbeiten, um den Zustand zu initialisieren und vollständige und korrekte Ergebnisse zu liefern, was zu einer verzögerten Ausgabe (keine Ausgabe) über längere Zeit führen kann. Abfragen ohne Fenster oder andere temporale Operatoren, wie JOIN oder LAG, haben keine Wiederholung.

Abschätzen der Replay-Nachholzeit

Um die Länge der Verzögerung durch ein Service-Upgrade abzuschätzen, folgen Sie folgender Technik:

  • Laden Sie den Input-Event Hub mit genügend Daten, um die größte Fenstergröße Ihrer Abfrage bei der erwarteten Ereignisrate abzudecken. Die Zeitstempel der Ereignisse sollten über den gesamten Zeitraum hinweg nahe bei der tatsächlichen Uhrzeit liegen, als kämen sie aus einem Live-Datenstrom. Wenn Sie zum Beispiel ein dreitägiges Zeitfenster in Ihrer Anfrage haben, senden Sie Ereignisse für drei Tage an den Event Hub und senden Sie weiterhin Ereignisse.
  • Starte den Job mit Now als Startzeit.
  • Miss die Zeit zwischen der Startzeit und dem Zeitpunkt, an dem der Job seine erste Ausgabe erzeugt. Diese Zeit entspricht ungefähr der Verzögerung, die der Auftrag während eines Service-Upgrades verursacht.
  • Wenn die Verzögerung zu lang ist, versuche, deinen Job zu partitionieren und die Anzahl der Streaming-Einheiten zu erhöhen, sodass die Last sich auf mehr Knoten verteilt. Alternativ erwägen Sie, die Fenstergrößen Ihrer Abfrage zu reduzieren und weitere Aggregation oder andere zustandsbehaftete Verarbeitung der Ausgabe durchzuführen, die der Stream Analytics-Job im Downstream-Sink erzeugt (zum Beispiel durch die Verwendung 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.

Job-Wiederherstellung durch einen von den Nutzern initiierten Stopp und Start

Um die Abfragesyntax eines Streaming-Jobs zu bearbeiten oder Eingaben und Ausgaben anzupassen, muss man den Job stoppen, um die Änderungen vorzunehmen und das Jobdesign zu aktualisieren. In solchen Szenarien, wenn man den Streaming-Auftrag stoppt und wieder startet, ähnelt das Wiederherstellungsszenario einem Dienst-Upgrade.

Ein vom Benutzer initiierter Job-Neustart kann keine Checkpoint-Daten verwenden. Um die Verzögerung der Ausgabe während eines solchen Neustarts zu schätzen, verwenden Sie das gleiche Verfahren wie im vorherigen Abschnitt beschriebenen Verfahren und wenden eine ähnliche Minderung an, wenn die Verzögerung zu lang ist.

Verwandte Inhalte

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

  • Last updated on