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.
Obsługa czasu w usłudze Azure Stream Analytics to zestaw mechanizmów, które określają, jak zdarzenia przesyłania strumieniowego są znakowane czasem, porządkowane i przetwarzane na podstawie czasu wystąpienia w porównaniu do czasu przybycia. W tym artykule wyjaśniono, 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 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, który wskazuje, w jakim momencie procesor przesyłania strumieniowego pozyskał zdarzenia. Znaki wodne pozwalają systemowi wskazać wyraźny postęp w przetwarzaniu zdarzeń. Ze względu na charakter strumieni dane zdarzeń napływają nieprzerwanie, więc znaki wodne wskazują postęp do określonego punktu w strumieniu.
Pojęcie znaku wodnego to istotna kwestia. Znaki wodne umożliwiają usłudze Azure 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. Na przykład, jeśli należy wykonać ponowne zliczenie w przypadku 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 w blogu Tylera Akidau Streaming 101 i Streaming 102.
Wybieranie najlepszego czasu rozpoczęcia
Usługa Azure Stream Analytics oferuje 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 znacznik czasu jest nieobecny, zdarzenia są przetwarzane według czasu 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 czas postępuje w usłudze Azure Stream Analytics
W przypadku korzystania z czasu aplikacji postęp czasu jest oparty na zdarzeniach przychodzących. Dla systemu przetwarzania strumieniowego trudno jest określić, 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 wystąpi jakiekolwiek zdarzenie przychodzące, znak wodny reprezentuje najdalszy czas zdarzenia, jaki usługa Azure Stream Analytics dotychczas przetworzyła, pomniejszony o rozmiar okna tolerancji zdarzeń poza kolejnością.
Jeśli nie ma zdarzenia przychodzącego, znak wodny jest bieżącym szacowanym czasem przybycia pomniejszonym o okno tolerancji spóźnionego przybycia. 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 lub IoT Hub), a nie na maszynie wirtualnej usługi Azure Stream Analytics przetwarzającego 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 portalu Azure, na stronie Porządkowanie zdarzeń dla zadania usługi Stream Analytics, można skonfigurować ustawienie Zdarzenia spoza kolejności. Podczas konfigurowania tego ustawienia należy wziąć pod uwagę kompromis aktualności a tolerancją zdarzeń nieuporządkowanych w strumieniu zdarzeń.
Okno tolerancji spóźnionego przybycia jest niezbędne do utrzymania procesu 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ą doświadczać opóźnień w danych wyjściowych przy rzadkich danych wejściowych, zwłaszcza gdy używanych jest wiele partycji.
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ń i przez to są powtarzalne. Gdy szacowany czas przybycia jest określany w przypadku braku zdarzeń, usługa Azure Stream Analytics zapisuje ten czas w celu 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 wzrasta w brokerze zdarzeń wejściowych, usługa Azure Stream Analytics pomija konfiguracje.
Zdarzenia z późnym przybyciem
Zgodnie z definicją okna tolerancji opóźnienia usługa Azure Stream Analytics porównuje czas zdarzenia z czasem jego przybycia dla każdego zdarzenia przychodzącego. 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. To dostosowanie jest jedyną sytuacją, w której System.Timestamp zdarzenia może być inny niż wartość w polu czasu zdarzenia i może spowodować wygenerowanie nieoczekiwanych wyników.
Obsługuj wariację czasu za pomocą podstrumieni
Mechanizm generowania heurystycznego znaku wodnego — gdzie usługa Azure Stream Analytics śledzi postęp czasu zdarzeń, wykorzystując największy zaobserwowany znacznik czasu minus okno tolerancji — działa dobrze w większości przypadków, gdy czas jest przeważnie zsynchronizowany między różnymi nadawcami zdarzeń. Jednak w praktyce, zwłaszcza w wielu scenariuszach IoT, system ma niewielką kontrolę nad zegarem czasu nadawania zdarzeń. Nadawcy zdarzeń mogą być różnego rodzaju urządzeniami IoT w terenie, być może na różnych wersjach sprzętu oraz oprogramowania układowego.
Zamiast używać watermarku, który jest globalny dla wszystkich zdarzeń w partycji wejściowej, usługa Azure Stream Analytics ma inny mechanizm, który nazywa się podstreamami. Możesz użyć podsieci w swojej pracy, pisząc zapytanie pracy, 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 stosował 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ń.
W przypadku korzystania z podstreamów usługa Azure Stream Analytics stosuje okno tolerancji późnego przybycia do zdarzeń przychodzących. Tolerancja opóźnionego przybycia określa maksymalną odległość, o jaką różne podstrumienie danych mogą się od siebie różnić. Jeśli na przykład urządzenie 1 znajduje się w znaczniku czasu 1, a urządzenie 2 w znaczniku czasu 2, maksymalna tolerancja opóźnienia to znacznik czasu 2 minus znacznik czasu 1. Domyślne ustawienie tolerancji późnego przylotu wynosi 5 sekund, co prawdopodobnie jest zbyt małe dla urządzeń IoT z rozbieżnymi znacznikami czasu. Zacznij od 5 minut i wprowadź korekty zgodnie ze wzorcem niesymetryczności zegara urządzenia.
Wcześnie pojawiające się zdarzenia
Okno wczesnego przybycia to stała 5-minutowa tolerancja, która określa, jak wcześnie zdarzenie może pojawić się względem czasu zdarzenia, zanim Azure Stream Analytics je odrzuci. To okno służy 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 system przetwarzał pełne okno, a nie tylko w środku okna.
Usługa Azure Stream Analytics uzyskuje czas rozpoczęcia od specyfikacji zapytania. Jednak ponieważ broker zdarzeń wejściowych jest indeksowany tylko na podstawie czasu przybycia, system jest zmuszony 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 zapewnia powtarzalne przetwarzanie niezależnie od tego, z którego miejsca rozpoczynasz generowanie wyników. 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 Azure Stream Analytics mają kilka opcji zamawiania zdarzeń . Można skonfigurować dwa ustawienia w portalu Azure: ustawienie Zdarzenia poza kolejnością (tolerancja zdarzeń poza kolejnością) oraz Zdarzenia, które docierają z opóźnieniem (tolerancja dla zdarzeń z opóźnieniem). Tolerancja wczesnego przybycia jest stała i nie można jej dostosować. Usługa Azure Stream Analytics używa tych zasad czasu do zapewnienia silnych gwarancji. Jednak te ustawienia czasami mają nieoczekiwane implikacje:
Przypadkowe wysyłanie zdarzeń, które są zbyt wcześnie.
Wczesne zdarzenia zwykle nie powinny być danymi wyjściowymi. Istnieje możliwość, że wczesne zdarzenia są wysyłane do wyjścia, w przypadku, gdy zegar nadawcy działa zbyt szybko. Wszystkie zdarzenia przychodzące z wyprzedzeniem są odrzucane, więc nie zobaczysz żadnego z nich w danych wyjściowych.
Wysyłanie starych zdarzeń do usługi Event Hubs do przetworzenia przez usługę Azure Stream Analytics.
Chociaż stare wydarzenia mogą wydawać się nieszkodliwe na początku, ze względu na stosowanie tolerancji późnego przybycia, stare wydarzenia mogą zostać porzucone. Jeśli zdarzenia są zbyt stare, wartość System.Timestamp jest zmieniana podczas pozyskiwania zdarzeń. Ze względu na to zachowanie usługa Azure Stream Analytics jest lepiej odpowiednia dla scenariuszy przetwarzania zdarzeń niemal w czasie rzeczywistym niż w przypadku historycznych scenariuszy przetwarzania zdarzeń. W niektórych przypadkach można ustawić czas dla Zdarzeń, które przychodzą późno do największej możliwej wartości (20 dni), aby ominąć ten problem.
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 wielkość okna tolerancji dla zdarzeń niechronologicznych. Domyślnie tolerancja poza kolejnością jest skonfigurowana na zero (00 minut i 00 sekund). Jeśli ustawisz wartość czasu na wyższą, niezerową wartość, pierwsze dane wyjściowe zadania przesyłania strumieniowego będą opóźnione o tę wartość czasu (lub większą) z powodu obliczonego czasu pierwszego watermarku.
Dane wejściowe są rzadkie.
Jeśli w danej partycji nie ma danych wejściowych, znacznik czasowy jest obliczany jako czas przybycia pomniejszony o okno 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ślną wartością dla zdarzeń, które docierają późno jest 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ą z opóźnieniem na wysoką wartość.
Wartość elementu System.Timestamp różni się od czasu w polu czasu zdarzenia.
Jak opisano wcześniej, system dostosowuje czas zdarzenia, uwzględniając tolerancję kolejkowania lub okna tolerancji opóźnionego przybycia. Wartość Elementu System.Timestamp zdarzenia jest dostosowywana, ale pole czasu zdarzenia nie jest dostosowywane. Można go użyć do zidentyfikowania, dla których zdarzeń zostały dostosowane 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ć efekty związane z tolerancją czasu kolejności 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 nie według kolejności, które zostały porzucone lub miały dostosowane znaczniki czasu. Ta metryka jest bezpośrednio zależna od konfiguracji ustawienia Zdarzenia poza kolejnością na stronie Porządkowanie zdarzeń w zadaniu na portalu Azure. |
| Zdarzenia opóźnionych danych wejściowych | Wskazuje liczbę zdarzeń przychodzących późno ze źródła. Ta metryka obejmuje zdarzenia, które zostały porzucone lub ich znaczniki czasu zostały zmienione. Ta metryka jest bezpośrednio wpływana przez konfigurację ustawienia zdarzeń, które docierają późno na stronie Porządkowanie zdarzeń w zadaniu w portalu Azure. |
| Wczesne zdarzenia wejściowe | Wskazuje liczbę zdarzeń przybywających ze źródła, które zostały porzucone lub miały skorygowany znacznik czasu, jeśli wystąpiły wcześniej niż 5 minut przed oczekiwanym czasem. |
| Opóźnienie znaku wodnego | Wskazuje opóźnienie zadania przetwarzania danych przesyłanych strumieniowo. Aby uzyskać więcej informacji, zobacz następującą sekcję. |
Szczegóły opóźnienia znaku wodnego
Usługa Azure Stream Analytics oblicza metrykę opóźnienia znacznika wodnego jako czas zegara ściennego węzła przetwarzania pomniejszony o największy znacznik wodny, który widział do tej pory. Aby uzyskać więcej informacji, zobacz także opóźnienie watermarku.
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 w przetwarzaniu potoku 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.
Późne okno przybycia wprowadziło opóźnienie, ponieważ znacznik czasowy jest zmniejszany przez rozmiar okna tolerancji.
Rozbieżność zegara węzła przetwarzania generującego metrykę.
Istnieje kilka innych ograniczeń zasobów, które mogą spowodować spowolnienie potoku przesyłania strumieniowego. Metryka opóźnienia znaku wodnego może wzrosnąć z następujących powodów:
Za mało zasobów przetwarzania w usłudze Azure Stream Analytics, aby obsłużyć ilość zdarzeń wejściowych. Aby skalować zasoby w górę, zobacz Zrozumienie 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 jednostek przepustowości w górę usługi Azure Event Hubs.
Wyjścia danych (takie jak Azure SQL Database, Blob Storage lub Power BI) nie są przydzielane z wystarczającą przepustowością, więc są dławione. 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 progresji znacznika wody jako jedynego wyzwalacza, aby generować zdarzenia wyjściowe. Ponieważ znak wodny jest generowany na podstawie danych wejściowych, można go odtworzyć podczas odzyskiwania po awarii, a także w czasie ponownego przetwarzania zainicjowanego przez użytkownika. W przypadku korzystania z okienkowych agregacji, usługa generuje tylko dane wyjściowe na końcu okien. W niektórych przypadkach możesz chcieć widzieć częściowe agregacje generowane 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 łączy się z 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 znajdują się poniżej na wykresie. Zwróć uwagę, że czas zdarzenia i czas przybycia różnią się, czasami są zgodne, a czasami nie.
| Czas zdarzenia | Godzina przyjazdu | DeviceId |
|---|---|---|
| 12:07 | 12:07 | urządzenie1 |
| 12:08 | 12:08 | urządzenie2 |
| 12:17 | 12:11 | urządzenie1 |
| 12:08 | 12:13 | Urządzenie3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | urządzenie3 |
| 12:17 | 12:18 | urządzenie2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | urządzenie3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | urządzenie3 |
Na tej ilustracji używane są następujące tolerancje:
- Okno wczesnego przyjazdu wynosi 5 minut
- Opóźnione okno przylotu wynosi 5 minut
- Okno ponownego zamówienia wynosi 2 minuty
Ilustracja przedstawiająca postęp znaku wodnego poprzez te zdarzenia:
Istotne procesy przedstawione na poprzedniej grafice:
Pierwsze zdarzenie (urządzenie1) oraz drugie zdarzenie (urządzenie2) mają dopasowane czasy i są przetwarzane bez korekt. Znak wodny przesuwa się na każdym zdarzeniu.
Po przetworzeniu trzeciego zdarzenia (device1) godzina przybycia (12:11) poprzedza czas zdarzenia (12:17). Wydarzenie przybyło 6 minut wcześniej, więc zostało odrzucone ze względu na tolerancję wczesnego przybycia wynoszącą 5 minut.
Znak wodny nie przesuwa się w przypadku wczesnego zdarzenia.
Czwarte wydarzenie (urządzenie3) i piąte wydarzenie (urządzenie1) mają zsynchronizowane czasy i są przetwarzane bez konieczności korekty. Znak wodny przesuwa się przy każdym zdarzeniu.
Po przetworzeniu szóstego zdarzenia (device3) czas przybycia (12:17) i czas zdarzenia (12:12) są niższe od poziomu limitu. Czas zdarzenia jest dostosowywany do poziomu znacznika 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 został dostosowany (12:22), który przekracza znak wodny (12:21), więc nie stosuje się dalszych korekt.
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, znacznie podnoszą graniczny punkt czasowy. Zwróć uwagę, że trzecie zdarzenie (deviceId1 o godzinie 12:11) nie zostało pominięte w tym scenariuszu, a znak wodny jest podniesiony do 12:15. Czas czwartego zdarzenia jest przesunięty o 7 minut do przodu (z 12:08 na 12:15) w wyniku tego zmiany.
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.
