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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

Эти факторы влияют на временные шкалы первого вывода:

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

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

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

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

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

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

Выходные данные запаздывают

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

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

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

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

При настройке службы "База данных SQL Azure" для выходных данных задания 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

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

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

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

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

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

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

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

  • При выполнении BulkCopy на шаге 5 возможны случаи истечения времени ожидания BulkCopy. При выполнении 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.

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