Устранение неполадок с запросами в Azure Stream Analytics

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

Запрос не даёт ожидаемый результат

1. Изучите ошибки с помощью локального тестирования:

   • В портале Azure на вкладке Запрос выберите Test. Для проверки запроса используйте загруженные демонстрационные данные. Проанализируйте все ошибки и попытайтесь исправить их.
   • Вы также можете локально протестировать свой запрос, используя инструменты Azure Stream Analytics для Visual Studio или Visual Studio Code.

2. Для отладки запросов можно применить пошаговое локальное выполнение с использованием схемы заданий из набора инструментов Azure Stream Analytics для Visual Studio Code. Диаграмма заданий показывает, как данные передаются от входных источников, например, Центры событий Azure и Центр Интернета вещей Azure, через несколько этапов запроса и, наконец, к выходным поглотителям. Скрипт отображает каждый шаг запроса в временный набор результатов, который вы определяете с помощью оператора WITH. Просмотрите данные и метрики в каждом промежуточном наборе результатов, чтобы найти источник проблемы.

   

3. Если вы используете Timestamp By, убедитесь, что у событий временные метки позже времени начала задания.

4. Исключите типичные проблемы, например:

   • Клауза WHERE в запросе фильтровала все события, поэтому запрос не даёт вывода.
   • Выполнение функции CAST завершается ошибкой, что приводит к сбою всего задания. Чтобы избежать ошибок приведения типов, используйте TRY_CAST.
   • При использовании оконных функций подождите до завершения окна для вывода выходных данных из запроса.
   • Временная метка у событий предшествует времени запуска задания, поэтому задание отбрасывает эти события.
   • Условия JOIN не имеют совпадений. Если совпадений нет, запрос не даёт результатов.

5. Убедитесь, что вы настроили правила упорядочивания событий должным образом. Перейдите к разделу Параметры и выберите Упорядочение событий. Кнопка Test не применяет политику при тестировании запроса. Этот результат — одно из отличий между тестированием в браузере и выполнением задания в продакшене.

6. Отладка с помощью журналов действий и ресурсов:

   • в журнале действий отфильтруйте результаты для поиска и диагностики ошибок;
   • примените журнал ресурсов для заданий для поиска и диагностики ошибок.

Последовательная отладка запросов

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

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

В следующем примере запроса в задании Azure Stream Analytics используются один входной поток, два входа ссылочных данных и выход в Хранилище таблиц Azure. Запрос объединяет данные из Центра событий и двух эталонных BLOB-объектов, чтобы получить имя и сведения о категории:

Задание выполняется, но не создаёт событий в выходных данных. На плитке Мониторинг , показанной здесь, видно, что вход генерирует данные, но вы не знаете, какой шаг JOIN отключил все события.

В этой ситуации можно добавить несколько дополнительных SELECT INTO инструкций, чтобы «записать в журнал» промежуточные JOIN результаты и данные, считываемые из входного потока.

В этом примере мы добавили два новых «временных выхода». Это может быть любая раковина, которую вы захотите. Ниже в качестве примера используется служба хранилища Azure:

Затем можно переписать запрос следующим образом:

Теперь снова запустите задание и дайте ему поработать несколько минут. Затем выполните запрос temp1 и temp2 с помощью Visual Studio Cloud Explorer, чтобы получить следующие таблицы:

таблица temp1

Таблица

Как видно, temp1 и temp2 оба содержат данные, а столбец name корректно заполнен в temp2. Однако, поскольку на выходе всё ещё нет данных, что-то не так:

Проанализировав выборку данных, почти наверняка можно сказать, что проблема связана со вторым JOIN. Вы можете скачать эталонные данные из BLOB-объекта и ознакомиться с ними:

Как видно, формат GUID в этих справочных данных отличается от формата [from] столбца в temp2. Вот почему данные не поступили в output1, как ожидалось.

Исправьте формат данных, загрузите их в референсный blob и попробуйте снова:

На этот раз выходные данные форматируются и заполняются требуемым образом.

Интенсивное использование ресурсов

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

Если процент использования ресурсов часто превышает 80 %, предельная задержка будет расти, как и число отложенных событий. В таком случае рекомендуется увеличить число единиц потоковой передачи. Высокий процент использования означает, что задача использует объем ресурсов, близкий к максимально допустимому.

Получить помощь

За дополнительной информацией перейдите на страницу вопросов и ответов об Azure Stream Analytics.

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

• Введение в Azure Stream Analytics
• Приступая к работе с Azure Stream Analytics
• Масштабирование заданий в службе Azure Stream Analytics
• Справочник по языку запросов Azure Stream Analytics
• Справочник по REST API управления Azure Stream Analytics