Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird beschrieben, wie Sie in Azure Stream Analytics Richtlinien für verspätet eintreffende Ereignisse und Ereignisse außerhalb der Reihenfolge einrichten und verwenden. Diese Richtlinien werden nur angewendet, wenn Sie die Klausel TIMESTAMP BY in Ihrer Abfrage verwenden, und sie werden nur auf Cloudeingabequellen angewendet.
Ereigniszeit und Ankunftszeit
Ihr Stream Analytics-Auftrag kann Ereignisse basierend auf der Ereigniszeit oder der Eingangszeit verarbeiten. Ereignis-/Anwendungszeit ist der Zeitstempel, der in der Ereignisnutzlast vorhanden ist (wenn das Ereignis generiert wurde). Die Eingangszeit ist der Zeitstempel, zu dem das Ereignis an der Eingabequelle (Event Hubs/IoT Hub/Blob Storage) eingegangen ist.
Standardmäßig verarbeitet Stream Analytics Ereignisse nach Ankunftszeit, aber Sie können ereignisse nach Ereigniszeit verarbeiten, indem Sie die TIMESTAMP BY-Klausel in Ihrer Abfrage verwenden. Richtlinien für verspätet eintreffende Ereignisse und für Ereignisse in falscher Reihenfolge gelten nur, wenn Sie Ereignisse anhand der Ereigniszeit verarbeiten. Berücksichtigen Sie die Latenz- und Korrektheitsanforderungen für Ihr Szenario, wenn Sie diese Einstellungen konfigurieren.
Wie lautet die Regelung bei verspätetem Erscheinen?
Manchmal kommen Ereignisse aus verschiedenen Gründen verspätet an. Bei einem Ereignis, das 40 Sekunden zu spät eingeht, beträgt die Ereigniszeit beispielsweise 00:10:00 und die Ankunftszeit 00:10:40. Wenn Sie die Richtlinie für verspätete Ankunft auf 15 Sekunden festlegen, wird jedes Ereignis, das später als 15 Sekunden eintrifft, entweder verworfen (nicht von Stream Analytics verarbeitet) oder die Ereigniszeit angepasst. Im obigen Beispiel geht das Ereignis 40 Sekunden zu spät ein (mehr als in der Richtlinie festgelegt), und die Ereigniszeit wird an den Maximalwert der Richtlinie angepasst: 00:10:25 (Eingangszeit - Wert der Richtlinie für die Eingangsverzögerung). Die Standardrichtlinie für verspätetes Eintreffen beträgt 5 Sekunden.
Was ist die Richtlinie für „außer Betrieb“?
Ereignisse treffen möglicherweise auch in der falschen Reihenfolge ein. Nachdem die Ereigniszeit basierend auf der Richtlinie für verspätetes Eintreffen angepasst wurde, können Sie auch festlegen, dass Ereignisse, die in falscher Reihenfolge eintreffen, automatisch verworfen oder angepasst werden. Wenn Sie diese Richtlinie auf 8 Sekunden festlegen, werden alle Ereignisse, die in der falschen Reihenfolge innerhalb des Zeitfensters von 8 Sekunden eingehen, anhand der Ereigniszeit neu angeordnet. Ereignisse, die später eintreffen, werden entweder verworfen oder an den Maximalwert der Richtlinie für ungeordnete Ereignisse angepasst. Der Standardwert für die Richtlinie bei falscher Reihenfolge beträgt 0 Sekunden.
Verspätete und nicht in der richtigen Reihenfolge eintreffende Ereignisse anpassen oder verwerfen
Wenn Ereignisse basierend auf den Richtlinien, die Sie konfiguriert haben, zu spät oder in falscher Reihenfolge eingehen, können Sie diese Ereignisse löschen (nicht von Stream Analytics verarbeiten lassen) oder die Ereigniszeit anpassen.
Das folgende Beispiel zeigt diese Richtlinien in Aktion.
- Verspätete Ankunftsrichtlinie: 15 Sekunden
- Richtlinie für ungeordnete Ereignisse: 5 Sekunden
| Ereignisnummer | Ereigniszeit | Ankunftszeit | System.Timestamp | Erklärung |
|---|---|---|---|---|
| 1 | 00:10:00 | 00:10:40 | 00:10:25 | Das Ereignis ist verspätet und außerhalb des Toleranzbereichs eingetroffen. Daher wird die Ereigniszeit auf die maximale Toleranz für Eingangsverzögerung angepasst. |
| 2 | 00:10:30 | 00:10:41 | 00:10:30 | Das Ereignis traf verspätet, aber innerhalb des Toleranzbereichs ein. Daher wird die Ereigniszeit nicht angepasst. |
| 3 | 00:10:42 | 00:10:42 | 00:10:42 | Das Event ist pünktlich eingetroffen. Keine Anpassung erforderlich. |
| 4 | 00:10:38 | 00:10:43 | 00:10:38 | Das Ereignis ist außerhalb der Reihenfolge, aber innerhalb der Toleranz von 5 Sekunden eingetroffen. Daher wird die Ereigniszeit nicht angepasst. Für Analysezwecke wird dieses Ereignis vor Ereignis Nummer 3 eingestuft (unter Berücksichtigung der insgesamt 5 Ereignisse. Die tatsächliche Reihenfolge lautet: 1, 2, 5, 4, 3). |
| 5 | 00:10:35 | 00:10:45 | 00:10:37 | Das Ereignis ist in falscher Reihenfolge und außerhalb des Toleranzbereichs von 5 Sekunden eingegangen. Daher wird die Ereigniszeit auf das Maximum der Toleranz für Ereignisse außerhalb der Reihenfolge angepasst. |
Kann verspätete Ankunfts- und Abwesenheitsrichtlinien die Auftragsausgabe verzögern?
Ja. Standardmäßig ist die Richtlinie für Vorgänge außerhalb der Reihenfolge auf null (00 Minuten und 00 Sekunden) festgelegt. Wenn Sie den Standardwert ändern, wird die erste Ausgabe des Auftrags um diesen Wert (oder höher) verzögert.
Wenn eine der Partitionen Ihrer Eingabedaten keine Ereignisse empfängt, sollten Sie damit rechnen, dass sich Ihre Ausgabe um den Wert der Richtlinie für verspätetes Eintreffen verzögert. Informationen dazu finden Sie unter InputPartitionNotProgressing-Nachrichten.
In meinem Aktivitätsprotokoll werden Meldungen vom Typ „LateInputEvents“ angezeigt.
Mit diesen Meldungen werden Sie darüber informiert, dass Ereignisse zu spät eingetroffen sind und (je nach Konfiguration) gelöscht oder angepasst wurden. Sie können diese Nachrichten ignorieren, wenn Sie die Richtlinie für verspätete Ankunft entsprechend konfiguriert haben.
Hier ist ein Beispiel für diese Nachricht:
{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}
In meinem Aktivitätsprotokoll wird „InputPartitionNotProgressing“ angezeigt.
Ihre Eingabequelle (Event Hub/IoT Hub) verfügt wahrscheinlich über mehrere Partitionen. Azure Stream Analytics erzeugt die Ausgabe für Zeitstempel t1 erst, nachdem alle zusammengeführten Partitionen mindestens bei Zeitpunkt t1 angekommen sind. Angenommen, die Abfrage liest aus einer Event Hub-Partition, die zwei Partitionen umfasst. „P1“, eine der Partitionen, verfügt über Ereignisse bis zum Zeitpunkt „t1“. „P2“, die andere Partition, verfügt über Ereignisse bis zum Zeitpunkt „t1 + x“. Die Ausgabe wird dann bis zum Zeitpunkt t1 erzeugt. Wenn jedoch eine explizite Klausel vom Typ „Partition by PartitionId“ vorhanden ist, werden beide Partitionen unabhängig voneinander verarbeitet.
Wenn mehrere Teile des gleichen Eingabedatenstroms kombiniert werden, ist die Toleranz für die Eingangsverzögerung der maximale Zeitraum, in dem jede Partition auf neue Daten wartet. Wenn Ihr Event Hub nur eine Partition hat oder der IoT Hub keine Eingaben erhält, schreitet die Zeitleiste für diese Partition nicht voran, bis der Schwellenwert für die Toleranz bei verspätetem Eintreffen erreicht ist. Dadurch verzögert sich Ihre Ausgabe um den Toleranzschwellenwert für verspäteten Eingang. In solchen Fällen wird möglicherweise die folgende Meldung angezeigt:
{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}
Diese Meldung weist Sie darauf hin, dass mindestens eine Partition in Ihrer Eingabe leer ist und Ihre Ausgabe um den Schwellenwert für verspätetes Eintreffen verzögern wird. Um dies zu überwinden, empfiehlt es sich, Folgendes zu beachten:
- Stellen Sie sicher, dass alle Partitionen Ihres Event Hubs oder IoT Hubs Eingaben empfangen.
- Verwenden Sie in Ihrer Abfrage die Klausel „Partition by PartitionId“.
Warum wird auch dann eine Verzögerung von 5 Sekunden angezeigt, wenn meine Richtlinie für Eingangsverzögerung auf 0 festgelegt ist?
Dies geschieht, wenn eine Eingabepartition vorliegt, die nie Eingaben empfangen hat. Sie können die Eingabemetrik nach Partition überprüfen, um dieses Verhalten zu überprüfen.
Wenn für eine Partition für einen Zeitraum, der den konfigurierten Schwellenwert für verspätetes Eintreffen überschreitet, keine Daten vorliegen, setzt Stream Analytics den Anwendungszeitstempel wie im Abschnitt zu Aspekten der Ereignisreihenfolge erläutert herauf. Dies erfordert die geschätzte Ankunftszeit. Wenn die Partition nie Daten hatte, schätzt Stream Analytics die Ankunftszeit als Ortszeit - 5 Sekunden. Dadurch konnten Partitionen, die niemals Daten enthielten, eine Wasserzeichenverzögerung von 5 Sekunden anzeigen.