Рассмотрение времени в 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, которая обрабатывает события.
Помимо создания водяных знаков проектная схема служит двум дополнительным целям.
Система создает результаты за отведенное время, независимо от наличия входящих событий.
Вы можете контролировать интервал получения результатов выходных данных. На портале Azure на станице Упорядочение событий задания Stream Analytics можно настроить параметр События, поступающие не по порядку. При настройке этого параметра учтите компромисс между своевременностью и интервалом для событий, полученных в неправильном порядке, в потоке событий.
Допустимый интервал поступления с задержкой необходим для формирования водяных знаков даже при отсутствии входящих событий. Иногда может возникнуть период, когда входящие события не приходят, например, когда поток ввода события разрежен. Эта проблема усугубляется использованием нескольких секций в брокере входных событий.
Потоковые системы обработки данных без периода допустимости позднего прибытия могут страдать от отложенных выходных данных при разрежении входных данных и использовании нескольких секций.
Реакция системы на событие должна быть повторяемой. Повторяемость является важным свойством системы обработки потоковых данных.
Водяной знак формируется на основе времени получения и времени приложения. Оба этих времени сохраняются в брокере событий, и поэтому они являются повторяемыми. Если время получения оценивается при отсутствии событий, журналы 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 находится в timestamp 1, а устройство 2 находится в timestamp 2, то наиболее поздняя допустимость прибытия — Timestamp 2 минус Timestamp 1. Значение по умолчанию (5 секунд), скорее всего, слишком мало для устройств, имеющих разные метки времени. Мы советуем начать с 5 минут и вносить изменения в соответствии со схемой разницы в показаниях часов устройства.
События, поступающие рано
Возможно, вы заметили еще одну концепцию, называемую окном раннего прибытия, которое выглядит как противоположность оконечению допустимости прибытия. Этот интервал составляет 5 минут и предназначен для других целей, чем интервал для событий, наступивших с задержкой.
Так как Azure Stream Analytics гарантирует получение полных результатов, вы можете указать только время запуска задания в качестве первого времени вывода задания, а не времени ввода. Время запуска задания требуется для обработки всего интервала, а не только с его середины.
Затем Stream Analytics извлекает время начала из спецификации запроса. Тем не менее, так как брокер входных событий индексируется только по времени получения, система должна преобразовать начальное время события во время получения. Система может начать обрабатывать события с этого момента в брокере входных событий. С ограничением интервала раннего поступления преобразование не представляет никаких трудностей. Это начальное время события минус 5-минутный интервал раннего поступления. Это вычисление также означает, что система отклоняет все события, время которых на 5 минут превышает время получения. Значение метрики ранних входных событий увеличивается при удалении событий.
Эта концепция позволяет обеспечить возможность повторения обработки независимо от того, откуда начинается вывод данных. Без такого механизма невозможно гарантировать повторяемость, так как многие другие системы потоковой передачи утверждают, что они делают.
Побочные эффекты использования интервалов для событий, полученных в неправильном порядке
В заданиях Stream Analytics существует несколько параметров упорядочения событий. Два параметра можно настроить на портале Azure: параметр События, поступающие не по порядку (интервал для событий, полученных в неправильном порядке) и параметр События, поступающие с опозданием (допустимый интервал поступления с задержкой). Допустимое значение для раннего прибытия исправлено и не может быть изменено. Эти политики времени используются в Stream Analytics для предоставления надежных гарантий. Тем не менее в этих параметрах есть некоторые неожиданные последствия:
Случайная слишком ранняя отправка событий.
Ранние события не должны быть выходными в обычном режиме. Ранние события могут отправляться на вывод, если часы отправителя работают слишком быстро. Все ранние события удаляются, поэтому вы не увидите их из выходных данных.
Отправка старых событий в Центры событий для обработки в Azure Stream Analytics.
Хотя старые события могут показаться безвредными, во-первых, из-за применения позднего допуска прибытия старые события могут быть удалены. Если события слишком старые, значение System.Timestamp изменяется во время приема событий. Из-за этого поведения в настоящее время Azure Stream Analytics лучше подходит для сценариев обработки событий в режиме, близком к реальному времени, а не для сценариев обработки событий журнала. В некоторых случаях для обхода этого поведения вы можете задать для параметра События, поступающие с опозданием наибольшее возможное значение —20 дней.
Выходные данные задерживаются.
Первая метка времени создается в вычисленное время — максимальное время события, которое до сих пор наблюдала система, минус интервал для событий, полученных в неправильном порядке. По умолчанию для интервала для событий, полученных в неправильном порядке, установлено нулевое значение (00 минут, 00 секунд). При установке более высокого (ненулевого) значения времени первый вывод данных задания потоковой передачи задерживается на это значение времени (или большее) из-за первой вычисленной метки времени.
Входные данные являются разреженными.
Если в заданной секции нет входных данных, время подложки вычисляется как время прибытия минус окно допустимости позднего прибытия. Таким образом, если входные события редки и разрежены, выходные данные могут задерживаться на этот период времени. Значение по умолчанию для параметра События, поступающие с опозданием составляет 5 секунд. Например, следует ожидать некоторую задержку при отправке событий входных данных по одному за раз. Задержки могут стать большими, если задать для параметра События, поступающие с опозданием большее значение.
Значение System.Timestamp отличается от времени в поле времени события.
Как было описано выше, система корректирует время события с учетом интервала для событий, полученных в неправильном порядке, или интервала для событий, наступивших с задержкой. Корректируется значение System.Timestamp события, но не значение поля времени события. Это можно использовать, чтобы указать, для каких событий были скорректированы метки времени. Если система изменила метку времени из-за одного из допустимых, обычно они одинаковы.
Метрики для наблюдения
Вы можете наблюдать последствия использования интервалов для событий, полученных в неправильном порядке, с помощью метрик задания Azure Stream Analytics. Ниже приведены соответствующие метрики.
| Метрическая | Description |
|---|---|
| События, поступающие не по порядку | Указывает количество событий, полученных из порядка, которые были удалены или заданы скорректированной меткой времени. Эта метрика напрямую зависит от настройки параметра События, поступающие не по порядку на странице Упорядочение событий для задания на портале Azure. |
| Поздние входные события | Указывает число событий, поступающих позднее из источника. Эта метрика включает отклоненные события или события с откорректированной меткой времени. Эта метрика напрямую зависит от настройки параметра События, поступающие с опозданием на странице Упорядочение событий для задания на портале Azure. |
| Early Input Events (Ранние входные события) | Указывает количество событий, поступивших рано из источника, которые были либо отклонены, либо их метка времени была скорректирована, если их время поступления раньше на 5 минут. |
| Watermark Delay (Предельная задержка) | Указывает значение задержки для задания обработки потоковых данных. Дополнительные сведения приведены в следующем разделе. |
Сведения о предельной задержке
Метрика Watermark delay (Предельная задержка) вычисляется как физическое время обрабатываемого узла минус наибольшая метка времени, возникшая до этого. Дополнительные сведения доступны в записи блога о предельной задержке.
Есть несколько причин, из-за которых это значение метрики больше 0 при нормальной работе:
Задержка обработки конвейера потоковой передачи. Обычно эта задержка является ничтожно малой.
Из-за интервала для событий, полученных в неправильном порядке, возникла задержка, так как метка времени снижена до интервала для таких событий.
Из-за интервала поступления с задержкой возникла задержка, так как метка времени снижена до размера такого интервала.
Разница в показаниях часов узла обработки, создающего метрику.
Существует ряд других ограничений ресурсов, которые могут привести к замедлению конвейера потоковой передачи. Метрика предельной задержки может увеличиваться из-за:
Нехватка ресурсов для обработки входных событий в Stream Analytics. Дополнительные сведения об увеличении масштаба см. в статье Обзор и настройка единиц потоковой передачи.
Недостаточно пропускной способности в брокерах входных событий, поэтому они регулируются. Возможные решения см. в статье Автоматическое масштабирование единиц пропускной способности Центров событий Azure.
Приемники выходных данных не подготовлены с достаточной емкостью, поэтому они регулируются. Возможные решения значительно варьируются в зависимости от вида используемой службы вывода.
Частота событий вывода
Azure Stream Analytics использует прогресс метки времени в качестве единственного триггера для создания выходных событий. Так как водяной знак является производным от входных данных, он может повторяться во время восстановления сбоя, а также при повторной обработке, инициированной пользователем. При использовании агрегатов данных на основе периодов служба создает выходные данные только в конце интервалов. В некоторых случаях пользователям может потребоваться увидеть частичные агрегаты, созданные из окон. Частичные агрегаты в настоящее время не поддерживаются в Azure Stream Analytics.
В других решениях потоковой передачи выходные события можно материализовать в различных точках активации, в зависимости от внешних обстоятельств. В некоторых решениях возможно, что выходные события для данного интервала времени могут создаваться несколько раз. По мере обработки входных значений результаты агрегации становятся более точными. События сначала предполагаются, а через время пересматриваются. Например, когда определенное устройство находится в автономном режиме, система может использовать предположительное значение. Позднее это же устройство подключится к сети. Затем фактические данные событий могут быть включены во входной поток. Результаты обработки этого временного окна дают более точные выходные данные.
Примеры меток времени
На следующих изображениях показано, как метки времени меняются в различных обстоятельствах.
В этой таблице показан пример данных, которые представлены на диаграмме ниже. Обратите внимание, что время события и время получения различаются (иногда совпадают, а иногда — нет).
| Время события | Время прибытия | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | устройство2 |
| 12:17 | 12:11 | device1 |
| 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). Отслеживается несколько меток времени, по одной на поток. Как результат количество событий со скорректированным временем меньше.
