Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Обработка времени в Azure Stream Analytics — это набор механизмов, определяющих, как события потоковой передачи помечаются временными метками, упорядочиваются и обрабатываются на основе времени их возникновения и на основе времени их поступления. В этой статье объясняется, как выбрать варианты разработки для решения практических задач по обработке времени в заданиях Azure Stream Analytics. Проектные решения, касающиеся обработки времени, тесно связаны с факторами упорядочения событий.
Базовые понятия о времени
Чтобы лучше представлять рамки обсуждения, давайте определим некоторые базовые понятия:
Время события: время, когда происходит исходное событие. Например, двигающийся по шоссе автомобиль приближается к пункту взимания дорожных сборов.
Время обработки: время, когда событие достигает системы обработки и наблюдается. Например, когда датчик на пункте взимания дорожных сборов обнаруживает автомобиль, а компьютерная система обрабатывает данные.
Водяной знак: маркер времени события, указывающий, до какого момента обработчик потоковой передачи обработал события. Системные водяные знаки позволяют чётко отслеживать прогресс при обработке событий. Входящий поток данных событий никогда не останавливается, поэтому метки времени показывают прогресс до определенной точки в потоке.
Концепция меток времени очень важна. Водяные знаки позволяют Azure Stream Analytics определять, когда система может создавать полные, правильные и повторяемые результаты, которые не нужно изменять. Обработка может быть выполнена предсказуемым и повторяемым способом. Например, если необходимо выполнить пересчет для какого-либо условия обработки ошибок, метки времени могут быть безопасными начальными и конечными точками.
Дополнительные ресурсы по этой теме доступны в записях блога Тайлера Акидау (Tyler Akidau), посвященных потоковой передаче (101 и 102).
Выбор наиболее подходящего времени запуска
Azure 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, обрабатывающей события.
Помимо создания водяных знаков проектная схема служит двум дополнительным целям.
Система создает результаты за отведенное время, независимо от наличия входящих событий.
Вы можете контролировать интервал получения результатов выходных данных. На портале Azure на станице Упорядочение событий задания Stream Analytics можно настроить параметр События, поступающие не по порядку. При настройке этого параметра учтите компромисс между своевременностью и допуском на выходящие из порядка события в потоке событий.
Допустимый интервал поступления с задержкой необходим для формирования водяных знаков даже при отсутствии входящих событий. Иногда может возникнуть период, когда входящие события не приходят, например, когда поток ввода события разрежен. Эта проблема усугубляется использованием нескольких секций в брокере входных событий.
Потоковые системы обработки данных без окна допустимости позднего прибытия могут страдать от отложенных выходных данных при разреженности входных данных и использовании нескольких разделов.
Реакция системы на событие должна быть повторяемой. Повторяемость является важным свойством системы обработки потоковых данных.
Водяной знак формируется на основе времени прибытия и времени применения. Обе сущности сохраняются в брокере событий и потому становятся воспроизводимыми. Если время прибытия оценивается при отсутствии событий, журналы Azure Stream Analytics фиксируют ожидаемое время прибытия для повторяемости во время воспроизведения для восстановления после сбоев.
Если вы решили использовать время прибытия в качестве времени события, вам не нужно настраивать допустимое нарушение порядка и допустимое опоздание. Так как время прибытия гарантированно увеличивается в брокере событий ввода, Azure Stream Analytics игнорирует конфигурации.
События, поступающие с задержкой
Исходя из определения допустимого интервала поступления с задержкой, для каждого входного события Azure Stream Analytics сравнивает время события и время получения. Если время события находится за пределами окна терпимости, можно настроить систему для удаления события или настройки времени события в пределах допустимости.
После формирования водяных знаков служба может потенциально получать события с временем меньше, чем у водяного знака. Вы можете настроить службу так, чтобы либо отклонять эти события, либо корректировать время события в соответствии со значением водяного знака.
В рамках корректировки для параметра System.Timestamp события задано новое значение, но само поле времени события не изменяется. Эта корректировка является единственной ситуацией, когда метка события System.Timestamp может отличаться от значения в поле времени события и может привести к возникновению непредвиденных результатов.
Обработка вариации времени использованием подпотоков
Механизм генерации эвристических временных меток, где Azure Stream Analytics отслеживает прогресс времени события, используя наибольшую наблюдаемую метку времени минус окно допустимого отклонения, хорошо работает в большинстве случаев, если время в основном синхронизировано между различными отправителями событий. Однако в реальной жизни, особенно во многих сценариях Интернета вещей, система имеет ограниченный контроль над временем на отправителях событий. Отправителем событий могут быть все виды устройств Интернета вещей в поле, возможно, в разных версиях оборудования и встроенного ПО устройства.
Вместо использования подложки, которая является глобальной для всех событий во входной секции, Azure Stream Analytics имеет другой механизм, называемый подпотоками. Вложенные потоки можно использовать в задании, написав запрос задания, использующий предложение TIMESTAMP BY и ключевое слово OVER. Чтобы указать подпоток, укажите имя ключевого столбца после ключевого слова
При использовании подпотоков Azure Stream Analytics применяет окно допустимой задержки для обработки запоздалого прибытия к входящим событиям. Допустимый интервал поступления с задержкой определяет максимальное расстояние, которое может разделять разные подпотоки. Например, если устройство 1 находится на метке времени 1, а устройство 2 — на метке времени 2, максимальный допустимый срок запаздывания — это метка времени 2 минус метка времени 1. Установка допустимого опоздания по умолчанию составляет 5 секунд, что, вероятно, слишком мало для устройств Интернета вещей с расходящимися метками времени. Начните с 5 минут и внесите изменения в соответствии с шаблоном размыка часов устройства.
События, поступающие рано
Окно раннего прибытия — это фиксированный 5-минутный допуск, который определяет, насколько заранее событие может прибыть относительно времени события, прежде чем Azure Stream Analytics его отбросит. Это окно служит другой целью, отличной от периода допустимости прибытия.
Так как Azure Stream Analytics гарантирует получение полных результатов, вы можете указать только время запуска задания в качестве первого времени вывода задания, а не времени ввода. Время начала задания требуется, чтобы система обрабатывала полное окно, а не только с середины окна.
Azure Stream Analytics получает время начала из спецификации запроса. Тем не менее, так как брокер входных событий индексируется только по времени получения, система должна преобразовать начальное время события во время получения. Система может начать обрабатывать события с этого момента в брокере входных событий. С ограничением интервала раннего поступления преобразование не представляет никаких трудностей. Это начальное время события минус 5-минутный интервал раннего поступления. Это вычисление также означает, что система отклоняет все события, время которых на 5 минут превышает время получения. Значение метрики ранних входных событий увеличивается при удалении событий.
Эта концепция гарантирует, что обработка повторяется независимо от того, откуда начинается вывод. Без такого механизма невозможно гарантировать повторяемость, так как многие другие системы потоковой передачи утверждают, что они делают.
Побочные эффекты временных допусков упорядочивания событий
Задания Azure Stream Analytics имеют несколько вариантов упорядочивания событий . Два параметра можно настроить на портале Azure: параметр События, поступающие не по порядку (интервал для событий, полученных в неправильном порядке) и параметр События, поступающие с опозданием (допустимый интервал поступления с задержкой). Допустимый предел раннего прибытия установлен и не может быть изменён. Azure Stream Analytics использует эти политики времени для обеспечения надежных гарантий. Тем не менее в этих параметрах есть некоторые неожиданные последствия:
Случайная слишком ранняя отправка событий.
Ранние события обычно не должны выводиться. Возможно, что ранние события отправляются в выходные данные, если часы отправителя идут слишком быстро. Все ранние события отсекаются, поэтому вы не увидите их в выходных данных.
Отправка старых событий в Центры событий для обработки в Azure Stream Analytics.
Хотя сначала старые события могут показаться безвредными, из-за применения допуска задержки прибытия, старые события могут быть отброшены. Если события слишком старые, значение System.Timestamp изменяется во время приема событий. Из-за этого Azure Stream Analytics лучше подходит для сценариев обработки событий почти в реальном времени, чем для сценариев обработки исторических событий. В некоторых случаях для обхода этого поведения вы можете задать для параметра События, поступающие с опозданием наибольшее возможное значение —20 дней.
Результаты задерживаются.
Первая водяная метка создается в вычисленное время — максимальное из наблюдавшихся системой на данный момент времен событий минус размер окна допустимой неупорядоченности. По умолчанию допуск для событий, полученных в неправильном порядке, установлен на ноль (00 минут и 00 секунд). При установке более высокого (ненулевого) значения времени первый вывод задания на потоковую обработку задерживается на это значение времени (или большее), поскольку рассчитывается первая метка времени.
Входные данные являются разреженными.
Если в заданном разделе данных нет входных данных, время водяного знака вычисляется как время прибытия минус временное окно толерантности на позднее прибытие. Таким образом, если входные события редки и разрежены, выходные данные могут задерживаться на этот период времени. Значение по умолчанию для параметра События, поступающие с опозданием составляет 5 секунд. Например, следует ожидать некоторую задержку при отправке событий входных данных по одному за раз. Задержки могут стать большими, если задать для параметра События, поступающие с опозданием большее значение.
Значение System.Timestamp отличается от времени в поле времени события.
Как было описано выше, система корректирует время события с учетом окна допуска для событий, полученных в неправильном порядке, или для событий, поступивших с задержкой. Значение System.Timestamp события настраивается, но поле времени события не настраивается. Это можно использовать для определения событий, для которых были скорректированы метки времени. Если система изменяет метку времени из-за одной из допустимых погрешностей, обычно они остаются одинаковыми.
Метрики для наблюдения
Вы можете наблюдать несколько эффектов допусков времени упорядочивания событий через метрики задания Azure Stream Analytics. Ниже приведены соответствующие метрики.
| Метрика | Описание |
|---|---|
| События вне порядка | Указывает количество событий, полученных не в порядке, которые были либо удалены, либо получили скорректированную метку времени. Эта метрика напрямую зависит от настройки параметра События, поступающие не по порядку на странице Упорядочение событий для задания на портале Azure. |
| Поздние входные события | Указывает число событий, поступающих позднее из источника. Эта метрика включает события, которые были удалены или были изменены метки времени. Эта метрика напрямую зависит от настройки параметра События, поступающие с опозданием на странице Упорядочение событий для задания на портале Azure. |
| Early Input Events (Ранние входные события) | Указывает количество событий, приходящих раньше времени из источника, которые были удалены или у которых была изменена метка времени, если они опережают график более чем на 5 минут. |
| Watermark Delay (Задержка водяного знака) | Сообщает о задержке выполнения задания по обработке потоковых данных. Дополнительные сведения см. в следующем разделе. |
Сведения о предельной задержке
Azure Stream Analytics вычисляет метрику задержки водяного знака как время обработки узла минус наибольший водяной знак, который был замечен до сих пор. Дополнительные сведения см. в разделе «Задержка водяного знака».
Есть несколько причин, из-за которых это значение метрики больше 0 при нормальной работе:
Задержка, присущая обработке потокового конвейера. Обычно эта задержка является ничтожно малой.
Из-за окна допустимого расхождения во времени для событий, полученных в неправильном порядке, возникла задержка, так как водяной знак уменьшается на размер этого окна.
Из-за позднего окна прибытия была введена задержка, потому что порог уменьшен на размер окна допустимых отклонений.
Смещение времени на узле обработки, создающем метрику.
Существует несколько других ограничений ресурсов, которые могут привести к замедлению конвейера потоковой передачи. Метрика предельной задержки может увеличиваться из-за:
Недостаточно ресурсов обработки в Azure Stream Analytics для обработки объема входных событий. Чтобы увеличить количество ресурсов, см. Обзор и настройку потоковых единиц.
Недостаточно пропускной способности в брокерах входных событий, поэтому они ограничиваются. Возможные решения см. в статье Автоматическое масштабирование единиц пропускной способности Центров событий Azure.
Конечные системы (например, Azure SQL Database, Azure Blob Storage или Power BI) не подготовлены с достаточной емкостью, поэтому они ограничены. Возможные решения зависят от используемой выходной службы.
Частота событий вывода
Azure Stream Analytics использует прогресс метки времени в качестве единственного триггера для создания выходных событий. Так как водяной знак является производным от входных данных, он повторяется во время восстановления после сбоя, а также при повторной обработке, инициированной пользователем. При использовании агрегатов данных на основе периодов служба создает выходные данные только в конце интервалов. В некоторых случаях вы можете захотеть увидеть частичные агрегаты, созданные из окон. Частичные агрегаты в настоящее время не поддерживаются в Azure Stream Analytics.
В других решениях потоковой передачи выходные события можно материализовать в различных точках триггера в зависимости от внешних обстоятельств. В некоторых решениях можно создать выходные события для заданного периода времени несколько раз. По мере обработки входных значений результаты агрегации становятся более точными. События можно сначала рассматривать, а затем пересмотреть со временем. Например, когда определенное устройство находится в автономном режиме, система может использовать предположительное значение. Позднее это же устройство подключится к сети. Затем фактические данные событий могут быть включены во входной поток. Результаты обработки этого временного окна дают более точные выходные данные.
Иллюстрированный пример водяных знаков
На следующих изображениях показано, как водяные знаки меняются в различных обстоятельствах.
В этой таблице показан пример данных, которые представлены на диаграмме ниже. Обратите внимание, что время события и время получения различаются (иногда совпадают, а иногда — нет).
| Время события | Время прибытия | DeviceId |
|---|---|---|
| 12:07 | 12:07 | устройство1 |
| 12:08 | 12:08 | устройство2 |
| 12:17 | 12:11 | устройство1 |
| 12:08 | 12:13 | устройство3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | устройство3 |
| 12:17 | 12:18 | устройство2 |
| 12:20 | 12:19 | устройство2 |
| 12:16 | 12:21 | устройство3 |
| 12:23 | 12:22 | устройство2 |
| 12:22 | 12:24 | устройство2 |
| 12:21 | 12:27 | устройство3 |
На этой иллюстрации используются следующие отклонения:
- Окно раннего прибытия составляет 5 минут
- Окно позднего поступления составляет 5 минут.
- Окно повторного заказа — 2 минуты.
Иллюстрация того, как метка времени изменяется вместе с этими событиями:
Важные процессы, показанные на предыдущем рисунке:
Время первого события (device1) и второго события (device2) выровнены и обрабатываются без корректировки. Метка времени изменяется для каждого события.
При обработке данного третьего события (device1) время прибытия (12:11) предшествует времени события (12:17). Событие прибыло на 6 минут раньше, поэтому оно было отклонено из-за 5-минутной допустимости раннего прибытия.
Метка времени не двигается в случае раннего события.
Время четвертого события (device3) и пятого события (device1) совпадает, и они обрабатываются без корректировки. Метка времени изменяется для каждого события.
При обработке шестого события (device3) время прибытия (12:17) и время события (12:12) находятся ниже порогового уровня. Время события корректируется на уровень подложки (12:17).
При обработке двенадцатого события (device3) время получения (12:27) — на 6 минут раньше времени события (12:21). Применяется политика опозданий. Время события скорректировано (12:22) и находится ниже метки времени (12:21), поэтому дальнейшая корректировка не применяется.
Вторая иллюстрация водяного знака, который развивается без политики преждевременного прибытия.
В этом примере политика раннего получения не применяется. Аномальные события, поступающие раньше, значительно увеличивают уровень. Обратите внимание, что третье событие (deviceId1 в 12:11) не пропущено в этом случае, и водяной знак поднимается до 12:15. Как результат четвертое время события корректируется вперед на 7 минут (с 12:08 до 12:15).
На окончательной иллюстрации используются подпотоки (OVER DeviceId). Отслеживается несколько меток, по одной на поток. В результате количества событий с откорректированным временем стало меньше.
