Latenz im Activator

Der Fabric Activator wendet Regeln auf Echtzeitdaten an. Die Ergebnisse sind fast sofort, aber verschiedene Faktoren können Latenzen einführen. In den meisten Fällen bemerken Sie diese Latenz nicht, aber in einigen Fällen kann es bis zu 10 Minuten dauern. Das Empfangen von genauen und zeitnahen Informationen ist ein wichtiger Aspekt beim Erstellen und Empfangen von Regeln. In diesem Artikel werden die Prozesse und Einstellungen überprüft, die das Gleichgewicht zwischen der Einbindung von Ereignissen und der Regelstruktur bestimmen und wie schnell aktivator eine Aktivierung sendet. Soll der Aktivator beispielsweise zulassen, dass mehr Daten eintreffen und einbezogen werden, oder sollte der Aktivator sicherstellen, dass die Empfänger ihre Benachrichtigungen zu einem festgelegten Zeitpunkt erhalten? Und wie wirkt sich die Regelstruktur auf die Geschwindigkeit aus, mit der der Aktivator eine Aktivierung an Empfänger sendet?

Drei wichtige Faktoren wirken sich auf die Latenz der Regelaktivierung aus:

  • Toleranz bei verspäteter Ankunft.
  • Back-End-Verarbeitungslatenz.
  • Aggregationslatenz.

Toleranz für Eingangsverzögerung

Im Streaming von Daten können Ereignisse nicht immer in Reihenfolge oder rechtzeitig eintreffen. Die Ereigniszeit eines Ereignisses (wenn es passiert ist) kann innerhalb des Zeitfensters einer Regel liegen, aber seine Ankunftszeit (wenn der Aktivator es empfangen hat) kann außerhalb dieses Fensters fallen – wodurch das Ereignis verspätet wird. Standardmäßig verwirft Activator verspätete Ereignisse bei der Regelauswertung.

Die Wartezeit für spät ankommende Ereignisse steuert, wie lange der Aktivator wartet, bevor das Auswertungsfenster geschlossen wird, sodass verspätete Ereignisse eingetroffen werden können. Diese Einstellung befindet sich im Abschnitt "Erweiterte Einstellungen " des Bildschirms " Regeldefinition ". Informationen zum Konfigurieren finden Sie in der Einstellung für die Toleranz für verspätete Ankunft.

Back-End-Verarbeitungslatenz

Aktivator muss möglicherweise eine Regel verarbeiten, bevor sie aktiviert wird, was zu einer Verzögerung von bis zu einer Minute führen kann. Wenn die Regel z. B. mit einer vorherigen Ereignisgruppe verglichen wird, ruft Aktivator die vorherigen Daten ab, macht den Vergleich und berechnet das Ergebnis. Ein weiteres Beispiel: Wenn die Regel für 10 Millionen Datenzeilen ausgeführt wird, führt auch die Verarbeitung dieses Datenvolumens durch Activator zu Latenzzeiten.

Aggregationslatenz

Wenn eine Aggregation in der Regeldefinition verwendet wird, wird die Regel nur aktiviert, wenn sie die angegebenen Zeitfenster abgeschlossen hat. Angenommen, es wird eine Regel erstellt, um die Daten über vier Stunden zu mittelieren. Wenn ein Ereignis, das die Regelbedingungen erfüllt, um 12:00 Uhr aufgenommen wird, löst die Regel um 14:00 Uhr aus. Die Latenz ist das Ergebnis der Aggregationseinstellungen. Auch wenn eine Regel eine einfache Aggregation enthält, wie z. B. den Mittelwert, kann Activator erst dann eine Aktivierung senden, wenn Activator die Aggregation über die eingehenden Ereignisdaten hinweg ausführt.

Zeitkonzepte im Hintergrund

Um die Diskussion besser zu gestalten, definieren wir einige Hintergrundzeitkonzepte.

  • Ereigniszeit: Der Zeitpunkt, an dem das ursprüngliche Ereignis aufgetreten ist. Sie ist Teil der Ereignisnutzlast. Beispielsweise ist der Moment, in dem ein Sensor ein Auto erkennt, das sich einem Mautstand nähert, die Ereigniszeit.
  • Verarbeitungszeit: Die Uhrzeit, zu der das Verarbeitungssystem das Ereignis empfängt und beobachtet. Zum Beispiel, nachdem der Mautstandsensor das Auto sieht, ist die Zeit, zu der das Computersystem die Informationen des Sensors empfängt und verarbeitet, die Verarbeitungszeit.
  • Ankunftszeit (Wasserzeichen oder Aufnahmezeit): Eine Markierung, die angibt, wann die Ereignisdaten den Activator erreichen. Durch die Art der Datenströme werden die eingehenden Ereignisdaten nie angehalten, sodass die Ankunftszeiten den Fortschritt angeben, den der Activator zu einem bestimmten Punkt im Datenstrom gemacht hat. An diesem Punkt kann Activator vollständige, korrekte und wiederholbare Ergebnisse erzeugen, die nicht zurückgezogen werden müssen. Und an diesem Punkt kann Activator mit der Verarbeitung der Daten beginnen. Aktivator verarbeitet Daten vorhersehbar und wiederholbar. Wenn der Aktivator z. B. Daten für die Fehlerbehandlung zurückzählen muss, kann er die Ankunftszeiten als sichere Ausgangspunkte und Endpunkte verwenden. Sobald das Mautstationssystem beispielsweise alle Autoerkennungen bis 9:05 Uhr erhalten hat, bewegt sich fort die Ankunftszeitmarkierung auf 9:05 Uhr. Alle Erkennungen, die nach diesem Punkt eintreffen – auch wenn ihre Ereigniszeit vor 9:05 Uhr war – sind verspätet.

Verspätete Ankunft tritt auf, wenn eine Regel einen Zeitparameter hat und die Ereigniszeit innerhalb dieses Zeitparameters liegt, aber die Ankunftszeit fällt außerhalb dieses Parameters. Mithilfe des Mautstandsbeispiels erkennt der Sensor das Auto und die Ereigniszeit befindet sich innerhalb des Zeitfensters der Regel. Wenn der Sensor jedoch zu lange braucht, um die Erkennung zu übertragen — zum Beispiel aufgrund von Netzwerküberlastung — gelangt das Ereignis erst nach dem Schließen des Zeitfensters zum Aktivator. Aktivator hält das Ereignis für spät. Wenn Verspätete Ankunftstermine eingeschlossen werden sollen, legen Sie die Wartezeit für spät ankommende Ereignisse in den erweiterten Einstellungen fest.

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

Toleranzeinstellung für späte Ankunft

Sie können die Toleranzeinstellung für verspätete Ankunft konfigurieren. Der Standardwert beträgt zwei Minuten. Diese Einstellung trägt zur Latenz bei. Regeln, die Sie mit einer Wartezeit erstellen, weisen eine minimale Latenz auf, die der konfigurierten Dauer entspricht. Entscheiden Sie beim Erstellen einer Regel, ob Sie die Standardeinstellung verwenden oder ändern möchten. Die Einstellung stellt sicher, dass späte Ereignisse und Ereignisse außerhalb der Reihenfolge die Möglichkeit haben, in die Regelauswertung eingeschlossen zu werden. Wenn ein Ereignis außerhalb der konfigurierten Toleranz für verspätete Ankunft liegt, berücksichtigt der Aktivator es nicht. Alle Ereignisse mit einer Ankunftszeit nach dieser Schwelle werden nicht berücksichtigt.

Screenshot des Bildschirms

Überlegen Sie insgesamt, ob es wichtiger ist, folgendes zu beachten:

  • Warten auf die verspäteten Datenpunkte, oder
  • Führen Sie die Regel für potenziell unvollständige Daten aus, sodass die Regel früher aktiviert wird. 

In diesem Beispiel werden Datenpunkte in Schritten von 15 Minuten gemessen. Die ersten drei Punkte, die blau sind, schaffen es ins Zeitfenster. Der vierte Punkt, der orange ist, tut es nicht. Die Ereigniszeit liegt innerhalb des 15-Minuten-Intervalls, aber das Ereignis wird nicht vom Activator innerhalb des 15-Minuten-Intervalls aufgenommen. Activator wertet die Regel nur über Daten mit einer Eingangszeit innerhalb eines 15-Minuten-Zeitfensters aus. Sofern Sie die Toleranz für die späte Ankunft nicht erhöhen, werden datenpunkte, die nach dem Schließen des Fensters eingehen, nicht einbezogen.

Screenshot eines Liniendiagramms, das Zeitintervalle anzeigt.

Der Aktivator kann Verzögerungen aus Ihren Datenquellen nicht berücksichtigen. Sie können beispielsweise IoT-Sensoren haben, die für eine Stunde offline sind. Sobald sie wieder online sind, kann Activator die Daten empfangen, allerdings wurden die Daten aufgrund dieses Offlinestatus um eine Stunde verzögert, was außerhalb von Activator stattfindet.

Hier sehen Sie ein weiteres Beispiel.

Sie erstellen eine Regel, die die Durchschnittliche Temperatur in Minutenintervallen berechnet. Die Wartezeit für Spätantreffende Ereignisse wird auf die Standardeinstellung von zwei Minuten festgelegt. Aktivator enthält Temperaturwerte 20 und 30 und berechnet einen Mittelwert von 25. Aktivierer schließt das spät eintreffende 40-Grad-Ereignis jedoch erst bei der nächsten Regelaktivierung ein.

Ereigniszeit Eingangszeit Temperatur
09:00 09:02 20
09:01 09:03 30
09:02 09:07 40

Note

Bei Abfragedatenquellen wie Power BI, KQL-Abfragesets und Real-Time Dashboards beeinflusst die Abfragehäufigkeit auch, wie schnell Activator neue Ereignisse erkennt. Siehe Abfragehäufigkeit für Abfragedatenquellen.

Regeln, die auf visuellen Power BI-Elementen basieren

Die integrierte Latenz unterscheidet sich je nach Dienst. Die Latenz für Ereignisstreams unterscheidet sich von der Latenz für Power BI visuelle Elemente. Zwei Faktoren wirken sich auf die Latenz für Regeln aus, die auf Power BI-Visuellelementen basieren: die Häufigkeit der Abfrage der Power BI-Visuellelemente, die im System integriert sind, und eine Verzögerung, die das Backend des Aktivierers möglicherweise einführen kann.

Power BI-Regeln werden jedes Mal ausgewertet, wenn neue Daten im Activator eingehen. Die Aktivierer fragen Power BI standardmäßig einmal pro Stunde ab, das bedeutet, Ereignisse, die der Regelbedingung entsprechen, lösen eine Aktivierung maximal eine Stunde nach dem Auftreten des Ereignisses aus. Sie können diese Häufigkeit in den Datenquelleneinstellungen ändern. Weitere Informationen finden Sie unter Abfragehäufigkeit für Abfragedatenquellen und Erstellen von Power BI-Benachrichtigungen und deren Verfeinerung im Fabric Activator.