Omówienie obsługi czasu w usłudze Azure Stream Analytics
W tym artykule dowiesz się, jak dokonać wyborów projektowych w celu rozwiązania praktycznych problemów z obsługą czasu w zadaniach usługi Azure Stream Analytics. Decyzje projektowe związane z obsługą czasu są ściśle związane z czynnikami porządkowania zdarzeń.
Pojęcia dotyczące czasu tła
Aby lepiej oprawić dyskusję, zdefiniujmy pewne pojęcia w tle:
Czas zdarzenia: godzina wystąpienia oryginalnego zdarzenia. Na przykład, gdy poruszający się samochód na autostradzie zbliża się do stoiska opłat.
Czas przetwarzania: czas dotarcia zdarzenia do systemu przetwarzania i obserwowany. Na przykład gdy czujnik kabiny płatnej widzi samochód, a system komputerowy zajmuje kilka chwil, aby przetworzyć dane.
Znak wodny: znacznik czasu zdarzenia wskazujący, jakie zdarzenia punktu zostały przychodzące do procesora przesyłania strumieniowego. Znaki wodne pozwalają systemowi wskazać jasny postęp pozyskiwania zdarzeń. Ze względu na charakter strumieni dane zdarzeń przychodzących nigdy się nie zatrzymują, więc znaki wodne wskazują postęp do określonego punktu w strumieniu.
Koncepcja znaku wodnego jest ważna. Znaki wodne umożliwiają usłudze Stream Analytics określenie, kiedy system może wygenerować kompletne, poprawne i powtarzalne wyniki, które nie muszą zostać wycofane. Przetwarzanie można wykonać w przewidywalny i powtarzalny sposób. Jeśli na przykład należy wykonać relację w przypadku pewnego warunku obsługi błędów, znaki wodne są bezpieczne od początku i punktu końcowego.
Aby uzyskać dodatkowe zasoby na ten temat, zobacz wpisy w blogu Tylera Akidau Streaming 101 i Streaming 102.
Wybieranie najlepszego czasu rozpoczęcia
Usługa Stream Analytics zapewnia użytkownikom dwie opcje wyboru czasu zdarzenia: czas przybycia i czas aplikacji.
Godzina przyjazdu
Godzina przybycia jest przypisywana w źródle wejściowym, gdy zdarzenie dociera do źródła. Dostęp do czasu przybycia można uzyskać przy użyciu właściwości EventEnqueuedUtcTime dla danych wejściowych usługi Event Hubs, właściwości IoTHub.EnqueuedTime dla danych wejściowych IoT Hub oraz właściwości BlobProperties.LastModified dla danych wejściowych obiektu blob.
Czas przyjazdu jest domyślnie używany i najlepiej jest używany w scenariuszach archiwizacji danych, w których logika czasowa nie jest konieczna.
Czas aplikacji (również nazwany czas zdarzenia)
Czas aplikacji jest przypisywany po wygenerowaniu zdarzenia i jest częścią ładunku zdarzenia. Aby przetwarzać zdarzenia według czasu aplikacji, użyj klauzuli Timestamp by w zapytaniu SELECT. Jeśli sygnatura czasowa według jest nieobecna, zdarzenia są przetwarzane przez czas przybycia.
Ważne jest, aby używać znacznika czasu w ładunku, gdy logika czasowa jest zaangażowana w uwzględnianie opóźnień w systemie źródłowym lub w sieci. Czas przypisany do zdarzenia jest dostępny w systemie. SYGNATURA CZASOWA.
Jak postępuje czas w usłudze Azure Stream Analytics
W przypadku korzystania z czasu aplikacji postęp czasu jest oparty na zdarzeniach przychodzących. System przetwarzania strumieniowego jest trudny dowiedzieć się, czy nie ma zdarzeń, czy zdarzenia są opóźnione. Z tego powodu usługa Azure Stream Analytics generuje heurystyczne znaki wodne na następujące sposoby dla każdej partycji wejściowej:
Jeśli istnieje jakiekolwiek zdarzenie przychodzące, znak wodny jest największym czasem zdarzenia, jaki usługa Stream Analytics widziała do tej pory pomniejszone o rozmiar okna tolerancji poza kolejnością.
Jeśli nie ma zdarzenia przychodzącego, znak wodny jest bieżącym szacowany czas przybycia minus okno tolerancji spóźnienia. Szacowany czas przybycia to czas, który upłynął od czasu ostatniego wystąpienia zdarzenia wejściowego oraz czas przybycia zdarzenia wejściowego.
Czas przybycia można oszacować tylko dlatego, że czas przybycia rzeczywistego jest generowany na brokerze zdarzeń wejściowych, takich jak Event Hubs, ani na maszynie wirtualnej usługi Azure Stream Analytics przetwarzającego zdarzenia.
Projekt służy do dwóch dodatkowych celów innych niż generowanie znaków wodnych:
System generuje wyniki w sposób terminowy z wydarzeniami przychodzącymi lub bez tych zdarzeń.
Masz kontrolę nad terminowym wyświetlaniem wyników wyjściowych. W Azure Portal na stronie Zamawianie zdarzeń zadania usługi Stream Analytics można skonfigurować ustawienie Zdarzenia poza kolejnością. Podczas konfigurowania tego ustawienia należy wziąć pod uwagę kompromis terminów z tolerancją zdarzeń poza kolejnością w strumieniu zdarzeń.
Okno tolerancji spóźnienia jest niezbędne do utrzymania generowania znaków wodnych, nawet w przypadku braku zdarzeń przychodzących. Czasami może wystąpić okres, w którym nie występują żadne zdarzenia przychodzące, na przykład gdy strumień wejściowy zdarzenia jest rozrzedny. Ten problem jest zaostrzony przez użycie wielu partycji w brokerze zdarzeń wejściowych.
Systemy przetwarzania danych przesyłanych strumieniowo bez okna tolerancji opóźnionego przybycia mogą cierpieć na opóźnienia w danych wyjściowych, gdy dane wejściowe są rozrzedzone, a wiele partycji jest używanych.
Zachowanie systemu musi być powtarzalne. Powtarzalność jest ważną właściwością systemu przetwarzania danych przesyłanych strumieniowo.
Znak wodny pochodzi od czasu przybycia i czasu aplikacji. Oba są utrwalane w brokerze zdarzeń, a tym samym powtarzalne. Gdy szacowany jest czas przybycia w przypadku braku zdarzeń, usługa Azure Stream Analytics zapisuje szacowany czas powrotu do powtarzalności podczas ponownego odtwarzania w celu odzyskania awarii.
Jeśli zdecydujesz się używać czasu przyjazdu jako czasu zdarzenia, nie musisz konfigurować tolerancji poza kolejnością i tolerancji opóźnionego przylotu. Ponieważ czas przybycia jest gwarantowany, aby zwiększyć wartość w brokerze zdarzeń wejściowych, usługa Azure Stream Analytics po prostu ignoruje konfiguracje.
Zdarzenia z późnym przybyciem
Zgodnie z definicją okna tolerancji spóźnienia dla każdego zdarzenia przychodzącego usługa Azure Stream Analytics porównuje czas zdarzenia z czasem przybycia. Jeśli czas zdarzenia znajduje się poza oknem tolerancji, można skonfigurować system tak, aby upuścił zdarzenie lub dostosować czas zdarzenia, aby mieścił się w tolerancji.
Po wygenerowaniu znaków wodnych usługa może potencjalnie odbierać zdarzenia z czasem zdarzenia krótszym niż znak wodny. Możesz skonfigurować usługę tak, aby upuściła te zdarzenia lub dostosować czas zdarzenia do wartości limitu.
W ramach korekty znacznik czasu zdarzenia system.timestamp jest ustawiony na nową wartość, ale samo pole czasu zdarzenia nie jest zmieniane. Ta korekta jest jedyną sytuacją, w której znacznik czasu zdarzenia może być inny niż wartość w polu czasu zdarzenia i może spowodować wygenerowanie nieoczekiwanych wyników.
Obsługa odmiany czasu z podwłaściami
Opisany mechanizm generowania znaku wodnego heurystycznego działa dobrze w większości przypadków, gdy czas jest głównie synchronizowany między różnymi nadawcami zdarzeń. Jednak w prawdziwym życiu, zwłaszcza w wielu scenariuszach IoT, system ma niewielką kontrolę nad zegarem na nadawcach zdarzeń. Nadawcy zdarzeń mogą być różnego rodzaju urządzeniami w terenie, być może w różnych wersjach sprzętu i oprogramowania.
Zamiast używać znaku wodnego globalnego dla wszystkich zdarzeń w partycji wejściowej, usługa Stream Analytics ma inny mechanizm nazywany podstreamami. Możesz użyć podstreams w zadaniu, pisząc zapytanie o zadanie, które używa klauzuli TIMESTAMP BY i słowa kluczowego OVER. Aby wyznaczyć podstream, podaj nazwę kolumny klucza po słowie kluczowym OVER , takim jak deviceid, dzięki czemu system stosuje zasady czasu według tej kolumny. Każdy podstream dostaje własny niezależny znak wodny. Ten mechanizm jest przydatny w celu umożliwienia czasowego generowania danych wyjściowych w przypadku dużych niesymetryczności zegara lub opóźnień sieciowych wśród nadawców zdarzeń.
Podstreams to unikatowe rozwiązanie udostępniane przez usługę Azure Stream Analytics i nie są oferowane przez inne systemy przetwarzania danych przesyłanych strumieniowo.
W przypadku korzystania z podstreams usługa Stream Analytics stosuje okno tolerancji spóźnienia do zdarzeń przychodzących. Tolerancja opóźnionego przybycia decyduje o maksymalnej ilości, o jaką różne podstreamy mogą być niezależnie od siebie. Jeśli na przykład urządzenie 1 znajduje się na sygnaturze czasowej 1, a urządzenie 2 znajduje się na sygnaturze czasowej 2, najbardziej opóźniona tolerancja przylotu to Sygnatura czasowa 2 minus Sygnatura czasowa 1. Ustawienie domyślne to 5 sekund i prawdopodobnie jest zbyt małe dla urządzeń z rozbieżnymi znacznikami czasu. Zalecamy rozpoczęcie od 5 minut i dostosowanie zgodnie ze wzorcem niesymetryczności zegara urządzenia.
Zdarzenia o wczesnych przyjazdach
Być może zauważyłeś inną koncepcję o nazwie okno wczesnego przyjazdu, które wygląda jak przeciwieństwo okna tolerancji późnego przyjazdu. To okno jest stałe na 5 minut i służy do innego celu niż okno tolerancji opóźnionego przybycia.
Ponieważ usługa Azure Stream Analytics gwarantuje pełne wyniki, można określić tylko godzinę rozpoczęcia zadania jako pierwszy czas wyjściowy zadania, a nie czas wejściowy. Czas rozpoczęcia zadania jest wymagany, aby pełne okno było przetwarzane, a nie tylko w środku okna.
Usługa Stream Analytics uzyskuje czas rozpoczęcia od specyfikacji zapytania. Jednak ponieważ broker zdarzeń wejściowych jest indeksowany tylko przez czas przybycia, system musi przetłumaczyć czas rozpoczęcia zdarzenia na czas przybycia. System może rozpocząć przetwarzanie zdarzeń z tego punktu w brokerze zdarzeń wejściowych. Dzięki limitowi okna wczesnego przybycia tłumaczenie jest proste: czas rozpoczęcia zdarzenia minus 5-minutowe okno wczesnego przybycia. To obliczenie oznacza również, że system odrzuca wszystkie zdarzenia, które są postrzegane jako zdarzenie o czasie 5 minut wcześniej niż czas przybycia. Metryka wczesnych zdarzeń wejściowych jest zwiększana po usunięciu zdarzeń.
Ta koncepcja służy do zapewnienia, że przetwarzanie jest powtarzalne bez względu na to, skąd rozpoczynasz dane wyjściowe. Bez takiego mechanizmu nie byłoby możliwe zagwarantowanie powtarzalności, ponieważ wiele innych systemów przesyłania strumieniowego twierdzi, że to robią.
Skutki uboczne tolerancji czasu porządkowania zdarzeń
Zadania usługi Stream Analytics mają kilka opcji porządkowania zdarzeń . Dwa można skonfigurować w Azure Portal: ustawienie Out of order events (tolerancja poza kolejnością) i Zdarzenia, które docierają późno (tolerancja opóźnionego przylotu). Tolerancja wczesnego przybycia jest stała i nie można jej dostosować. Te zasady czasowe są używane przez usługę Stream Analytics w celu zapewnienia silnych gwarancji. Jednak te ustawienia czasami mają nieoczekiwane implikacje:
Przypadkowe wysyłanie zdarzeń, które są zbyt wcześnie.
Wczesne zdarzenia nie powinny być zwracane normalnie. Istnieje możliwość, że wczesne zdarzenia są wysyłane do danych wyjściowych, jeśli zegar nadawcy działa zbyt szybko. Wszystkie wczesne przychodzące zdarzenia są porzucane, więc nie będą widoczne żadne z nich z danych wyjściowych.
Wysyłanie starych zdarzeń do usługi Event Hubs do przetworzenia przez usługę Azure Stream Analytics.
Podczas gdy stare wydarzenia mogą wydawać się nieszkodliwe na początku, ze względu na zastosowanie tolerancji opóźnionego przybycia, stare wydarzenia mogą zostać usunięte. Jeśli zdarzenia są zbyt stare, wartość Znacznik czasu system.timestamp jest zmieniana podczas pozyskiwania zdarzeń. Ze względu na to zachowanie obecnie usługa Azure Stream Analytics jest bardziej odpowiednia dla scenariuszy przetwarzania zdarzeń niemal w czasie rzeczywistym zamiast historycznych scenariuszy przetwarzania zdarzeń. W niektórych przypadkach można ustawić zdarzenia, które docierają późno do największej możliwej wartości (20 dni), aby obejść to zachowanie.
Dane wyjściowe wydają się być opóźnione.
Pierwszy znak wodny jest generowany w obliczonym czasie: maksymalny czas zdarzenia zaobserwowany do tej pory przez system, minus rozmiar okna tolerancji poza kolejnością. Domyślnie tolerancja poza kolejnością jest skonfigurowana do zera (00 minut i 00 sekund). Po ustawieniu jej na wyższą, niezerową wartość czasu pierwsze dane wyjściowe zadania przesyłania strumieniowego są opóźnione przez wartość czasu (lub większą) z powodu pierwszego obliczonego limitu czasu.
Dane wejściowe są rozrzedłe.
Jeśli w danej partycji nie ma danych wejściowych, czas limitu jest obliczany jako czas przybycia pomniejszone o przedział tolerancji opóźnionego przybycia. W związku z tym, jeśli zdarzenia wejściowe są rzadko występujące i rozrzedzone, dane wyjściowe mogą być opóźnione o ten czas. Domyślne zdarzenia, które docierają późno , to 5 sekund. Podczas wysyłania zdarzeń wejściowych należy oczekiwać pewnego opóźnienia, na przykład. Opóźnienia mogą się pogorszyć, gdy ustawisz ustawienie Zdarzenia, które docierają późno w oknie, na dużą wartość.
Wartość znacznika czasowego System.Timestamp różni się od czasu w polu czasu zdarzenia.
Jak opisano wcześniej, system dostosowuje czas zdarzenia przez tolerancję poza kolejnością lub okna tolerancji opóźnionego przylotu. Wartość znacznika czasowego zdarzenia System.Timestamp jest dostosowywana, ale nie pole czasu zdarzenia . Może to służyć do identyfikowania zdarzeń dostosowanych sygnatur czasowych. Jeśli system zmienił znacznik czasu ze względu na jedną z tolerancji, zwykle są one takie same.
Metryki do obserwowania
Możesz obserwować szereg efektów tolerancji czasu porządkowania zdarzeń za pomocą metryk zadań usługi Azure Stream Analytics. Istotne są następujące metryki:
| Metric | Opis |
|---|---|
| Zdarzenia poza kolejnością | Wskazuje liczbę zdarzeń odebranych z zamówienia, które zostały porzucone lub podane dostosowane znaczniki czasu. Ta metryka ma bezpośredni wpływ na konfigurację ustawienia Zdarzenia poza kolejnością na stronie Porządkowanie zdarzeń w zadaniu w Azure Portal. |
| Zdarzenia późnych danych wejściowych | Wskazuje liczbę zdarzeń przychodzących późno ze źródła. Ta metryka obejmuje zdarzenia, które zostały porzucone lub zostały skorygowane sygnatury czasowej. Ta metryka ma bezpośredni wpływ na konfigurację zdarzeń, które docierają do późnego ustawienia na stronie Kolejność zdarzeń w zadaniu w Azure Portal. |
| Wczesne zdarzenia wejściowe | Wskazuje liczbę zdarzeń przybywających wcześnie ze źródła, które zostały porzucone, lub ich sygnatura czasowa została skorygowana, jeśli są one powyżej 5 minut na początku. |
| Opóźnienie znaku wodnego | Wskazuje opóźnienie zadania przetwarzania danych przesyłanych strumieniowo. Zobacz więcej informacji w poniższej sekcji. |
Szczegóły opóźnienia znaku wodnego
Metryka opóźnienia znaku wodnego jest obliczana jako czas zegara ściany węzła przetwarzania minus największy znak wodny, który widział do tej pory. Aby uzyskać więcej informacji, zobacz wpis w blogu o opóźnieniu znaku wodnego.
Może istnieć kilka powodów, dla których ta wartość metryki jest większa niż 0 w ramach normalnego działania:
Z natury opóźnienie przetwarzania potoku przesyłania strumieniowego. Zwykle to opóźnienie jest nominalne.
Okno tolerancji poza kolejnością wprowadziło opóźnienie, ponieważ znak wodny jest zmniejszony o rozmiar okna tolerancji.
Opóźnione okno przylotu wprowadziło opóźnienie, ponieważ znak wodny jest zmniejszany o rozmiar okna tolerancji.
Niesymetryczność zegara węzła przetwarzania generującego metryki.
Istnieje wiele innych ograniczeń zasobów, które mogą spowodować spowolnienie potoku przesyłania strumieniowego. Metryka opóźnienia znaku wodnego może wzrosnąć z powodu:
Za mało zasobów przetwarzania w usłudze Stream Analytics, aby obsłużyć ilość zdarzeń wejściowych. Aby skalować zasoby w górę, zobacz Omówienie i dostosowywanie jednostek przesyłania strumieniowego.
Za mało przepływności w ramach brokerów zdarzeń wejściowych, więc są one ograniczane. Aby uzyskać możliwe rozwiązania, zobacz Automatyczne skalowanie w górę Azure Event Hubs jednostek przepływności.
Ujścia wyjściowe nie są aprowizowane z wystarczającą pojemnością, więc są ograniczane. Możliwe rozwiązania różnią się znacznie w zależności od używanej usługi wyjściowej.
Częstotliwość zdarzeń wyjściowych
Usługa Azure Stream Analytics używa postępu znaku wodnego jako jedynego wyzwalacza do tworzenia zdarzeń wyjściowych. Ponieważ znak wodny pochodzi z danych wejściowych, jest powtarzalny podczas odzyskiwania po awarii, a także podczas ponownego przetwarzania zainicjowanego przez użytkownika. W przypadku korzystania z agregacji okien usługa generuje tylko dane wyjściowe na końcu okien. W niektórych przypadkach użytkownicy mogą chcieć zobaczyć częściowe agregacje wygenerowane z okien. Częściowe agregacje nie są obecnie obsługiwane w usłudze Azure Stream Analytics.
W innych rozwiązaniach do przesyłania strumieniowego zdarzenia wyjściowe mogą być zmaterializowane w różnych punktach wyzwalacza w zależności od okoliczności zewnętrznych. W niektórych rozwiązaniach można wielokrotnie generować zdarzenia wyjściowe dla danego przedziału czasu. Gdy wartości wejściowe są uściśline, zagregowane wyniki stają się bardziej dokładne. Zdarzenia mogą być spekulowane na początku i zmieniane w czasie. Na przykład gdy określone urządzenie jest w trybie offline z sieci, szacowana wartość może być używana przez system. Później to samo urządzenie jest w trybie online w sieci. Następnie rzeczywiste dane zdarzenia można uwzględnić w strumieniu wejściowym. Dane wyjściowe z przetwarzania tego przedziału czasu generują dokładniejsze dane wyjściowe.
Zilustrowany przykład znaków wodnych
Poniższe obrazy ilustrują postęp znaków wodnych w różnych okolicznościach.
W tej tabeli przedstawiono przykładowe dane, które są wykresowane poniżej. Zwróć uwagę, że czas zdarzenia i czas przybycia różnią się, czasami pasujące, a czasami nie.
| Czas zdarzenia | Godzina przyjazdu | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | device3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | device3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | device3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | device3 |
Na tej ilustracji są używane następujące tolerancje:
- Okna wczesnego przyjazdu to 5 minut
- Spóźnione okno przylotu wynosi 5 minut
- Okno zmiany kolejności wynosi 2 minuty
Ilustracja przedstawiająca postęp znaku wodnego przez następujące zdarzenia:
Istotne procesy przedstawione na poprzedniej ilustracji:
Pierwsze zdarzenie (urządzenie1) i drugie zdarzenie (urządzenie2) mają wyrównane czasy i są przetwarzane bez korekt. Znak wodny przechodzi w każdym zdarzeń.
Po przetworzeniu trzeciego zdarzenia (device1) godzina przybycia (12:11) poprzedza czas zdarzenia (12:17). Wydarzenie przybyło 6 minut wcześnie, więc wydarzenie zostało porzucone z powodu 5-minutowej tolerancji wczesnego przybycia.
Znak wodny nie postępuje w tym przypadku wczesnego zdarzenia.
Czwarte zdarzenie (urządzenie3) i piąte zdarzenie (urządzenie1) mają wyrównane czasy i są przetwarzane bez korekty. Znak wodny przechodzi w każdym zdarzeń.
Po przetworzeniu szóstego zdarzenia (urządzenie3) czas przybycia (12:17) i czas zdarzenia (12:12) jest niższy od poziomu znaku wodnego. Czas zdarzenia jest dostosowywany do poziomu znaku wodnego (12:17).
Po przetworzeniu dwunastego zdarzenia (device3) czas przybycia (12:27) wynosi 6 minut przed czasem zdarzenia (12:21). Stosowane są zasady późnego przyjazdu. Czas zdarzenia jest dostosowywany (12:22), który znajduje się powyżej znaku wodnego (12:21), więc nie stosuje się dalszych korekt.
Druga ilustracja przedstawiająca postęp znaku wodnego bez zasad wczesnego przybycia:
W tym przykładzie nie zastosowano żadnych zasad wczesnego przybycia. Zdarzenia odstające, które przybywają wcześnie podnieść znak wodny znacznie. Zwróć uwagę, że trzecie zdarzenie (deviceId1 w czasie 12:11) nie zostanie usunięte w tym scenariuszu, a znak wodny zostanie podniesiony do 12:15. Czwarty czas zdarzenia jest dostosowywany do przodu 7 minut (od 12:08 do 12:15) w wyniku.
Na ostatniej ilustracji używane są podstreamy (OVER the DeviceId). Śledzono wiele znaków wodnych, jeden na strumień. W rezultacie jest mniej zdarzeń dostosowanych do czasu.
