TIMESTAMP BY (Azure Stream Analytics)

Wszystkie zdarzenia strumienia danych mają skojarzony znacznik czasu. Domyślnie zdarzenia z centrum zdarzeń i IoT Hub są znacznikami czasu na podstawie czasu odebrania zdarzenia przez centrum zdarzeń lub IoT Hub; zdarzenia z usługi Blob Storage są znacznikami czasu ostatniej modyfikacji obiektu blob. Sygnatura czasowa zdarzenia nie zmienia się, jeśli ponownie uruchomisz lub ponownie uruchomisz zadanie.

Wiele aplikacji do przesyłania strumieniowego wymaga użycia dokładnego znacznika czasu wystąpienia zdarzenia, a nie czasu przybycia. Na przykład w aplikacji Punkt sprzedaży może być konieczne znaczniki czasu zdarzenia odpowiadające czasowi zarejestrowania płatności, a nie czas, w którym zdarzenie płatności osiągnie usługę pozyskiwania zdarzeń. Ponadto systemy rozproszone geograficznie i opóźnienia sieci mogą przyczynić się do nieprzewidywalnych czasów przybycia, dzięki czemu użycie czasu aplikacji jest bardziej niezawodne w aplikacji przesyłania strumieniowego. W takich przypadkach klauzula TIMESTAMP BY umożliwia określenie niestandardowych wartości sygnatury czasowej. Wartość może być dowolnym polem z ładunku zdarzenia lub wyrażeniem typu DATETIME. Obsługiwane są również wartości ciągów zgodne z dowolnym formatem ISO 8601 .

Należy pamiętać, że użycie niestandardowego znacznika czasu (klauzula TIMESTAMP BY) może spowodować, że usługa Azure Stream Analytics pozyskuje zdarzenia poza kolejnością w odniesieniu do ich sygnatur czasowych z dwóch powodów:

• Indywidualni producenci zdarzeń mogą mieć różne (i niesymetryczne) zegary systemowe.
• Zdarzenia od poszczególnych producentów zdarzeń mogą być opóźnione podczas przesyłania, na przykład przez niedostępność sieci w witrynie producenta.

Podczas gdy zaburzenia między producentami zdarzeń mogą być duże, zaburzenia w ramach zdarzeń od jednego producenta jest zazwyczaj małe, a nawet nieistniejące. W przypadku, gdy zapytanie przetwarza tylko dane od każdego producenta zdarzeń niezależnie, obsługa zdarzeń od każdego producenta na własnej osi czasu jest wydajniejsza niż zarządzanie niesymetrycznością czasu między producentami. Usługa Azure Stream Analytics obsługuje podstreamy, określając klauzulę podrzędną OVER <over spec> , aby umożliwić przetwarzanie zdarzeń na niezależnych osiach czasu. Zobacz "Klauzula OVER współdziała z porządkowaniem zdarzeń", aby uzyskać wpływ użycia klauzuli OVER na przetwarzanie zadania.

Składnia

TIMESTAMP BY scalar_expression [OVER <over spec> ]  
      
<over spec> ::= 
      { column_name | expression } [,...n ]  

Uwagi

Pobieranie znacznika czasu zdarzenia

Znacznik czasu zdarzenia można pobrać w instrukcji SELECT w dowolnej części zapytania przy użyciu właściwości System.Timestamp().

Klauzula OVER współdziała z kolejnością zdarzeń

Gdy jest używana klauzula OVER, kilka aspektów przetwarzania zdarzeń przez usługę Azure Stream Analytics jest modyfikowanych:

1. Maksymalna tolerancja poza kolejnością jest stosowana w ramach pojedynczej <krotki wartości ponad specyfikacją>. Oznacza to, że zdarzenie jest uznawane za poza kolejnością tylko wtedy, gdy dociera zbyt dużo poza kolejność w odniesieniu do innych zdarzeń od tego samego producenta zdarzeń.

   Na przykład wartość "0" może być używana, jeśli zdarzenia od tego samego producenta zdarzeń są zawsze uporządkowane i spowoduje natychmiastowe przetwarzanie. Z drugiej strony użycie dużych wartości spowoduje wprowadzenie opóźnień przetwarzania podczas oczekiwania na zebranie zdarzeń poza kolejnością.

2. Maksymalna tolerancja opóźnionych przylotów jest stosowana globalnie (tak jak w przypadku braku użycia over). Oznacza to, że zdarzenie jest uznawane za opóźnione, jeśli wybrany znacznik czasu (w klauzuli TIMESTAMP BY) jest zbyt daleko od czasu przybycia.

   Należy pamiętać, że użycie dużych wartości w tym miejscu nie spowoduje wprowadzenia opóźnień przetwarzania, a zdarzenia będą nadal przetwarzane natychmiast (lub zgodnie z maksymalną tolerancją poza kolejnością). Wartość kilku dni nie jest nierozsądna. Jednak użycie wyjątkowo długich wartości może mieć wpływ na ilość pamięci wymaganej do przetworzenia zadania.

3. Zdarzenia wyjściowe dla każdego producenta zdarzeń są generowane w miarę ich obliczania, co oznacza, że zdarzenia wyjściowe mogą mieć znaczniki czasu poza kolejnością; jednak będą one w kolejności w ramach pojedynczej <krotki wartości ponad specyfikacją>.

Ograniczenia i ograniczenia

Klauzula TIMESTAMP BY OVER ma następujące ograniczenia użycia:

1. Klauzula TIMESTAMP BY OVER musi być używana dla wszystkich danych wejściowych zapytania lub nie jest używana dla żadnego z nich.

2. Klauzula TIMESTAMP BY OVER jest obsługiwana tylko w przypadku zadań w pełni równoległych lub zadań z jedną partycją.

3. Jeśli strumień wejściowy ma więcej niż jedną partycję, klauzula OVER musi być używana razem z klauzulą PARTITION BY. Kolumna PartitionId musi być określona jako część kolumn TIMESTAMP BY OVER.

4. Jeśli jest używana klauzula TIMESTAMP BY OVER, nazwy kolumn z klauzuli muszą być używane jako klucz grupowania w instrukcjach GROUP BY i we wszystkich predykatach JOIN podczas łączenia między strumieniami.

5. Kolumny utworzone w instrukcji SELECT lub w innych klauzulach zapytania nie mogą być używane w klauzuli TIMESTAMP BY. Należy użyć pola z ładunku wejściowego. Na przykład wynik FUNKCJI CROSS APPLY nie może być używany jako wartość docelowa TIMESTAMP BY. Można jednak użyć jednego zadania usługi Azure Stream Analytics, które wykonuje operację CROSS APPLY, i użyć drugiego zadania do wykonania sygnatury CZASOWEJ BY.

6. Nie można używać elementu System.Timestamp() w sygnaturze CZASOWEJ BY, ponieważ funkcja TIMESTAMP BY określa wartość Elementu System.Timestamp().

Przykłady

Przykład 1 — uzyskiwanie dostępu do pola znacznika czasu z ładunku

Użyj EntryTime pola z ładunku jako znacznika czasu zdarzenia

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime  

Przykład 2 — użyj czasu systemu UNIX z ładunku jako znacznika czasu zdarzenia

Systemy UNIX często używają czasu POSIX (lub epoki) zdefiniowanego jako liczba milisekund, które upłynęły od 00:00:00 czasu uniwersalnego koordynowanego (UTC), czwartek, 1 stycznia 1970.

W tym przykładzie pokazano, jak używać pola liczbowego "epochtime" zawierającego czas epoki jako sygnaturę czasową zdarzenia.

SELECT  
      System.Timestamp(),  
      LicensePlate,  
      State  
FROM input TIMESTAMP BY DATEADD(millisecond, epochtime, '1970-01-01T00:00:00Z')  

Przykład 3 — heterogeniczne znaczniki czasu

Wyobraź sobie przetwarzanie heterogenicznych strumieni danych zawierających dwa typy zdarzeń "A" i "B". Zdarzenia "A" mają dane sygnatury czasowej w polu "timestampA", a zdarzenia "B" mają znacznik czasu w polu "timestampB".

W tym przykładzie pokazano, jak napisać sygnaturę CZASOWA BY, aby móc pracować z obydwoma typami zdarzeń/sygnaturami czasowymi.

SELECT  
      System.Timestamp(),  
      eventType,  
      eventValue,  
FROM input TIMESTAMP BY  
      (CASE eventType   
            WHEN 'A' THEN timestampA  
            WHEN 'B' THEN timestampB  
      ELSE NULL END) 

Przykład 4 — obsługa wielu osi czasu w zapytaniu podzielonym na partycje

Przetwarzaj dane od różnych nadawców (stacji płatnych) bez stosowania zasad czasu w różnych identyfikatorach stacji opłat drogowych. Dane wejściowe są partycjonowane na podstawie identyfikatora TollId.

SELECT
      TollId,
      COUNT(*) AS Count
FROM input
      TIMESTAMP BY EntryTime OVER TollId, PartitionId
      PARTITION BY PartitionId
GROUP BY TUMBLINGWINDOW(minute,3), TollId, PartitionId

Zobacz też

System.Timestamp()
Zasady niesymetryczności czasu
Omówienie obsługi czasu w usłudze Azure Stream Analytics
Czas systemu Unix