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

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

Задание не создает выходные данные

  1. Проверьте подключение к портам вывода с помощью кнопки Проверить подключение для всех выходных данных.

  2. См. Мониторинг задания Stream Analytics с помощью портала Azure на вкладке Монитор. Поскольку значения агрегируются, метрики отображаются с задержкой в несколько минут.

    • Если значение в поле Входные события больше нуля, то задание может считывать входные данные. Если значение в поле Входные события не больше нуля, то это указывает на ошибку со входными данными задания. Дополнительные сведения см. в разделе Устранение неполадок с входными подключениями. Если в задании есть эталонные данные, примените разделение по логическому имени при просмотре метрики Входные события. Если входные события из эталонных данных отсутствуют, скорее всего, это означает, что этот источник входных данных не настроен должным образом, чтобы получить правильный эталонный набор данных.
    • Если значение в поле Ошибки преобразования данных больше нуля и увеличивается, обратитесь к статье Ошибки преобразования данных Azure Stream Analytics для получения дополнительных сведений об ошибках преобразования данных.
    • Если значение в поле Ошибки среды выполнения больше нуля, это означает, что задание получает данные, но при обработке запроса выдает ошибки. Чтобы найти ошибки, перейдите к журналам аудита и выполните фильтрацию по состоянию Сбой.
    • Если значение входных событий больше нуля, а значение выходных событий равно нулю, одно из следующих операторов имеет значение true:
      • Обработка запроса не привела к появлению ни одного выходного события.
      • События или их поля могут быть некорректно сформированы, в результате чего после обработки запроса не будет получено ни одного результата.
      • Заданию не удалось передать данные в приемник выходных данных из-за проблем с подключением или аутентификацией.

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

Первый фрагмент выходных данных задерживается

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

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

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

Одним из способов устранения этой задержки первых выходных данных является использование методов параллельной обработки запросов, таких как секционирование данных. Или можно добавить дополнительные единицы потоковой передачи (Streaming Units), чтобы повысить пропускную способность, пока задание не начнет справляться с нагрузкой. Дополнительные сведения см. в статье Рекомендации по созданию заданий Stream Analytics.

Эти факторы влияют на своевременность получения первого результата:

  • Использование оконных агрегатов, например предложения GROUP BY для фиксированных, скачущих и скользящих окон:

    • Для оконных агрегатов с фиксированными или скользящими окнами результаты формируются по окончании временного окна.
    • Для "скользящего" окна результаты создаются, когда событие входит в это окно или выходит из него.
    • Если вы планируете использовать окно большого размера, например более одного часа, лучше выбрать "прыгающее" или "скользящее" окно. Эти типы окон позволяют чаще видеть выходные данные.

  • Использование временных соединений, таких как JOIN с DATEDIFF:

    • Соответствия генерируются, как только поступают оба экземпляра сопоставляемых событий.
    • Данные без соответствия, такие как LEFT OUTER JOIN, создаются в конце окна DATEDIFF относительно каждого события с левой стороны.

  • Использование темпоральных аналитических функций, таких как ISFIRST, LAST и LAG с LIMIT DURATION:

    • Для аналитических функций выходные данные создаются для каждого события Нет задержки.

Выходные данные всё больше отстают с увеличением задержки

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

  • Подвергается ли приемник нижнего уровня ограничению скорости
  • Ограничивается ли входной источник
  • потребляет ли логика обработки в запросе много вычислительных ресурсов.

Чтобы просмотреть сведения о выходных данных, на портале Azure выберите задание потоковой передачи и нажмите Схема заданий. Для каждого входа существует метрика количества необработанных событий для каждой партиции. Если метрика увеличивается, это сигнализирует об ограниченности ресурсов системы. Такое увеличение может быть вызвано ограничением пропускной способности приемника выходных данных или высокой загрузкой ЦП. Дополнительные сведения см. в статье Отладка на основе данных с помощью схемы заданий.

Предупреждение о нарушении ключа с выходными данными службы "База данных SQL Azure"

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

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

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

Если IGNORE_DUP_KEY настраивается для нескольких типов индексов, обратите внимание на следующее:

  • Нельзя задать IGNORE_DUP_KEY для первичного ключа или уникального ограничения с помощью ALTER INDEX. Индекс нужно удалить и создать повторно.
  • Параметр IGNORE_DUP_KEY можно задать с помощью ALTER INDEX для уникального индекса. Этот объект отличается от ограничения PRIMARY KEY/UNIQUE и создаётся с помощью оператора CREATE INDEX или определения INDEX.
  • Параметр IGNORE_DUP_KEY не применяется к индексам хранилища столбцов, так как нельзя обеспечить уникальность таких индексов.

логика повторных попыток для выходных данных База данных SQL Azure

Когда задание Stream Analytics с выходными данными SQL получает первый пакет событий, выполняются следующие действия:

  1. Задание пытается подключиться к SQL.
  2. Задача извлекает схему целевой таблицы.
  3. Задание сверяет имена и типы столбцов со схемой целевой таблицы.
  4. Задание подготавливает таблицу данных в памяти из выходных записей в пакете.
  5. Задание записывает таблицу данных в SQL с помощью API BulkCopy.

Во время этих действий выходные данные SQL могут столкнуться со следующими типами ошибок:

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

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

  • Ошибки данных, такие как ошибки приведения и нарушения ограничений схемы, обрабатываются с помощью политики обработки ошибок вывода. Эти ошибки обрабатываются путем повторной обработки пакетов с их последовательным делением пополам до тех пор, пока отдельная запись, вызывающая ошибку, не будет обработана путем пропуска или повторной попытки. Нарушение ограничения первичного уникального ключа обрабатывается всегда.

  • При возникновении проблем со службой SQL или внутренних дефектов кода могут возникать повторяющиеся ошибки. Например, при возникновении ошибок, таких как (код 1132), когда эластичный пул достигает предела хранилища, повторные попытки не устраняют ошибку. В этих сценариях задание Stream Analytics переходит в состояние пониженной производительности.

  • Тайм-ауты BulkCopy могут возникать во время BulkCopy на шаге 5. BulkCopy может время от времени сталкиваться с тайм-аутами операций. Минимальное заданное по умолчанию время ожидания составляет пять минут и удваивается при каждом последовательном превышении. Если время ожидания превышает 15 минут, подсказка о максимальном размере пакета для BulkCopy уменьшается вдвое, пока размер пакета не достигнет 100 событий.

    Внимание

    Для заданий ASA без сетевой инъекции ни в коем случае не полагайтесь на IP-адрес источника подключений, поступающих из ASA. Они могут быть публичными или частными IP-адресами в зависимости от операций в инфраструктуре сервиса, которые время от времени выполняются.

Имена столбцов в Azure Stream Analytics (1.0) указаны строчными буквами

При использовании исходного уровня совместимости (1.0) Azure Stream Analytics преобразует символы имен столбцов в нижний регистр. На более поздних уровнях совместимости это поведение было исправлено. Чтобы сохранить регистр, перейдите на уровень совместимости 1.1 или более поздний. Дополнительные сведения см. в разделе Уровень совместимости для заданий Stream Analytics.

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

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

Следующие шаги

  • Last updated on