Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описано, как настроить и использовать политики для событий с поздним поступлением и событий, поступающих не по порядку, в Azure Stream Analytics. Эти политики применяются только в том случае, если в запросе используется предложение TIMESTAMP BY, и применяются только к облачным источникам входных данных.
Время события и время прибытия
Задание Stream Analytics может обрабатывать события на основе времени события или времени поступления. Время события/приложения — это метка времени, присутствующая в полезной нагрузке события (когда событие было сгенерировано). Время поступления — это отметка времени, которая указывает на то, когда данные об этом событии были получены в источнике входных данных (концентраторе событий, Центре Интернета вещей или хранилище BLOB-объектов).
По умолчанию Stream Analytics обрабатывает события по времени прибытия, но вы можете обрабатывать события по времени события с помощью предложения TIMESTAMP BY в запросе. Политики опоздания и поступления не по порядку применяются только в том случае, если обработка событий выполняется по времени события. При настройке этих параметров рассмотрите требования к задержке и правильности сценария.
Что такое политика обработки поздно поступающих данных?
Иногда события приходят поздно по различным причинам. Например, событие, которое поступает с опозданием в 40 секунд, будет иметь время события 00:10:00, а время поступления — 00:10:40. Если установить для политики позднего поступления значение 15 секунд, любое событие, которое поступит более чем на 15 секунд позже, будет либо отброшено (то есть не будет обработано Stream Analytics), либо его время события будет скорректировано. В приведенном выше примере событие поступило с опозданием в 40 секунд (больше, чем предусмотрено политикой), поэтому его время будет изменено до максимально приемлемого для политики опоздания значения 00:10:25 (время поступления минус значение политики опоздания). По умолчанию для политики опоздания задано значение 5 секунд.
Что такое политика обработки вне очереди?
События также могут поступать не по порядку. После корректировки времени события в соответствии с политикой позднего поступления можно также настроить автоматическое удаление или корректировку событий, поступающих не по порядку. Если для этой политики установить значение 8 секунд, все события, поступающие не по порядку, но в пределах 8-секундного окна, будут переупорядочены по времени события. События, поступившие позже, будут либо отброшены, либо скорректированы до максимального значения, допустимого политикой обработки событий, поступающих не по порядку. По умолчанию значение политики обработки не по порядку составляет 0 секунд.
Настройте или отбрасывайте поздние и поступающие не по порядку события
Если события поступают с опозданием или не по порядку (согласно настроенным политикам), они могут быть либо удалены (не будут обрабатываться с помощью Stream Analytics), либо скорректированы (будет изменено время события).
В следующем примере показаны эти политики в действии.
- Политика позднего прибытия: 15 секунд
- Политика вне очереди: 5 секунд
| Номер события | Время события | Время прибытия | System.Timestamp | Пояснение |
|---|---|---|---|---|
| 1 | 00:10:00 | 00:10:40 | 00:10:25 | Событие поступило с опозданием и вне допустимого отклонения. Поэтому время события корректируется в соответствии с максимально допустимым опозданием. |
| 2 | 00:10:30 | 00:10:41 | 00:10:30 | Событие поступило с опозданием, но без превышения допустимого уровня. Поэтому время события не корректируется. |
| 3 | 00:10:42 | 00:10:42 | 00:10:42 | Событие пришло вовремя. Корректировка не требуется. |
| 4 | 00:10:38 | 00:10:43 | 00:10:38 | Событие поступило не в том порядке, в котором требовалось, но в пределах 5-секундного допуска. Поэтому время события не корректируется. В целях аналитики это событие будет считаться предыдущим номером 3 (с учетом всего 5 событий. Фактический порядок: 1, 2, 5, 4, 3). |
| 5 | 00:10:35 | 00:10:45 | 00:10:37 | Событие поступило не в том порядке, в котором требовалось, и за пределами 5-секундного допуска. Итак, время события корректируется с учётом максимально допустимого нарушения порядка поступления. |
Могут ли позднее поступление данных и политики обработки неупорядоченных данных задерживать вывод задания?
Да. По умолчанию для политики обработки неупорядоченных данных установлено значение 0 (00 минут и 00 секунд). При изменении значения по умолчанию первый вывод задания задержится (как минимум) на это значение.
Если один из разделов ваших входных данных не получает событий, следует ожидать, что выходные данные будут задержаны на значение, заданное политикой позднего поступления. Сведения о том, почему см. в статье InputPartitionNotProgressing messages.
Я вижу сообщения LateInputEvents в моем журнале действий
Эти сообщения указывают на то, что события были получены с опозданием и либо удалены, либо скорректированы в соответствии с конфигурацией. Эти сообщения можно игнорировать, если вы правильно настроили политику позднего прибытия.
Ниже приведен пример этого сообщения:
{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}
Я вижу InputPartitionNotProgressing в своем журнале действий
Вероятно, источник входных данных (концентратор событий или Центр Интернета вещей), имеет несколько секций. Azure Stream Analytics формирует выходные данные для момента времени t1 только после того, как все объединяемые разделы достигнут как минимум момента времени t1. Например, предположим, что запрос считывает данные из раздела концентратора событий, имеющего два раздела. В одном из разделов, P1, есть события до времени t1. В одном из разделов, P2, есть события до времени t1 + x. Затем выходные данные формируются до момента времени t1. Однако, если явно указано условие PARTITION BY PartitionId, обе партиции обрабатываются независимо друг от друга.
Если одновременно используется несколько секций из одного входного потока, допустимый интервал поступления с опозданием является максимальным временем, в течение которого каждая секция ожидает поступления новых данных. Если в концентраторе событий имеется только один раздел или если Центр Интернета вещей не получает входящие данные, временная шкала для этого раздела не продвигается вперед, пока не будет достигнут порог допуска позднего поступления. В следствие этого выходные данные задерживаются на величину порогового значение допустимого опоздания. В таких случаях может появиться следующее сообщение:
{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}
Это сообщение сообщает, что по крайней мере один раздел во входных данных пуст, что приведёт к задержке выходных данных на величину порога позднего поступления. Чтобы преодолеть это, рекомендуется:
- Убедитесь, что все секци концентратора событий или Центра Интернета вещей получают входные данные.
- Используйте в запросе конструкцию Partition by PartitionID.
Почему я вижу задержку в 5 секунд, даже если политика позднего прибытия установлена на 0?
Это происходит, когда существует входной раздел, который никогда не получал входных данных. Чтобы убедиться в наличии такого поведения, можно проверить входные метрики по секциям.
Если в разделе отсутствуют какие-либо данные дольше, чем заданный порог позднего поступления, Stream Analytics сдвигает метку времени приложения вперёд, как описано в разделе, посвящённом особенностям упорядочения событий. Для этого требуется расчётное время прибытия. Если в секции никогда не было данных, Stream Analytics оценивает время прибытия как локальное время — 5 секунд. Из-за этого разделы, в которых никогда не было данных, могли показывать задержку watermark в 5 секунд.