Рассмотрение времени в Azure Stream Analytics

В этой статье вы узнаете, какие решения следует принимать при проектировании, чтобы устранить практические проблемы, касающиеся времени, в заданиях Azure Stream Analytics. Проектные решения, касающиеся восприятия времени, тесно связаны с факторами упорядочения событий.

Базовые понятия о времени

Чтобы лучше представлять рамки обсуждения, давайте определим некоторые базовые понятия:

• Время события: время, когда произошло исходное событие. Например, двигающийся по шоссе автомобиль приближается к пункту взимания дорожных сборов.

• Время обработки: время, когда событие достигает системы обработки и наблюдается. Например, когда датчик на пункте взимания дорожных сборов обнаруживает автомобиль, а компьютерная система обрабатывает данные.

• Водяной знак: маркер времени события, указывающий до того, какие события были входящего трафика в обработчик потоковой передачи. Метки времени позволяют системе указывать ход выполнения при приеме событий. Входящий поток данных событий никогда не останавливается, поэтому метки времени показывают прогресс до определенной точки в потоке.

  Концепция меток времени очень важна. Они позволяют Stream Analytics определить, когда система может производить полные, правильные и повторяемые результаты, которые не нужно отменять. Обработка может быть выполнена предсказуемым и повторяемым способом. Например, если необходимо выполнить пересчет для какого-либо условия обработки ошибок, метки времени могут быть безопасными начальными и конечными точками.

Дополнительные ресурсы по этой теме доступны в записях блога Тайлера Акидау (Tyler Akidau), посвященных потоковой передаче (101 и 102).

Выбор наиболее подходящего времени запуска

Stream Analytics предоставляет пользователям два варианта выбора времени события: время получения и время приложения.

Время прибытия

Время получения присваивается в источнике входных данных, когда событие достигает источника. Узнать время получения можно с помощью свойства EventEnqueuedUtcTime для входных данных Центров событий, свойства IoTHub.EnqueuedTime для входных данных Центра Интернета вещей и свойства BlobProperties.LastModified для входных данных большого двоичного объекта.

Время получения используется по умолчанию. Оно лучше всего подходит для сценариев архивации данных, в которых не требуется временная логика.

Время приложения (также называется временем события).

Время приложения присваивается при создании события и является частью полезных данных события. Для обработки событий по времени приложения используйте предложение Timestamp by в запросе SELECT. Если предложение Timestamp by отсутствует, то события обрабатываются по времени получения.

Важно использовать метку времени в полезных данных, если используется временная логика для учета задержек в исходной системе или в сети. Время, назначенное событию, доступно в SYSTEM.TIMESTAMP.

Течение времени в Azure Stream Analytics

При использовании времени приложения ход времени основывается на входящих событиях. Системе обработки потоковых данных трудно определить отсутствие событий или их задержку. По этой причине Azure Stream Analytics создает для каждого раздела входных данных эвристические метки времени одним из следующих способов:

• Каждый раз при обнаружении входящего события водяной знак будет представлять наибольшее время события, наблюдавшееся Azure Stream Analytics до сих пор, за вычетом размера интервала для событий, полученных в неправильном порядке.

• Если входящего события нет, то водяной знак — это текущее предполагаемое время получения за вычетом допустимого интервала поступления с задержкой. Предполагаемое время получения — это время, которое прошло с момента последнего появления входного события, плюс время поступления этого события.

  Время получения можно определить только предположительно, так как реальное время получения создается брокером входных событий, таким как Центры событий, а не виртуальной машиной Azure Stream Analytics, которая обрабатывает события.

Помимо создания водяных знаков проектная схема служит двум дополнительным целям.

1. Система создает результаты за отведенное время, независимо от наличия входящих событий.

   Вы можете контролировать интервал получения результатов выходных данных. На портале Azure на станице Упорядочение событий задания Stream Analytics можно настроить параметр События, поступающие не по порядку. При настройке этого параметра учтите компромисс между своевременностью и интервалом для событий, полученных в неправильном порядке, в потоке событий.

   Допустимый интервал поступления с задержкой необходим для формирования водяных знаков даже при отсутствии входящих событий. Иногда могут возникать периоды, когда входные события не поступают, например, когда входной поток разреженный. Эта проблема усугубляется использованием нескольких секций в брокере входных событий.

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

2. Реакция системы на событие должна быть повторяемой. Повторяемость является важным свойством системы обработки потоковых данных.

   Водяной знак формируется на основе времени получения и времени приложения. Оба этих времени сохраняются в брокере событий, и поэтому они являются повторяемыми. Если время получения оценивается при отсутствии событий, журналы Azure Stream Analytics оценивают ожидаемое время получения с точки зрения повторяемости во время воспроизведения для восстановления после сбоев.

Когда вы используете время получения в качестве времени события, вам не обязательно настраивать интервал для событий, полученных в неправильном порядке, и допустимый интервал поступления с задержкой. Azure Stream Analytics просто игнорирует конфигурации, так как время получения гарантированно возрастает в брокере входных событий.

События, поступающие с задержкой

Исходя из определения допустимого интервала поступления с задержкой, для каждого входного события Azure Stream Analytics сравнивает время события и время получения. Если время события выходит за пределы допустимого интервала, можно настроить систему для удаления события или настроить время события в пределах допустимого интервала.

После формирования водяных знаков служба может потенциально получать события со временем, предшествующим водяному знаку. Вы можете настроить службу так, чтобы либо отклонять эти события, либо корректировать время события в соответствии со значением водяного знака.

В рамках корректировки параметру System.Timestamp события присваивается новое значение, но само поле Время события не изменяется. Эта корректировка является единственным сценарием, в котором время System.Timestamp события может отличаться от значения в поле времени события и может привести к созданию непредвиденных результатов.

Обработка разных показателей времени с помощью подпотоков

Описанный здесь механизм создания эвристического водяного знака работает в большинстве случаев, в которых время в основном синхронизируется между различными отправителями событий. Однако в реальной жизни, особенно во многих сценариях Интернета вещей, система не контролирует время в отправителях событий. Отправителями событий могут быть всевозможные устройства в той или иной отрасли, у которых могут быть разные версии оборудования и программного обеспечения.

Вместо использования глобального водяного знака для всех событий в разделе входных данных Stream Analytics применяет другой механизм, который называется подпотоками. Чтобы использовать подпотоки в задании, напишите запрос задания, указав в нем предложение TIMESTAMP BY и ключевое слово OVER. Чтобы назначить подпоток, укажите имя ключевого столбца, например deviceid, после ключевого слова OVER, чтобы система применила политики времени для этого столбца. Каждый подпоток данных получает собственную независимую метку времени. Этот механизм нужен для своевременного создания выходных данных при работе с большими отклонениями часов и задержками в сети между отправителями событий.

Подпотоки — это уникальное решение, предоставляемое Azure Stream Analytics. Они не предлагаются другими системами обработки потоковых данных.

Когда используются подпотоки, Stream Analytics применяет интервал событий, наступивших с задержкой, для входных событий. Допустимый интервал поступления с задержкой определяет максимальное значение, которое может разделять разные подпотоки. Например, если устройство 1 находится на метке времени 1, а устройство 2 — на метке времени 2, то максимальный допустимый интервал получения с задержкой равен разности метки времени 2 и метки времени 1. Значение по умолчанию (5 секунд), скорее всего, слишком мало для устройств, имеющих разные метки времени. Мы советуем начать с 5 минут и вносить изменения в соответствии со схемой разницы в показаниях часов устройства.

События, поступающие рано

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

Так как Azure Stream Analytics гарантирует получение полных результатов, вы можете указать только время запуска задания в качестве первого времени вывода задания, а не времени ввода. Время запуска задания требуется для обработки всего интервала, а не только с его середины.

Затем Stream Analytics извлекает время начала из спецификации запроса. Тем не менее, так как брокер входных событий индексируется только по времени получения, система должна преобразовать начальное время события во время получения. Система может начать обрабатывать события с этого момента в брокере входных событий. С ограничением интервала раннего поступления преобразование не представляет никаких трудностей. Это начальное время события минус 5-минутный интервал раннего поступления. Это вычисление также означает, что система отклоняет все события, время которых на 5 минут превышает время получения. Значение метрики ранних входных событий увеличивается при удалении событий.

Эта концепция позволяет обеспечить возможность повторения обработки независимо от того, откуда начинается вывод данных. Без такого механизма невозможно гарантировать повторяемость, так как он есть у многих других систем потоковой передачи.

Побочные эффекты использования интервалов для событий, полученных в неправильном порядке

В заданиях Stream Analytics существует несколько параметров упорядочения событий. Два параметра можно настроить на портале Azure: параметр События, поступающие не по порядку (интервал для событий, полученных в неправильном порядке) и параметр События, поступающие с опозданием (допустимый интервал поступления с задержкой). Интервал раннего поступления фиксирован, и его нельзя скорректировать. Эти политики времени используются в Stream Analytics для предоставления надежных гарантий. Тем не менее в этих параметрах есть некоторые неожиданные последствия:

1. Случайная слишком ранняя отправка событий.

   Обычно ранние события не выводятся. Ранние события могут отправляться на вывод, если часы отправителя работают слишком быстро. Все ранние поступающие события отклоняются, поэтому вы не увидите их во выходных данных.

2. Отправка старых событий в Центры событий для обработки в Azure Stream Analytics.

   Хотя сначала может казаться, что старые события не могут причинить вреда из-за допустимого интервала поступления с задержкой, они могут быть отклонены. Если события слишком старые, значение System.Timestamp изменяется во время приема событий. Из-за этого поведения в настоящее время Azure Stream Analytics лучше подходит для сценариев обработки событий в режиме, близком к реальному времени, а не для сценариев обработки событий журнала. В некоторых случаях для обхода этого поведения вы можете задать для параметра События, поступающие с опозданием наибольшее возможное значение —20 дней.

3. Выходные данные задерживаются.

   Первая метка времени создается в вычисленное время — максимальное время события, которое до сих пор наблюдала система, минус интервал для событий, полученных в неправильном порядке. По умолчанию для интервала для событий, полученных в неправильном порядке, установлено нулевое значение (00 минут, 00 секунд). При установке более высокого (ненулевого) значения времени первый вывод данных задания потоковой передачи задерживается на это значение времени (или большее) из-за первой вычисленной метки времени.

4. Входные данные являются разреженными.

   Если в данном разделе входные данные отсутствуют, метка времени вычисляется следующим образом: время получения минус интервал для событий, наступивших с задержкой. Таким образом, если входные события редки и разрежены, выходные данные могут задерживаться на этот период времени. Значение по умолчанию для параметра События, поступающие с опозданием составляет 5 секунд. Например, следует ожидать некоторую задержку при отправке событий входных данных по одному за раз. Задержки могут стать большими, если задать для параметра События, поступающие с опозданием большее значение.

5. Значение System.Timestamp отличается от времени в поле времени события.

   Как было описано выше, система корректирует время события с учетом интервала для событий, полученных в неправильном порядке, или интервала для событий, наступивших с задержкой. Корректируется значение System.Timestamp события, но не значение поля времени события. Это можно использовать, чтобы указать, для каких событий были скорректированы метки времени. Если система изменила метку времени из-за одного из допустимых интервалов, обычно они одинаковы.

Метрики для наблюдения

Вы можете наблюдать последствия использования интервалов для событий, полученных в неправильном порядке, с помощью метрик задания Azure Stream Analytics. Ниже приведены соответствующие метрики.

Сведения о предельной задержке

Метрика Watermark delay (Предельная задержка) вычисляется как физическое время обрабатываемого узла минус наибольшая метка времени, возникшая до этого. Дополнительные сведения доступны в записи блога о предельной задержке.

Есть несколько причин, из-за которых это значение метрики больше 0 при нормальной работе:

1. Задержка обработки конвейера потоковой передачи. Обычно эта задержка является ничтожно малой.

2. Из-за интервала для событий, полученных в неправильном порядке, возникла задержка, так как метка времени снижена до интервала для таких событий.

3. Из-за интервала поступления с задержкой возникла задержка, так как метка времени снижена до размера такого интервала.

4. Разница в показаниях часов узла обработки, создающего метрику.

Существует ряд других ограничений ресурсов, которые могут привести к замедлению конвейера потоковой передачи. Метрика предельной задержки может увеличиваться из-за:

1. Нехватка ресурсов для обработки входных событий в Stream Analytics. Дополнительные сведения об увеличении масштаба см. в статье Обзор и настройка единиц потоковой передачи.

2. В брокерах входных событий недостаточно пропускной способности, поэтому они регулируются. Возможные решения см. в статье Автоматическое масштабирование единиц пропускной способности Центров событий Azure.

3. Приемники выходных данных не подготавливаются с достаточной емкостью, поэтому они регулируются. Возможные решения значительно варьируются в зависимости от вида используемой службы вывода.

Частота событий вывода

Azure Stream Analytics использует прогресс метки времени в качестве единственного триггера для создания выходных событий. Так как метка времени является производной от входных данных, она повторяется во время восстановления после сбоя, а также при повторной обработке, инициированной пользователем. При использовании агрегатов данных на основе периодов служба создает выходные данные только в конце интервалов. В некоторых случаях пользователям может потребоваться просмотреть частичные агрегаты, созданные в интервалах. Частичные агрегаты в настоящее время не поддерживаются в Azure Stream Analytics.

В других решениях потоковой передачи выходные события можно материализовать в различных точках активации, в зависимости от внешних обстоятельств. В некоторых решениях возможно, что выходные события для данного интервала времени могут создаваться несколько раз. По мере обработки входных значений результаты агрегации становятся более точными. События сначала предполагаются, а через время пересматриваются. Например, когда определенное устройство находится в автономном режиме, система может использовать предположительное значение. Позднее это же устройство подключится к сети. Затем фактические данные событий могут быть включены во входной поток. Результаты обработки этого временного окна дают более точные выходные данные.

Примеры меток времени

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

В этой таблице показан пример данных, которые представлены на диаграмме ниже. Обратите внимание, что время события и время получения различаются (иногда совпадают, а иногда — нет).

На этой иллюстрации используются следующие отклонения:

• Интервалы раннего поступления составляют 5 минут.
• Интервал позднего поступления составляет 5 минут.
• Окно изменения порядка — 2 минуты.

1. Иллюстрация того, как метка времени изменяется вместе с этими событиями:

   

   Важные процессы, показанные на предыдущем рисунке:

   1. Время первого события (device1) и второго события (device2) выровнены и обрабатываются без корректировки. Метка времени изменяется для каждого события.

   2. При обработке третьего события (device1) время получения (12:11) предшествует времени события (12:17). Событие прибывает на 6 минут раньше, поэтому оно отклоняется из-за 5-минутного интервала раннего поступления.

      Метка времени не двигается в случае раннего события.

   3. Время четвертого события (device3) и пятого события (device1) выровнены и обрабатываются без корректировки. Метка времени изменяется для каждого события.

   4. При обработке шестого события (device3) время получения (12:17) и время события (12:12) находятся ниже уровня метки времени. Время события корректируется до уровня метки времени (12:17).

   5. При обработке двенадцатого события (device3) время получения (12:27) — на 6 минут раньше времени события (12:21). Применяется политика позднего получения. Время события скорректировано (12:22) и находится ниже метки времени (12:21), поэтому дальнейшая корректировка не применяется.

2. Вторая иллюстрация метки времени, которая изменяется без политики раннего получения:

   

   В этом примере политика раннего получения не применяется. События-выброс, которые поступили раньше, значительно увеличивают метку времени. Обратите внимание, что третье событие (deviceId1 в 12:11) в этом сценарии не отклоняется, а метка времени поднимается до 12:15. Как результат четвертое время события корректируется вперед на 7 минут (с 12:08 до 12:15).

3. На окончательной иллюстрации используются подпотоки (OVER DeviceId). Отслеживается несколько меток времени, по одной на поток. Как результат количество событий со скорректированным временем меньше.

   

Следующие шаги

• Рассмотрение порядка событий Azure Stream Analytics

• Метрики заданий Azure Stream Analytics