Основные понятия контрольных точек и воспроизведения в заданиях Azure Stream Analytics

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

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

Логика запросов с отслеживанием состояния во временных элементах

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

Концепция временного окна представлена в следующих элементах запросов Stream Analytics.

  • Оконные агрегаты (GROUP BY для сегментированных, скачковых и скользящих окон)
  • Темпоральные соединения (JOIN с DATEDIFF)
  • Функции темпоральной аналитики (ISFIRST, LAST и LAG с ОГРАНИЧЕНИЕМ ДЛИТЕЛЬНОСТИ)

Восстановление заданий из сбоя узла, включая обновление ОС

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

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

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

[частота входных событий] x [длина пробела] / [количество секций обработки]

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

Stream Analytics в настоящее время не показывает отчёт, когда происходит такой процесс восстановления.

Восстановление заданий после обновления службы

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

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

Как правило, необходимое количество воспроизведения пропорционально размеру окна, умноженному на среднюю частоту событий. Например, для задания с входной скоростью 1 000 событий в секунду окно длительностью более одного часа приводит к большому объёму повторной обработки. Сервису может потребоваться переобработка до одного часа данных для инициализации состояния, чтобы получить полные и корректные результаты, что может привести к задержке выхода (отсутствию вывода) на длительное время. Запросы без окон или других временных операторов, например JOIN или LAG, имеют нулевое воспроизведение.

Оценка времени догонки при воспроизведении

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

  • Загрузите в центр входных событий достаточное количество данных, чтобы покрыть самый большой размер окна в вашем запросе при ожидаемой частоте событий. Временные метки событий должны примерно соответствовать времени по системным часам в течение всего этого периода, как если бы это был поток входных данных в реальном времени. Например, если в вашем запросе есть трёхдневное окно, отправляйте события в event hub на три дня и продолжайте отправлять события.
  • Начинайте работу, используя «Сейчас » как время начала.
  • Измерьте время между началом работы и моментом, когда задание генерирует свой первый результат. Это время примерно равно задержке, которую испытывает задание во время обновления сервиса.
  • Если задержка слишком высокая, попробуйте разделить работу и увеличить количество стриминговых единиц, чтобы нагрузка распределялась между большим количеством узлов. В качестве альтернативы рассмотрите возможность уменьшить размеры окон в запросе и выполнить дополнительную агрегацию или другую обработку с сохранением состояния для выходных данных, которые формирует задание Stream Analytics, в последующем приёмнике (например, с помощью База данных SQL Azure).

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

Восстановление задания после остановки, инициированной пользователем

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

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

Связанные материалы

Дополнительные сведения о надежности и масштабируемости см. в следующих статьях:

  • Last updated on