Grundlegendes zum Zeitmanagement in Azure Stream Analytics

Die Zeitbehandlung in Azure Stream Analytics ist der Satz von Mechanismen, die bestimmen, wie Streamingereignisse zeitstempelt, sortiert und verarbeitet werden, basierend auf dem Zeitpunkt, an dem sie aufgetreten sind, im Vergleich zu dem Zeitpunkt, an dem sie eintreffen. In diesem Artikel wird erläutert, wie Sie Designentscheidungen treffen, um praktische Probleme mit der Zeitbehandlung in Azure Stream Analytics-Aufträgen zu lösen. Die Entwurfsentscheidungen für die Behandlung von Zeitangaben stehen in engem Zusammenhang mit den Faktoren der Ereignisreihenfolge.

Zeitkonzepte im Hintergrund

Um die Diskussion besser zu gestalten, lassen Sie uns einige Hintergrundkonzepte definieren:

• Ereigniszeit: Der Zeitpunkt, zu dem das ursprüngliche Ereignis eintritt. Zum Beispiel, wenn sich ein fahrendes Auto auf der Autobahn einem Mauthäuschen nähert.

• Verarbeitungszeit: Der Zeitpunkt, an dem das Ereignis das Verarbeitungssystem erreicht und beobachtet wird. Zum Beispiel, wenn der Sensor im Mauthäuschen das Auto erkennt und das Computersystem einen Moment benötigt, um die Daten zu verarbeiten.

• Wasserzeichen: Eine Ereigniszeitmarkierung, die anzeigt, bis zu welchem Punkt der Streaming-Prozessor Ereignisse verarbeitet hat. Mit Hilfe von Wasserzeichen kann das System den Fortschritt beim klaren Erfassen der Ereignisse anzeigen. Aufgrund der Art der Streams hören die eingehenden Ereignisdaten nie auf, sodass Wasserzeichen den Fortschritt bis zu einem bestimmten Punkt im Stream anzeigen.

  Das Wasserzeichenkonzept ist wichtig. Mit Wasserzeichen kann Azure Stream Analytics ermitteln, wann das System vollständige, korrekte und wiederholbare Ergebnisse erzeugen kann, die nicht zurückgezogen werden müssen. Die Verarbeitung kann auf vorhersehbare und wiederholbare Weise erfolgen. Wenn zum Beispiel eine Neuberechnung für eine Fehlerbehandlung durchgeführt werden muss, sind Wasserzeichen sichere Start- und Endpunkte.

Zusätzliche Ressourcen zu diesem Thema finden Sie in den Blogbeiträgen von Tyler Akidau Streaming 101 und Streaming 102.

Auswählen der besten Startzeit

Azure Stream Analytics bietet Ihnen zwei Optionen für die Auswahl von Ereigniszeit: Ankunftszeit und Anwendungszeit.

Eingangszeit

Die Ankunftszeit wird von der Eingabequelle zugewiesen, wenn das Ereignis die Quelle erreicht. Auf die Eingangszeit kann bei Event Hubs-Eingaben mithilfe der EventEnqueuedUtcTime-Eigenschaft, bei IoT Hub-Eingaben mit der Eigenschaft IoTHub.EnqueuedTime und bei Blobeingaben mithilfe der BlobProperties.LastModified-Eigenschaft zugegriffen werden.

Die Eingangszeit wird standardmäßig verwendet und eignet sich am besten für Datenarchivierungsszenarien, bei denen keine Zeitlogik erforderlich ist.

Anwendungszeit (auch als Ereigniszeit bezeichnet)

Die Anwendungszeit wird bei Erstellung des Ereignisses zugewiesen und ist Teil der Ereignisnutzlast. Verwenden Sie zur Verarbeitung von Ereignissen anhand der Anwendungszeit die Timestamp by-Klausel in der SELECT-Abfrage. Wenn Timestamp by nicht vorhanden ist, werden Ereignisse basierend auf der Eingangszeit verarbeitet.

Es ist wichtig, einen Zeitstempel in der Nutzlast zu verwenden, wenn Zeitlogik eine Rolle spielt, um Verzögerungen im Quellsystem oder im Netzwerk zu berücksichtigen. Die Zeit, die einem Ereignis zugeordnet ist steht in SYSTEM.TIMESTAMP zur Verfügung.

Zeitverlauf in Azure Stream Analytics

Wenn Sie Anwendungszeit verwenden, basiert der Zeitverlauf auf den eingehenden Ereignissen. Es ist für das Streamverarbeitungssystem schwierig einzuschätzen, ob es gerade keine Ereignisse gibt oder ob sich Ereignisse verzögern. Aus diesem Grund erzeugt Azure Stream Analytics für jede Eingangspartition heuristische Wasserzeichen auf folgende Weise:

• Wenn ein eingehendes Ereignis vorhanden ist, ist das Wasserzeichen die größte Ereigniszeit, zu der Azure Stream Analytics bisher abzüglich der Fenstergröße der nicht ordnungsgemäßen Toleranz angezeigt wurde.

• Wenn es kein eingehendes Ereignis gibt, ist das Wasserzeichen die aktuelle geschätzte Ankunftszeit abzüglich des Toleranzfensters für verspätete Ankunft. Die geschätzte Ankunftszeit ist die Zeit, die seit dem letzten Mal verstrichen ist, als ein Eingabeereignis gesehen wurde, zuzüglich der Ankunftszeit dieses Eingabeereignisses.

  Die Ankunftszeit kann nur geschätzt werden, weil die Echtzeit-Ankunftszeit auf dem Eingabeereignisbroker (z. B. Event Hubs oder IoT Hub) generiert wird, nicht auf der Azure Stream Analytics-VM, die die Ereignisse verarbeitet.

Der Entwurf dient außer der Generierung von Wasserzeichen zwei weiteren Zwecken:

1. Das System erzeugt zeitnah Ergebnisse mit oder ohne eingehende Ereignisse.

   Sie können selbst steuern, wie zeitnah Sie die Ausgabeergebnisse sehen möchten. Im Azure-Portal können Sie auf der Seite Ereignisreihenfolge Ihres Stream Analytics-Auftrags die Einstellung Ungeordnete Ereignisse konfigurieren. Bei der Konfiguration dieser Einstellung ist der Kompromiss zwischen Aktualität und Toleranz gegenüber Ereignissen mit falscher Reihenfolge im Ereignisstrom zu berücksichtigen.

   Das Verzögerungstoleranzfenster ist erforderlich, um selbst bei fehlenden eingehenden Ereignissen kontinuierlich Wasserzeichen zu generieren. Manchmal kann es einen Zeitraum geben, in dem keine eingehenden Ereignisse eintreffen, etwa wenn ein Ereigniseingabestream eine geringe Dichte hat. Dieses Problem wird durch die Verwendung mehrerer Partitionen im Eingangsereignis-Broker noch verschärft.

   Bei Streaming-Datenverarbeitungssystemen ohne ein Toleranzfenster für Eingangsverzögerung kann es zu Verzögerungen bei der Ausgabe kommen, wenn die Eingabe eine geringe Dichte hat und mehrere Partitionen verwendet werden.

2. Das Verhalten des Systems muss wiederholbar sein. Wiederholbarkeit ist eine wichtige Eigenschaft von Verarbeitungssystemen für Streamingdaten.

   Das Wasserzeichen wird von der Eingangszeit und Anwendungszeit abgeleitet. Beide bleiben somit im Event-Broker vorhanden und sind wiederholbar. Wenn eine Eingangszeit bei Abwesenheit von Ereignissen geschätzt wird, protokolliert Azure Stream Analytics die geschätzte Eingangszeit zwecks Wiederholbarkeit bei der Wiedergabe zur Fehlerbehebung.

Wenn Sie sich entscheiden, die Ankunftszeit als Ereigniszeit zu verwenden, müssen Sie die Toleranz außerhalb der Reihenfolge und die Spätankunftstoleranz nicht konfigurieren. Da die Ankunftszeit im Eingabeereignisbroker garantiert steigt, ignoriert Azure Stream Analytics die Konfigurationen.

Spät eintreffende Ereignisse

Gemäß der Definition des Toleranzfenster für Eingangsverzögerung vergleicht Azure Stream Analytics für jedes eingehende Ereignis die Ereigniszeit mit der Eingangszeit. Wenn sich die Ereigniszeit außerhalb des Toleranzfensters befindet, können Sie das System so konfigurieren, dass das Ereignis abzulegen oder die Zeit des Ereignisses an die Toleranz angepasst wird.

Sobald Wasserzeichen generiert werden, kann der Dienst möglicherweise Ereignisse empfangen, deren Ereigniszeit niedriger ist als das Wasserzeichen. Sie können den Dienst so konfigurieren, dass diese Ereignisse entweder gelöscht werden, oder dass die Ereigniszeit an den Wasserzeichenwert angepasst wird.

Als Teil der Anpassung wird der System.Timestamp des Ereignisses auf den neuen Wert gesetzt, aber das Feld Ereigniszeit selbst wird nicht geändert. Diese Anpassung ist die einzige Situation, in welcher System.Timestamp für ein Ereignis vom Wert im Feld „Ereigniszeit“ abweichen kann, und es könnten unerwartete Ergebnisse generiert werden.

Behandlung von Zeitabweichungen mit untergeordneten Datenströmen

Der heuristische Wasserzeichengenerierungsmechanismus – bei dem Azure Stream Analytics den Ereigniszeitfortschritt mithilfe des größten beobachteten Zeitstempels abzüglich des Toleranzfensters verfolgt – funktioniert in den meisten Fällen gut, in denen die Zeit hauptsächlich zwischen den verschiedenen Ereignissendern synchronisiert wird. In der Praxis, insbesondere in vielen IoT-Szenarien, hat das System jedoch wenig Kontrolle über die Uhr auf den Ereignissendern. Die Ereignis-Absender könnten alle Arten von IoT-Geräten im Feld sein, vielleicht auf verschiedenen Versionen von Gerätehardware und Firmware.

Anstatt ein Wasserzeichen zu verwenden, das global für alle Ereignisse in einer Eingabepartition ist, verfügt Azure Stream Analytics über einen anderen Mechanismus, der als Teilstreams bezeichnet wird. Sie können Unterstreams in Ihrem Auftrag verwenden, indem Sie eine Auftragsabfrage schreiben, die die TIMESTAMP BY-Klausel und das Schlüsselwort OVER verwendet. Um einen untergeordneten Datenstrom festzulegen, geben Sie den Namen der Schlüsselspalte nach dem Schlüsselwort OVER ein, wie z.B. deviceid, sodass das System Zeitrichtlinien gemäß dieser Spalte anwendet. Jeder Substrom erhält jeweils sein eigenes unabhängiges Wasserzeichen. Dieser Mechanismus ist nützlich, um eine zeitnahe Ausgabe zu ermöglichen, wenn große Uhrabweichungen oder Netzwerkverzögerungen zwischen Ereignissendern vorliegen.

Wenn Sie Unterstreams verwenden, wendet Azure Stream Analytics das Toleranzfenster für verspätete Ankunft auf eingehende Ereignisse an. Die Toleranz für Eingangsverzögerung bestimmt den maximalen Betrag, um den verschiedene untergeordnete Datenströme voneinander abweichen können. Wenn sich z. B. "Gerät 1" bei "Zeitstempel 1" und "Gerät 2" bei "Zeitstempel 2" befindet, lautet die maximale Toleranz für späte Ankunft "Zeitstempel 2" minus "Zeitstempel 1". Die Standardmäßige Einstellung für die Spätankunftstoleranz beträgt 5 Sekunden, was für IoT-Geräte mit unterschiedlichen Zeitstempeln wahrscheinlich zu klein ist. Beginnen Sie mit 5 Minuten und nehmen Sie Anpassungen gemäß der Uhrabweichung Ihres Geräts vor.

Früh eingetroffene Ereignisse

Das Fenster für frühe Ankunft ist eine feste Toleranz von 5 Minuten, die bestimmt, wie früh ein Ereignis relativ zur Ereigniszeit eingehen kann, bevor Azure Stream Analytics es abbricht. Dieses Fenster dient einem anderen Zweck als das Toleranzfenster für späte Ankunft.

Da Azure Stream Analytics stets vollständige Ergebnisse garantiert, können Sie als erste Ausgabezeit des Auftrags nur die Auftragsstartzeit angeben, nicht die Eingangszeit. Die Startzeit des Auftrags ist erforderlich, damit das System das vollständige Fenster verarbeitet, nicht nur von der Mitte des Fensters.

Azure Stream Analytics leitet die Startzeit aus der Abfragespezifikation ab. Da der Eingangsereignis-Broker jedoch nur nach Eingangszeit indiziert wird, muss das System die Startzeit des Ereignisses in die Eingangszeit umrechnen. Das System kann die Verarbeitung von Ereignissen ab dieser Stelle im Eingangsereignis-Broker starten. Beim Grenzwert für das frühzeitige Eintreffen ist die Umrechnung ganz einfach: Startzeit des Ereignisses abzüglich des 5-Minuten-Fensters für das frühzeitige Eintreffen. Diese Berechnung bedeutet auch, dass das System alle Ereignisse löscht, deren Ereigniszeit 5 Minuten vor der Eingangszeit liegt. Die Metrik für frühe Eingabeereignisse wird inkrementiert, wenn die Ereignisse gelöscht werden.

Dieses Konzept stellt sicher, dass die Verarbeitung wiederholbar ist, unabhängig davon, wo Sie mit der Ausgabe beginnen. Ohne einen solchen Mechanismus wäre es nicht möglich, die Wiederholbarkeit zu gewährleisten, die viele andere Streamingsysteme für sich in Anspruch nehmen.

Nebeneffekte der Zeittoleranzen für die Ereignissortierung

Azure Stream Analytics-Aufträge verfügen über mehrere Optionen für die Ereignisbestellung . Zwei können im Azure-Portal konfiguriert werden: die Einstellung Ereignisse mit falscher Reihenfolge (Toleranz für Ereignisse mit falscher Reihenfolge) und die Einstellung Spät empfangene Ereignisse (Toleranz für Eingangsverzögerung). Die Toleranz für den frühzeitigen Eingang ist fixiert und kann nicht angepasst werden. Azure Stream Analytics verwendet diese Zeitrichtlinien, um starke Garantien bereitzustellen. Diese Einstellungen haben jedoch einige manchmal unerwartete Auswirkungen:

1. Versehentliches Senden von zu frühen Ereignissen.

   Frühe Ereignisse sollten normalerweise nicht ausgegeben werden. Es ist möglich, dass frühe Ereignisse an die Ausgabe gesendet werden, wenn die Uhr des Absenders zu schnell läuft. Alle frühzeitig eingehenden Ereignisse werden verworfen, daher werden sie nicht in der Ausgabe angezeigt.

2. Senden alter Ereignisse an Event Hubs zur Verarbeitung durch Azure Stream Analytics.

   Obwohl alte Ereignisse zunächst harmlos erscheinen könnten, kann es aufgrund der Anwendung der Spätankunftstoleranz dazu kommen, dass die alten Ereignisse verworfen werden. Wenn die Ereignisse zu alt sind, wird der Wert System.Timestamp während der Ereigniserfassung geändert. Aufgrund dieses Verhaltens eignet sich Azure Stream Analytics besser für Nahezu-Echtzeit-Ereignisverarbeitungsszenarien als für historische Ereignisverarbeitungsszenarien. Sie können die Zeit für Spät empfangene Ereignisse auf den größtmöglichen Wert (20 Tage) einstellen, um dieses Verhalten in einigen Fällen zu umgehen.

3. Ausgaben scheinen verzögert zu sein.

   Das erste Wasserzeichen wird zu der berechneten Zeit generiert: die maximale Ereigniszeit, die das System bisher beobachtet hat, abzüglich der Größe des Toleranzfensters für Ereignisse mit falscher Reihenfolge. Standardmäßig ist die Toleranz für Ereignisse mit falscher Reihenfolge auf Null (00 Minuten und 00 Sekunden) konfiguriert. Wenn Sie den Wert auf einen höheren Zeitwert als Null einstellen, wird die erste Ausgabe des Streamingauftrags aufgrund der berechneten ersten Wasserzeichenzeit um diesen Zeitwert (oder mehr) verzögert.

4. Eingaben sind spärlich.

   Wenn es in einer bestimmten Partition keine Eingabe gibt, wird die Wasserzeichenzeit als Eingangszeit minus dem Toleranzfenster für Eingangsverzögerung berechnet. Infolgedessen kann die Ausgabe bei seltenen Eingangsereignissen und Eingangsereignissen mit geringer Dichte um diese Zeitspanne verzögert werden. Der Standardwert für Spät empfangene Ereignisse beträgt 5 Sekunden. Sie sollten mit einer gewissen Verzögerung rechnen, wenn Sie z.B. Eingangsereignisse einzeln senden. Die Verzögerungen können länger werden, wenn Sie für das Fenster Spät empfangene Ereignisse einen zu großen Wert festlegen.

5. Der Wert für System.Timestamp unterscheidet sich von der Zeit im Feld Ereigniszeit.

   Wie bereits beschrieben, passt das System die Ereigniszeit um das Toleranzfenster für Ereignisse mit falscher Reihenfolge oder für Eingangsverzögerung an. Der System.Timestamp-Wert des Ereignisses wird angepasst, das Ereigniszeitfeld wird jedoch nicht angepasst. Sie können dies verwenden, um zu ermitteln, für welche Ereignisse die Zeitstempel angepasst wurden. Wenn das System den Zeitstempel aufgrund einer der Toleranzen ändert, sind sie normalerweise identisch.

Zu überwachende Metriken

Sie können eine Reihe von Auswirkungen der Zeittoleranzen bei der Ereignisreihenfolge anhand der Azure Stream Analytics-Auftragsmetriken beobachten. Die folgenden Metriken sind relevant:

Details zur Wasserzeichenverzögerung

Azure Stream Analytics berechnet die Wasserzeichenverzögerungsmetrik als Wanduhrzeit des Verarbeitungsknotens abzüglich des bisher größten Wasserzeichens. Weitere Informationen finden Sie unter Wasserzeichenverzögerung.

Es kann mehrere Gründe geben, warum dieser metrische Wert im Normalbetrieb größer als 0 ist:

1. Eigene Verarbeitungsverzögerung der Streamingpipeline. Diese Verzögerung ist in der Regel nominal.

2. Das Toleranzfenster für Ereignisse mit falscher Reihenfolge führte zu einer Verzögerung, da das Wasserzeichen um die Größe des Toleranzfensters reduziert wird.

3. Das verspätete Ankunftsfenster verursachte eine Verzögerung, da das Wasserzeichen um die Größe des Toleranzfensters reduziert wird.

4. Uhrzeitabweichung des Verarbeitungsknotens, der die Metrik erzeugt.

Es gibt mehrere andere Ressourceneinschränkungen, die dazu führen können, dass die Streamingpipeline verlangsamt wird. Die Metrik der Wasserzeichenverzögerung kann aus folgenden Gründen ansteigen:

1. Nicht genügend Verarbeitungsressourcen in Azure Stream Analytics, um das Volumen von Eingabeereignissen zu verarbeiten. Informationen zum Hochskalieren von Ressourcen finden Sie unter Verstehen und Anpassen von Streamingeinheiten.

2. Nicht genügend Durchsatz bei den Ereignis-Eingabe-Brokern, sodass diese gedrosselt werden. Mögliche Lösungen finden Sie in Automatisches Hochskalieren der Azure Event Hub-Durchsatzeinheiten.

3. Ausgabesenken (z. B. Azure SQL-Datenbank, Blob-Speicher oder Power BI) sind nicht mit ausreichender Kapazität ausgestattet, sodass sie gedrosselt werden. Die möglichen Lösungen weisen große Unterschiede je nach dem genutzten Ausgabedienst auf.

Ausgabeereignisfrequenz

Azure Stream Analytics verwendet den Fortschritt des Wasserzeichens als einzigen Auslöser, um Ausgabeereignisse zu erzeugen. Da das Wasserzeichen von Eingabedaten abgeleitet wird, ist es während der Fehlerwiederherstellung und auch bei der vom Benutzer initiierten Neuverarbeitung wiederholbar. Bei Verwendung von Aggregaten im Fenstermodus erzeugt der Dienst nur dann Ausgaben am Ende der Fenster. In einigen Fällen möchten Sie möglicherweise partielle Aggregate anzeigen, die aus den Fenstern generiert wurden. Partielle Aggregate werden derzeit in Azure Stream Analytics nicht unterstützt.

In anderen Streaminglösungen können Ausgabeereignisse je nach externen Umständen an verschiedenen Triggerpunkten materialisiert werden. Es ist in einigen Lösungen möglich, dass die Ausgabeereignisse für ein bestimmtes Zeitfenster mehrmals generiert werden können. Mit der Optimierung der Eingabewerte werden die Gesamtergebnisse genauer. Ereignisse können zuerst spekuliert und im Laufe der Zeit überarbeitet werden. Wenn beispielsweise ein bestimmtes Gerät nicht mit dem Netzwerk verbunden ist, kann das System einen Schätzwert verwenden. Zu einem späteren Zeitpunkt verbindet sich das Gerät wieder mit dem Netzwerk. Dann können die tatsächlichen Ereignisdaten in den Eingabestream enthalten sein. Die Ergebnisse aus der Verarbeitung dieses Zeitfensters führen zu einer genaueren Ausgabe.

Illustriertes Beispiel für Wasserzeichen

Die folgenden Bilder zeigen, wie sich Wasserzeichen unter verschiedenen Umständen entwickeln.

Diese Tabelle zeigt die Beispieldaten, die im Folgenden dargestellt werden. Beachten Sie, dass die Ereigniszeit und die Eingangszeit variieren, manchmal übereinstimmen und manchmal nicht.

In dieser Illustration werden die folgenden Toleranzen verwendet:

• Das frühe Ankunftszeitfenster beträgt 5 Minuten
• Das Zeitfenster für verspätete Ankunft beträgt 5 Minuten.
• Das Fenster für die Neusortierung beträgt 2 Minuten.

1. Illustration des Fortschritts des Wasserzeichens durch diese Ereignisse:

   

   Beachtenswerte Prozesse, die in der vorhergehenden Grafik dargestellt sind:

   1. Beim ersten Ereignis (device1) und dem zweiten Ereignis (device2) sind die Zeiten ausgerichtet und die Ereignisse werden ohne Anpassungen verarbeitet. Das Wasserzeichen schreitet bei jedem Ereignis voran.

   2. Wenn das dritte Ereignis (device1) verarbeitet wird, liegt die Eingangszeit (12:11) vor der Ereigniszeit (12:17). Das Ereignis kam 6 Minuten früher an und wird daher aufgrund der 5-minütigen Toleranz für frühzeitiges Eintreffen gelöscht.

      Wenn das Ereignis früh eintritt, schreitet das Wasserzeichen nicht fort.

   3. Beim vierten Ereignis (device3) und dem fünften Ereignis (device1) sind die Zeiten ausgerichtet und die Ereignisse werden ohne Anpassungen verarbeitet. Das Wasserzeichen schreitet bei jedem Ereignis voran.

   4. Wenn das sechste Ereignis (Gerät3) verarbeitet wird, liegen die Ankunftszeit (12:17) und die Ereigniszeit (12:12) unter dem Wasserzeichenniveau. Die Zeit des Ereignisses wird auf das Wasserzeichenniveau (12:17) angepasst.

   5. Wenn das zwölfte Ereignis (device3) verarbeitet wird, liegen die Eingangszeit (12:27) und die Ereigniszeit (12:21) sechs Minuten auseinander. Die Verspätungsrichtlinie wird angewendet. Die Ereigniszeit wird angepasst (12:22). Dies liegt über dem Wasserzeichen (12:21), sodass keine weiteren Anpassungen angewendet werden.

2. Zweite Darstellung des Wasserzeichen-Fortschritts ohne Richtlinie für frühzeitige Ankunft.

   

   In diesem Beispiel wird keine Richtlinie für den frühen Eingang angewendet. Ausreißerereignisse, die verfrüht eintreffen, heben das Wasserzeichen deutlich an. Beachten Sie, dass das dritte Ereignis (deviceId1 zum Zeitpunkt 12:11) in diesem Szenario nicht verworfen wird, und das Wasserzeichen wird auf 12:15 erhöht. Die Zeit des vierten Ereignisses wird daher 7 Minuten vorverlegt (von 12:08 auf 12:15).

3. In der endgültigen Illustration werden Substreams (über die DeviceID) verwendet. Es werden mehrere Wasserzeichen nachverfolgt, eines pro Datenstrom. Es gibt weniger Ereignisse, bei denen die Zeiten entsprechend angepasst werden.

   

Nächste Schritte

• Überlegungen zur Ereignisreihenfolge in Azure Stream Analytics
• Azure Stream Analytics-Auftragsmetriken