Прочитать на английском

Поделиться через

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

  • Статья

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

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

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

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

  1. Агрегаты данных на основе периодов (оператор группирования GROUP BY по "переворачивающимся", "прыгающим" и "скользящим" окнам).

  2. Темпоральные соединения (JOIN с DATEDIFF).

  3. Темпоральные аналитические функции (ISFIRST, LAST и LAG с LIMIT DURATION).

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

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

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

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

[частота входящих событий.] x [длина временного промежутка] / [количество обрабатываемых разделов]

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

Сейчас Stream Analytics не показывает отчет во время выполнения такого процесса восстановления.

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

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

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

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

Оценка времени восстановления воспроизведения

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

  1. Загрузите входные концентраторы событий с количеством данных, достаточным для охвата максимального периода в запросе, с ожидаемой скоростью событий. Метка времени событий должна быть близка к реальному времени по часам в течение всего этого периода, как если бы это был динамический канал входных данных. Например, при наличии 3-дневного периода в запросе отправляйте события в концентраторы событий на протяжении трех дней, а затем продолжите их отправку.

  2. Запустите задание, использовав в качестве времени начала значение Now.

  3. Измеряйте время между временем начала и временем создания первого фрагмента выходных данных. Это примерное время возможной задержки задания при обновлении службы.

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

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

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

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

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

Дальнейшие действия

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