Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano sposób konfigurowania i używania zasad zdarzeń opóźnionego przyjazdu i braku zamówienia w usłudze Azure Stream Analytics. Te zasady są stosowane tylko wtedy, gdy używasz klauzuli TIMESTAMP BY w zapytaniu i są stosowane tylko dla źródeł danych wejściowych w chmurze.
Czas zdarzenia i godzina przybycia
Zadanie usługi Stream Analytics może przetwarzać zdarzenia na podstawie czasu zdarzenia lub czasu przybycia. Czas zdarzenia/aplikacji to sygnatura czasowa obecna w ładunku zdarzenia (gdy zdarzenie zostało wygenerowane). Godzina przybycia to sygnatura czasowa odebrania zdarzenia w źródle wejściowym (Event Hubs/IoT Hub/Blob Storage).
Domyślnie usługa Stream Analytics przetwarza zdarzenia według czasu przybycia, ale możesz wybrać przetwarzanie zdarzeń według czasu zdarzenia przy użyciu klauzuli TIMESTAMP BY w zapytaniu. Zasady opóźnionego przyjazdu i braku zamówienia mają zastosowanie tylko w przypadku przetwarzania zdarzeń według czasu zdarzenia. Podczas konfigurowania tych ustawień należy wziąć pod uwagę wymagania dotyczące opóźnienia i poprawności dla danego scenariusza.
Co to są zasady spóźnionego przybycia?
Czasami wydarzenia przychodzą późno z różnych powodów. Na przykład zdarzenie, które pojawia się 40 sekund późno, będzie miało czas zdarzenia = 00:10:00 i czas przybycia = 00:10:40. Jeśli ustawisz zasady opóźnionego przyjazdu na 15 sekund, każde zdarzenie, które zostanie dostarczone później niż 15 sekund, zostanie usunięte (nie przetworzone przez usługę Stream Analytics) lub zostanie skorygowane ich czas zdarzenia. W powyższym przykładzie, ponieważ zdarzenie przybyło 40 sekund późno (więcej niż zestaw zasad), jego czas zdarzenia zostanie dostosowany do maksymalnej wartości zasad późnego przyjazdu 00:10:25 (czas przyjazdu — wartość zasad spóźnienia). Domyślne zasady późnego przyjazdu to 5 sekund.
Co to są zasady poza kolejnością?
Zdarzenie może również pojawić się poza zamówieniem. Po dostosowaniu czasu zdarzenia na podstawie zasad późnego przyjazdu można również wybrać automatyczne upuszczanie lub dostosowanie zdarzeń, które są poza kolejnością. Jeśli ustawisz te zasady na 8 sekund, wszystkie zdarzenia, które docierają z zamówienia, ale w 8-sekundowym oknie, są zmieniane według czasu zdarzenia. Zdarzenia, które docierają później, zostaną usunięte lub dostosowane do maksymalnej wartości zasad poza kolejnością. Domyślne zasady poza kolejnością to 0 sekund.
Dostosowywanie lub upuszczanie zdarzeń
Jeśli zdarzenia pojawią się późno lub poza kolejnością na podstawie skonfigurowanych zasad, możesz usunąć takie zdarzenia (nie przetworzone przez usługę Stream Analytics) lub dostosować ich czas zdarzenia.
Zobaczmy przykład tych zasad w działaniu.
Zasady późnego przyjazdu: 15 sekund
Zasady poza kolejnością: 5 sekund
| Zdarzenie nr. | Czas zdarzenia | Godzina przyjazdu | System.Timestamp | Wyjaśnienie |
|---|---|---|---|---|
| 1 | 00:10:00 | 00:10:40 | 00:10:25 | Zdarzenie przybyło późno i na zewnątrz poziomu tolerancji. Więc czas zdarzenia jest dostosowywany do maksymalnej tolerancji późnego przybycia. |
| 2 | 00:10:30 | 00:10:41 | 00:10:30 | Zdarzenie zostało opóźnione, ale na poziomie tolerancji. Dlatego czas zdarzenia nie jest dostosowywany. |
| 3 | 00:10:42 | 00:10:42 | 00:10:42 | Zdarzenie dotarło na czas. Nie trzeba wprowadzać żadnych korekt. |
| 4 | 00:10:38 | 00:10:43 | 00:10:38 | Zdarzenie wyszło poza kolejność, ale w granicach tolerancji 5 sekund. Dlatego czas zdarzenia nie jest dostosowywany. Dla celów analitycznych to zdarzenie zostanie uznane za poprzednie zdarzenie o numerze 3 (z uwzględnieniem łącznej liczby 5 zdarzeń. Rzeczywista kolejność to: 1, 2, 5, 4, 3). |
| 5 | 00:10:35 | 00:10:45 | 00:10:37 | Zdarzenie wyszło poza kolejność i tolerancję zewnętrzną na 5 sekund. Dlatego czas zdarzenia jest dostosowywany do maksymalnej tolerancji poza kolejnością. |
Czy te ustawienia mogą opóźniać dane wyjściowe zadania?
Tak. Domyślnie zasady poza kolejnością są ustawione na zero (00 minut i 00 sekund). Jeśli zmienisz wartość domyślną, pierwsze dane wyjściowe zadania będą opóźnione przez tę wartość (lub większą).
Jeśli jedna z partycji danych wejściowych nie odbiera zdarzeń, należy oczekiwać, że dane wyjściowe zostaną opóźnione przez wartość zasad późnego przybycia. Aby dowiedzieć się, dlaczego, przeczytaj sekcję błąd InputPartition poniżej.
W dzienniku aktywności są wyświetlane komunikaty LateInputEvents
Te komunikaty są wyświetlane, aby poinformować o tym, że zdarzenia dotarły późno i zostały usunięte lub dostosowane zgodnie z konfiguracją. Te komunikaty można zignorować, jeśli odpowiednio skonfigurowano zasady późnego przyjazdu.
Przykład tej wiadomości to:
{"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"}
Widzę wartość InputPartitionNotProgressing w moim dzienniku aktywności
Źródło danych wejściowych (centrum zdarzeń/centrum IoT Hub) prawdopodobnie ma wiele partycji. Usługa Azure Stream Analytics generuje dane wyjściowe dla sygnatury czasowej t1 tylko wtedy, gdy wszystkie połączone partycje są co najmniej t1. Załóżmy na przykład, że zapytanie odczytuje z partycji centrum zdarzeń, która ma dwie partycje. Jedna z partycji, P1, ma zdarzenia do czasu t1. Druga partycja, P2, ma zdarzenia do czasu t1 + x. Dane wyjściowe są następnie generowane do czasu t1. Jeśli jednak istnieje jawna klauzula Partition by PartitionId, obie partycje postępują niezależnie.
W przypadku łączenia wielu partycji z tego samego strumienia wejściowego tolerancja opóźnionego przybycia to maksymalny czas oczekiwania na nowe dane przez każdą partycję. Jeśli w centrum zdarzeń znajduje się jedna partycja lub jeśli usługa IoT Hub nie odbiera danych wejściowych, oś czasu dla tej partycji nie postępuje, dopóki nie osiągnie progu tolerancji opóźnionego przybycia. Spowoduje to opóźnienie danych wyjściowych przez próg tolerancji opóźnionego przybycia. W takich przypadkach może zostać wyświetlony następujący komunikat:
{"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"}
Ten komunikat informujący o tym, że co najmniej jedna partycja w danych wejściowych jest pusta i opóźni dane wyjściowe o próg opóźnionego przybycia. Aby rozwiązać ten problem, zaleca się:
- Upewnij się, że wszystkie partycje centrum zdarzeń/centrum IoT Hub odbierają dane wejściowe.
- Użyj klauzuli Partition by PartitionID w zapytaniu.
Dlaczego widzę opóźnienie 5 sekund nawet wtedy, gdy moje zasady opóźnionego przyjazdu mają wartość 0?
Dzieje się tak, gdy istnieje partycja wejściowa, która nigdy nie otrzymała żadnych danych wejściowych. Możesz zweryfikować metryki wejściowe według partycji, aby zweryfikować to zachowanie.
Jeśli partycja nie ma żadnych danych dla więcej niż skonfigurowany próg opóźnionego przybycia, usługa Stream Analytics przechodzi sygnaturę czasową aplikacji zgodnie z wyjaśnieniem w sekcji zagadnień dotyczących porządkowania zdarzeń. Wymaga to szacowanej godziny przyjazdu. Jeśli partycja nigdy nie miała żadnych danych, usługa Stream Analytics szacuje czas przybycia jako czas lokalny — 5 sekund. W związku z tym partycje, które nigdy nie miały żadnych danych, mogą pokazywać opóźnienie limitu 5 sekund.