Устранение неполадок с запросами в Azure Stream Analytics
В этой статье описаны распространенные проблемы с разработкой запросов Stream Analytics и способы их устранения.
В этой статье описаны распространенные проблемы, возникающие при разработке запросов Stream Analytics, способы диагностики и устранения этих проблем. Для многих действий по устранению неполадок должны быть включены журналы ресурсов для задания Stream Analytics. Если журналы ресурсов еще не включены, воспользуйтесь статьей Устранение неполадок в Azure Stream Analytics с помощью журналов ресурсов.
Запрос не создает ожидаемых выходных данных
Изучите ошибки с помощью локального тестирования:
- На портале Azure откройте вкладку Запрос и выберите Тест. Для проверки запроса используйте загруженные демонстрационные данные. Проанализируйте все ошибки и попытайтесь исправить их.
- Кроме того, вы можете проверить запрос локально с помощью инструментов Stream Analytics для Visual Studio или Visual Studio Code.
Для отладки запросов можно применить пошаговое локальное выполнение с использованием схемы заданий из набора инструментов Azure Stream Analytics для Visual Studio Code. На схеме заданий показано, как потоки данных из источников входных данных (концентратор событий, центр Интернета вещей и т. д.) проходят через несколько шагов запроса и попадают в приемники выходных данных. Каждый шаг запроса сопоставляется с временным результирующим набором, который определяется в скрипте с помощью инструкции WITH. Чтобы найти источник проблемы, вы можете просматривать данные и метрики по каждому из промежуточных результирующих наборов.
Если используются метки времени, убедитесь, что они зарегистрированы для событий после начала выполнения задания.
Исключите типичные проблемы, например:
- Предложение WHERE в запросе фильтрует все события, предотвращая создание выходных данных.
- Выполнение функции CAST завершается ошибкой, что приводит к сбою всего задания. Чтобы избежать сбоев приведения типов, используйте функцию TRY_CAST.
- При использовании оконных функций подождите до завершения окна для вывода выходных данных из запроса.
- Метка времени для событий предшествует времени запуска задания, и события отбрасываются.
- Условия JOIN не имеют совпадений. Если совпадений нет, возвращается нулевой набор результатов.
Убедитесь, что политики упорядочения событий настроены надлежащим образом. Перейдите к разделу Параметры и выберите Упорядочение событий. Эта политика НЕ применяется при проверке запроса по нажатию кнопки Тест. В результате тестирования в браузере и при выполнении задания в рабочей среде отличаются одним компонентом.
Для отладки по журналам действий и ресурсов:
- в журнале действий отфильтруйте результаты для поиска и диагностики ошибок;
- примените журнал ресурсов для заданий для поиска и диагностики ошибок.
Интенсивное использование ресурсов
Воспользуйтесь преимуществами параллелизма в Azure Stream Analytics. Сведения о масштабировании с использованием заданий параллелизации запросов Stream Analytics с помощью настройки входных разделов и определения запроса аналитики см. в статье Использование параллелизации запросов в Azure Stream Analytics.
Если процент использования ресурсов часто превышает 80 %, предельная задержка будет расти, как и число отложенных событий. В таком случае рекомендуется увеличить число единиц потоковой передачи. Высокий процент использования означает, что задача использует объем ресурсов, близкий к максимально допустимому.
Последовательная отладка запросов
При обработке данных в режиме реального времени важно знать, как выглядят данные во время запроса. Это можно увидеть на схеме заданий в Visual Studio. Если у вас нет Visual Studio, выполните дополнительные действия для вывода промежуточных данных.
Так как входные данные или шаги задания Azure Stream Analytics можно считать несколько раз, вы можете написать дополнительные инструкции SELECT INTO. Таким образом вы получаете промежуточные данные в хранилище, на основе которых можно проверить правильность данных, так же, как и с помощью переменных просмотра при отладке программы.
В следующем примере запроса в задании Azure Stream Analytics содержится один поток входных данных, два ссылочных набора входных данных и выходные данные для Хранилища таблиц Azure. Запрос объединяет данные из концентратора событий и два ссылочных больших двоичных объекта, чтобы получить сведения об имени и категории:
Обратите внимание, что задание выполняется, но события не создаются в выходных данных. На плитке Мониторинг, показанной здесь, можно увидеть, что данные выводятся, но невозможно определить, на каком шаге операции JOIN были удалены все события.
В этом случае можно добавить несколько дополнительных инструкций SELECT INTO в журнал для регистрации промежуточных результатов операции JOIN и данных, считываемых из входных данных.
В этом примере мы добавили два новых временных выхода. Они могут быть любым подходящим приемником. Ниже в качестве примера используется служба хранилища Azure:
Затем можно переписать запрос следующим образом:
Теперь снова запустите задание, которое должно выполняться в течение нескольких минут. Затем запросите temp1 и temp2 с помощью Visual Studio Cloud Explorer для создания следующих таблиц:
Таблица temp1
Таблица temp2
Как вы видите, обе таблицы содержат данные, а столбец имени в temp2 заполнен правильно. Тем не менее, так как данные еще не выведены, произошла какая-то проблема:
Выполнив выборку данных, можно почти определенно сказать, что проблема связана со второй операцией JOIN. Вы можете скачать ссылочные данные из большого двоичного объекта и убедиться в этом:
Как видно, формат GUID в этих справочных данных отличается от формата столбца в таблице temp2. Именно поэтому данные не поступили в output1, как положено.
Вы можете исправить формат данных, передать их в ссылочный большой двоичный объект и повторить попытку:
На этот раз выходные данные форматируются и заполняются требуемым образом.
Получить помощь
За дополнительной информацией перейдите на страницу вопросов и ответов об Azure Stream Analytics.