Omówienie obsługi czasu w usłudze Azure Stream Analytics
Z tego artykułu 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 dotyczące obsługi czasu są ściśle związane z czynnikami porządkowania zdarzeń.
Pojęcia dotyczące czasu w tle
Aby lepiej oprawić dyskusję, zdefiniujmy kilka pojęć w tle:
Czas zdarzenia: czas wystąpienia oryginalnego zdarzenia. Na przykład gdy poruszający się samochód na autostradzie zbliża się do kabiny płatnej.
Czas przetwarzania: czas, w którym zdarzenie dociera do systemu przetwarzania i jest obserwowane. Na przykład gdy czujnik punktu płatnego widzi samochód, a system komputerowy może chwilę 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ć wyraźny postęp pozyskiwania zdarzeń. Ze względu na charakter strumieni dane zdarzeń przychodzących nigdy nie są zatrzymywane, więc znaki wodne wskazują postęp do określonego punktu w strumieniu.
Pojęcie znaku wodnego jest ważne. Znaki wodne umożliwiają usłudze Stream Analytics określenie, kiedy system może generować kompletne, poprawne i powtarzalne wyniki, które nie muszą być 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łędu, 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 usługi IoT Hub oraz właściwości BlobProperties.LastModified dla danych wejściowych obiektu blob.
Czas przybycia jest używany domyślnie i najlepiej jest używany w scenariuszach archiwizacji danych, w których logika czasowa nie jest konieczna.
Czas aplikacji (nazwany również czasem zdarzenia)
Czas aplikacji jest przypisywany po wygenerowaniu zdarzenia i jest częścią ładunku zdarzenia. Aby przetworzyć 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żyć 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ęp czasu 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 żadnych zdarzeń, czy zdarzenia są opóźnione. Z tego powodu usługa Azure Stream Analytics generuje znaki heurystyczne w następujący sposób 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 pomniejszone o przedział czasu opóźnienia tolerancji przylotu. Szacowany czas przybycia to czas, który upłynął od 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, takim jak event hubs, ani na maszynie wirtualnej usługi Azure Stream Analytics przetwarza zdarzenia.
Projekt służy dwóm dodatkowym celom innym niż generowanie znaków wodnych:
System generuje wyniki w odpowiednim czasie z lub bez zdarzeń przychodzących.
Masz kontrolę nad terminowym wyświetlaniem wyników wyjściowych. W witrynie Azure Portal na stronie Porządkowanie zdarzeń zadania usługi Stream Analytics można skonfigurować ustawienie Zdarzenia poza kolejnością. Podczas konfigurowania tego ustawienia należy wziąć pod uwagę kompromis osi czasu z tolerancją zdarzeń poza kolejnością w strumieniu zdarzeń.
Okno tolerancji późnego przybycia jest niezbędne do utrzymania generowania znaków wodnych, nawet w przypadku braku przychodzących zdarzeń. Czasami może występować 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óźnione dane wyjściowe, 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 przypadku odzyskiwania po awarii.
Jeśli zdecydujesz się używać czasu przyjazdu jako czasu zdarzenia, nie musisz konfigurować tolerancji poza kolejnością i tolerancji późnego przyjazdu. Ze względu na to, że czas przybycia jest gwarantowany, że w brokerze zdarzeń wejściowych usługa Azure Stream Analytics po prostu ignoruje konfiguracje.
Zdarzenia z późnym przybyciem
Zgodnie z definicją okna tolerancji opóźnionego przylotu 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 porzucił 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ż limit czasu. Usługę można skonfigurować tak, aby usunąć te zdarzenia lub dostosować czas zdarzenia do wartości limitu.
W ramach korekty parametr System.Timestamp zdarzenia 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 podstreamami
Opisany mechanizm generowania znaków heurystycznych działa dobrze w większości przypadków, w których 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 nadawców 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, który jest globalny dla wszystkich zdarzeń w partycji wejściowej, usługa Stream Analytics ma inny mechanizm nazywany podstreamami. W zadaniu można używać podstreams, pisząc zapytanie zadania, 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, aby system stosuje zasady czasu według tej kolumny. Każdy podstream dostaje własny niezależny znak wodny. Ten mechanizm jest przydatny, aby umożliwić generowanie danych wyjściowych w odpowiednim czasie podczas pracy z dużymi niesymetrycznościami zegara lub opóźnieniami sieci 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 podstreamów usługa Stream Analytics stosuje okno tolerancji późnego przybycia do zdarzeń przychodzących. Tolerancja opóźnionego przybycia decyduje o maksymalnej wartości, o jaką różne podbiegi mogą być niezależnie od siebie. Jeśli na przykład urządzenie 1 znajduje się w znaczniku czasu 1, a urządzenie 2 znajduje się na sygnaturze czasowej 2, najbardziej opóźniona tolerancja przylotu to Sygnatura czasowa 2 minus Znacznik czasu 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 wczesnego przybycia
Być może zauważyłeś inną koncepcję o nazwie okno wczesnego przybycia, które wygląda jak przeciwieństwo okna tolerancji późnego przyjazdu. To okno jest stałe o 5 minutach i służy do innego celu niż okno tolerancji późnego 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 wprowadzania. Czas rozpoczęcia zadania jest wymagany, aby całe 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ń od tego momentu w brokerze zdarzeń wejściowych. Dzięki limitowi okna wczesnego przybycia tłumaczenie jest proste: czas rozpoczęcia zdarzenia pomniejszonego o 5-minutowe okno wczesnego przybycia. To obliczenie oznacza również, że system odrzuca wszystkie zdarzenia, które są postrzegane jako o czasie zdarzenia 5 minut wcześniej niż czas przybycia. Metryka wczesnych zdarzeń wejściowych jest zwiększana, gdy zdarzenia zostaną porzucone.
Ta koncepcja służy do zapewnienia, że przetwarzanie jest powtarzalne niezależnie od tego, 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 zamawiania zdarzeń. Dwa można skonfigurować w witrynie Azure Portal: ustawienie Zdarzenia poza kolejnością (tolerancja poza kolejnością ) i Zdarzenia, które docierają z opóźnieniem (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ć zwykle zwracane. Istnieje możliwość, że wczesne zdarzenia są wysyłane do danych wyjściowych, jeśli zegar nadawcy działa zbyt szybko. Wszystkie zdarzenia wczesnego przybycia są porzucane, więc nie zobaczysz żadnego 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 późnego przybycia, stare wydarzenia mogą zostać porzucone. 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ć wartość 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 przez system do tej pory, pomniejszony o rozmiar okna tolerancji poza kolejnością. Domyślnie tolerancja poza kolejnością jest skonfigurowana na zero (00 minut i 00 sekund). Jeśli ustawisz ją na wyższą, niezerową wartość czasu, pierwsze dane wyjściowe zadania przesyłania strumieniowego są opóźnione o wartość czasu (lub większą) ze względu na czas pierwszego limitu, który jest obliczany.
Dane wejściowe są rozrzedłe.
Jeśli w danej partycji nie ma danych wejściowych, czas limitu jest obliczany jako czas przybycia pomniejszonego o przedział tolerancji opóźnionego przybycia. W związku z tym, jeśli zdarzenia wejściowe są rzadko i rozrzedzone, dane wyjściowe mogą być opóźnione o ten czas. Domyślne zdarzenia, które docierają późno , to 5 sekund. Należy spodziewać się pewnego opóźnienia podczas wysyłania zdarzeń wejściowych pojedynczo, na przykład. Opóźnienia mogą się pogorszyć, gdy ustawisz opcję Zdarzenia, które docierają do późnego okna na dużą wartość.
Wartość elementu 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ść Elementu System.Timestamp zdarzenia jest dostosowywana, ale nie pole czasu zdarzenia. Może to służyć do identyfikowania, dla których zdarzeń skorygowane znaczniki czasu. 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:
| Metryczne | 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 witrynie Azure Portal. |
| Zdarzenia późnych danych wejściowych | Wskazuje liczbę zdarzeń przychodzących późno ze źródła. Ta metryka zawiera zdarzenia, które zostały porzucone lub zostały skorygowane znaczniki czasu. Ta metryka ma bezpośredni wpływ na konfigurację zdarzeń, które docierają późno na stronie Porządkowanie zdarzeń w zadaniu w witrynie Azure Portal. |
| Zdarzenia wczesnego wprowadzania danych wejściowych | Wskazuje liczbę zdarzeń przybywających wcześnie ze źródła, które zostały porzucone, lub ich znacznik czasu został skorygowany, jeśli są one dłuższe niż 5 minut wcześniej. |
| 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 limitu
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:
Nieodłączne 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 zmniejszany przez rozmiar okna tolerancji.
Opóźnione okno przylotu wprowadziło opóźnienie, ponieważ znak wodny jest zmniejszany przez 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 limitu może wzrosnąć z następujących powodów:
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 wejściowych brokerów zdarzeń, więc są one ograniczane. Aby uzyskać możliwe rozwiązania, zobacz Automatyczne skalowanie w górę jednostek przepływności usługi Azure Event Hubs.
Ujścia wyjściowe nie są aprowidowane 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 generowania 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. W miarę uściślinia wartości wejściowych zagregowane wyniki stają się dokładniejsze. 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.
Ilustrowany przykład znaków wodnych
Na poniższych ilustracjach pokazano, jak znaki wodne postępują w różnych okolicznościach.
W tej tabeli przedstawiono przykładowe dane, które zostały na wykresie 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 używane są następujące tolerancje:
- Okna wczesnego przyjazdu to 5 minut
- Opóźnione okno przylotu wynosi 5 minut
- Zmiana kolejności okna wynosi 2 minuty
Ilustracja przedstawiająca postęp znaku wodnego za pośrednictwem tych zdarzeń:
Istotne procesy przedstawione na poprzedniej grafice:
Pierwsze zdarzenie (urządzenie1) i drugie zdarzenie (device2) mają wyrównane czasy i są przetwarzane bez korekt. Znak wodny postępuje na każdym zdarzeń.
Po przetworzeniu trzeciego zdarzenia (device1) godzina przybycia (12:11) poprzedza czas zdarzenia (12:17). Wydarzenie przybyło 6 minut wcześniej, więc wydarzenie zostało porzucone z powodu 5-minutowej tolerancji wczesnego przybycia.
Znak wodny nie postępuje w tym przypadku w przypadku wczesnego wydarzenia.
Czwarte zdarzenie (device3) i piąte zdarzenie (urządzenie1) mają wyrównane czasy i są przetwarzane bez korekty. Znak wodny postępuje na każdym zdarzeń.
Po przetworzeniu szóstego zdarzenia (device3) czas przybycia (12:17) i czas zdarzenia (12:12) jest niższy od poziomu limitu. 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). Zastosowano zasady późnego przyjazdu. Czas zdarzenia jest dostosowywany (12:22), który znajduje się powyżej znaku wodnego (12:21), więc nie jest stosowana żadna dalsza korekta.
Druga ilustracja postępu znaku wodnego bez polityki wczesnego przybycia:
W tym przykładzie nie zastosowano żadnych zasad wcześniejszego przyjazdu. Zdarzenia odstające, które przybywają wcześnie podnieść znak wodny znacznie. Zwróć uwagę, że trzecie zdarzenie (deviceId1 w czasie 12:11) nie zostało usunięte w tym scenariuszu, a znak wodny jest zgłaszany 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, po jednym na strumień. W rezultacie jest mniej zdarzeń, których czasy są dostosowywane.
