МЕТКА ВРЕМЕНИ ПО

✅ Поток событий Azure Stream Analytics ✅ Fabric

Замечание

Компонент Eventstream Fabric основан на той же среде выполнения, что и Azure Stream Analytics. Поэтому основные понятия, описанные в этой статье, применимы как к Azure Stream Analytics, так и к потоку событий Fabric.

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

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

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

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

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

Syntax

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

Examples

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

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

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

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

Системы UNIX часто используют время POSIX (или Эпоха), определенное как количество миллисекундах, прошедших с 00: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

  • Last updated on