TIMESTAMP BY (Azure Stream Analytics)

  • Статья

Все события потока данных имеют связанную с ними метку времени. По умолчанию события из концентратора событий и Центр Интернета вещей метки времени определяются в зависимости от того, когда событие было получено концентратором событий или Центр Интернета вещей. События из хранилища BLOB-объектов определяются временем последнего изменения BLOB-объекта. Метка времени события не изменяется при повторном запуске или повторном запуске задания.

Для многих приложений потоковой передачи требуется точную метку времени возникновения события, а не время поступления. Например, в приложении Точки продаж могут потребоваться метки времени события, соответствующие времени регистрации платежа, а не времени, когда событие платежа достигает службы приема событий. Кроме того, геораспределённые системы и сетевые задержки могут привести к непредсказуемой задержке прибытия, что делает использование времени приложения более надежным в приложении потоковой передачи. В таких случаях предложение TIMESTAMP BY позволяет указывать пользовательские значения меток времени. Значением может быть любое поле из полезных данных события или выражение типа DATETIME. Также поддерживаются строковые значения, соответствующие любому из форматов ISO 8601 .

Обратите внимание, что использование пользовательской метки времени (предложение TIMESTAMP BY) может привести к тому, что Azure Stream Analytics будет принимать события не по порядку по отношению к их меткам времени по двум причинам:

  • У отдельных производителей событий могут быть разные системные часы (и с отклонением).
  • События от отдельных производителей событий могут быть задержаны при передаче, например из-за недоступности сети на сайте производителя.

Хотя беспорядок между производителями событий может быть большим, беспорядок в событиях от одного производителя, как правило, небольшой или даже не существует. Если запрос обрабатывает данные только от каждого производителя событий независимо друг от друга, обработка событий от каждого производителя в своем собственном временная шкала эффективнее, чем управление временными отклонениями между производителями. Azure Stream Analytics поддерживает подпотоки, указывая вложенное предложение OVER <по спецификации> , чтобы обеспечить обработку событий на независимых временных шкалах. Сведения о влиянии использования предложения OVER на обработку задания см. в разделе "Предложение OVER взаимодействует с упорядочением событий".

Синтаксис

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

Remarks

Получение метки времени события

Метку времени события можно получить в инструкции SELECT в любой части запроса с помощью свойства System.Timestamp().

Предложение OVER взаимодействует с упорядочением событий

При использовании предложения OVER изменяются несколько аспектов обработки событий с помощью Azure Stream Analytics:

  1. Максимальное отклонение от порядка применяется в одном кортеже значений по спецификации<>. То есть событие считается неупорядоченным только в том случае, если оно поступает слишком не по порядку по отношению к другим событиям от того же производителя события.

    Например, можно использовать значение "0", если события одного и того же производителя событий всегда упорядочены и приведут к немедленной обработке. С другой стороны, использование здесь больших значений приведет к задержкам обработки при ожидании сборки событий неупорядоченности.

  2. Максимальное отклонение при опозданиях применяется глобально (как если бы over не использовалось). То есть событие считается с опозданием, если выбранная им метка времени (в предложении TIMESTAMP BY) находится слишком далеко от времени прибытия.

    Обратите внимание, что использование здесь больших значений не приведет к задержкам обработки, а события по-прежнему будут обрабатываться немедленно (или в соответствии с максимальным отклонением от порядка). Значение в несколько дней не является необоснованным. Однако использование исключительно длинных значений может повлиять на объем памяти, необходимый для обработки задания.

  3. Выходные события для каждого производителя событий создаются по мере их вычисления. Это означает, что выходные события могут иметь неупорядоченные метки времени; однако они будут упорядочены в одном кортеже значений по спецификации<>.

Ограничения

Предложение TIMESTAMP BY OVER имеет следующие ограничения использования:

  1. Предложение TIMESTAMP BY OVER должно использоваться для всех входных данных запроса или не использоваться ни для одного из них.

  2. Предложение TIMESTAMP BY OVER поддерживается только с полностью параллельными заданиями или заданиями с одним разделом.

  3. Если входной поток содержит несколько секций, необходимо использовать предложение OVER вместе с предложением PARTITION BY. Столбец PartitionId должен быть указан как часть столбцов TIMESTAMP BY OVER.

  4. Если используется предложение TIMESTAMP BY OVER, имена столбцов из предложения должны использоваться в качестве ключа группирования в инструкциях GROUP BY и во всех предикатах JOIN при соединении между потоками.

  5. Столбцы, созданные в инструкции SELECT или в любых других предложениях запроса, нельзя использовать в предложении TIMESTAMP BY. Необходимо использовать поле из входных полезных данных. Например, результат CROSS APPLY нельзя использовать в качестве целевого значения TIMESTAMP BY. Однако можно использовать одно задание Azure Stream Analytics, которое выполняет CROSS APPLY, и второе задание для выполнения TIMESTAMP BY.

  6. System.Timestamp() нельзя использовать в TIMESTAMP BY, так как timestamp BY определяет значение System.Timestamp().

Примеры

Пример 1. Доступ к полю метки времени из полезных данных

Использование EntryTime поля из полезных данных в качестве метки времени события

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Пример 2. Использование времени UNIX из полезных данных в качестве метки времени события

Системы UNIX часто используют время POSIX (или Эпоха), определяемое как количество миллисекундах, прошедших с 00:00:00 utc, четверг, 1 января 1970 года.

В этом примере показано, как использовать числовое поле epochtime, содержащее эпохальное время в качестве метки времени события.

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

Пример 3. Разнородные метки времени

Представьте себе обработку разнородных потоков данных, содержащих два типа событий "A" и "B". События "A" имеют данные метки времени в поле "timestampA", а события "B" имеют метку времени в поле "timestampB".

В этом примере показано, как написать TIMESTAMP BY, чтобы иметь возможность работать с обоими типами событий и меток времени.

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

Пример 4. Обработка нескольких временных шкал в секционированных запросах

Обработка данных от разных отправителей (платных станций) без применения политик времени для разных идентификаторов платных станций. Входные данные секционируются на основе TollId.

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

См. также:

System.Timestamp()
Политики при отклонениях по времени
Рассмотрение времени в Azure Stream Analytics
Время Unix