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ązywania 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 płatnej kabiny.

  • Czas przetwarzania: czas, kiedy 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, do jakiego punktu zdarzenia 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 nie są zatrzymywane, dlatego 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 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ć recount dla pewnego warunku obsługi błędu, znaki wodne są bezpiecznymi punktami początkowymi i końcowymi.

Aby uzyskać dodatkowe zasoby na ten temat, zobacz wpisy Tylera Akidau w blogu Streaming 101 i Streaming 102.

Wybierz najlepszy czas rozpoczęcia

Usługa Stream Analytics oferuje użytkownikom dwie opcje wyboru czasu zdarzenia: czas przybycia i czas aplikacji.

Godzina przyjazdu

Czas przybycia jest przypisywany 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 IoT Hub danych wejściowych oraz właściwości BlobProperties.LastModified dla danych wejściowych obiektu blob.

Czas przybycia jest używany domyślnie i najlepiej nadaje się do archiwizowania danych w scenariuszach, 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 przetwarzać zdarzenia według czasu aplikacji, użyj klauzuli Timestamp by w zapytaniu SELECT. Jeśli znacznik czasu według jest nieobecny, zdarzenia są przetwarzane przez czas przybycia.

Ważne jest, aby użyć znacznika czasu w ładunku, gdy logika czasowa jest uwzględniana w celu uwzględnienia 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 żadnych zdarzeń, czy zdarzenia są opóźnione. Z tego powodu usługa Azure Stream Analytics generuje znaki wodne heurystyczne w następujący sposób dla każdej partycji wejściowej:

  • W przypadku wystąpienia jakichkolwiek zdarzeń przychodzących znak wodny jest największym czasem zdarzenia, który usługa Stream Analytics widziała do tej pory pomniejszone o rozmiar okna tolerancji poza kolejnością.

  • Jeśli nie ma zdarzenia przychodzącego, limit jest bieżącym szacowanym czasem przybycia pomniejszonego o przedział tolerancji opóźnionych przylotów. 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 usługa 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:

  1. System generuje wyniki w odpowiednim czasie z lub bez zdarzeń przychodzących.

    Masz kontrolę nad terminowym wyświetlaniem wyników wyjściowych. W 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 opóźnionego 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ą mieć wpływ na opóźnione dane wyjściowe, gdy dane wejściowe są rozrzedzone i są używane wiele partycji.

  2. 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 powtarzalności podczas ponownego odtwarzania w przypadku odzyskiwania po awarii.

W przypadku wybrania czasu przyjazdu jako czasu zdarzenia nie trzeba konfigurować tolerancji poza kolejnością i tolerancji opóźnionego przylotu. Ze względu na to, że czas przybycia jest gwarantowany w brokerze zdarzeń wejściowych, usługa Azure Stream Analytics po prostu pomija konfiguracje.

Późne przybycie zdarzeń

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 upuścił zdarzenie lub dostosować czas zdarzenia do tolerancji.

Po wygenerowaniu znaków wodnych usługa może potencjalnie odbierać zdarzenia z czasem zdarzenia krótszym niż limit. Możesz skonfigurować usługę tak, aby porzuciła te zdarzenia lub dostosować czas zdarzenia do wartości limitu.

W ramach korekty element 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 różnić się od wartości w polu czasu zdarzenia i może spowodować wygenerowanie nieoczekiwanych wyników.

Obsługa odmiany czasu z podstreamami

Opisany mechanizm generowania znaku wodnego heurystyczny 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 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 globalnego dla wszystkich zdarzeń w partycji wejściowej, usługa Stream Analytics ma inny mechanizm nazywany podstreamami. W zadaniu możesz użyć podstreams, pisząc zapytanie dotyczące 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, tak aby system stosuje zasady czasu według tej kolumny. Każdy podstream dostaje swój własny niezależny znak wodny. Ten mechanizm jest przydatny, aby umożliwić generowanie danych wyjściowych w odpowiednim czasie 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.

Gdy używasz podstreams, usługa Stream Analytics stosuje okno tolerancji opóźnionych przylotów do zdarzeń przychodzących. Tolerancja opóźnionego przybycia decyduje o maksymalnej ilości, o jaką różne podbiegi mogą być od siebie oddzielone. Jeśli na przykład urządzenie 1 znajduje się na sygnaturze czasowej 1, a urządzenie 2 znajduje się w znaczniku czasu 2, najbardziej opóźniona tolerancja przylotu to Znacznik czasu 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 opóźnionego przybycia. To okno jest ustalane na 5 minut i służy do innego celu niż okno tolerancji opóźnionego przybycia.

Ponieważ usługa Azure Stream Analytics gwarantuje ukończenie wyników, 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 określa godzinę 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 pominie wszystkie zdarzenia, które są postrzegane jako mające czas zdarzenia 5 minut wcześniej niż czas przybycia. Metryka wczesnych zdarzeń wejściowych jest zwiększana, gdy zdarzenia są porzucane.

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 Zdarzenia poza kolejnością (tolerancja poza kolejnością) i Zdarzenia, które docierają z opóźnieniem (tolerancja opóźnionego przybycia). Tolerancja wczesnego przybycia jest stała i nie można jej dostosować. Te zasady czasu są używane przez usługę Stream Analytics do zapewnienia silnych gwarancji. Jednak te ustawienia czasami mają nieoczekiwane implikacje:

  1. 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 zdarzenia przychodzące są porzucane, więc żadne z nich nie będzie widoczne z danych wyjściowych.

  2. 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.

  3. 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.

  4. 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ść.

  5. 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:

  1. Z natury opóźnienie przetwarzania potoku przesyłania strumieniowego. Zwykle to opóźnienie jest nominalne.

  2. Okno tolerancji poza kolejnością wprowadziło opóźnienie, ponieważ znak wodny jest zmniejszony o rozmiar okna tolerancji.

  3. Opóźnione okno przylotu wprowadziło opóźnienie, ponieważ znak wodny jest zmniejszany o rozmiar okna tolerancji.

  4. 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:

  1. 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.

  2. 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.

  3. 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
  1. Ilustracja przedstawiająca postęp znaku wodnego przez następujące zdarzenia:

    Ilustracja znaku wodnego usługi Azure Stream Analytics

    Istotne procesy przedstawione na poprzedniej ilustracji:

    1. 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ń.

    2. 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.

    3. 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ń.

    4. 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).

    5. 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.

  2. Druga ilustracja przedstawiająca postęp znaku wodnego bez zasad wczesnego przybycia:

    Ilustracja wczesnego znaku wodnego bez wczesnego znaku wodnego usługi Azure Stream Analytics

    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.

  3. 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.

    Ilustracja znaku wodnego podsieci usługi Azure Stream Analytics

Następne kroki