• Статья
  • Чтение занимает 6 мин

В этой статье описано, как настроить запрос Stream Analytics для увеличения пропускной способности заданий Streaming Analytics. Руководство ниже можно использовать для масштабирования заданий, чтобы обрабатывать большую нагрузку и использовать больше ресурсов системы (таких как пропускная способность, ресурсы ЦП, память).
Предварительно может потребоваться ознакомиться со следующими статьями:

  • Обзор и настройка единиц потоковой передачи
  • Использование параллелизации запросов в Azure Stream Analytics

Вариант 1. Полностью параллелизуемый запрос в секциях ввода

Если запрос по своей природе полностью параллелизуемый в секциях ввода, можно выполнить такие действия:

  1. Создайте запрос с усложненным параллелизмом с помощью ключевого слова PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО). Дополнительные сведения о заданиях с усложненным параллелизмом см. в этой статье.
  2. В зависимости от типов выходных данных, используемых в запросе, некоторые выходные данные могут быть не параллелизуемыми или требовать дополнительной конфигурации при усложненном параллелизме. Например, выходные данные PowerBI не параллелизуемы. Выходные данные всегда объединяются перед отправкой в приемник выходных данных. Большие двоичные объекты, таблицы, ADLS, служебные шины и служба «Функции Azure» автоматически параллелизуются. Выходные данные SQL и Azure Synapse Analytics имеют возможность параллелизации. Концентратору событий необходим набор конфигурации PartitionKey, чтобы соответствовать полю PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО) (обычно PartitionId). При использовании концентратора событий также обратите особое внимание на соответствие количества секций для всех входных и выходных данных, чтобы избежать пересечения секций.
  3. Выполните запрос с 6 единицами потоковой передачи (полная емкость одного узла вычислений) для измерения максимально достижимой пропускной способности, а при использовании GROUP BY (СГРУППИРОВАТЬ ПО) измерьте сколько групп (кратность) может обработать задание. Ниже перечислены общие признаки задания, достигшего ограничения по ресурсам.
    • Метрика процентного использования единиц потоковой передачи выше 80 %. Это указывает на высокий уровень использования памяти. Факторы, влияющие на увеличение этой метрики, описаны в этой статье.
    • Метка времени выходных данных отстает от реального времени. В зависимости от логики запроса метка времени может иметь логическое смещение относительно реального времени. Тем не менее они будут выполняться примерно с такой же скоростью. Если метка времени выходных данных отстает все сильнее, это является индикатором того, что система перегружена. Это может быть результатом нисходящего регулирования приемника выходных данных или высокой загрузки ЦП. В настоящее время метрика использования процессора не предоставляется, поэтому их может быть трудно различить.
      • Если проблема не возникает из-за регулирования приемников, может потребоваться увеличить количество секций выходных данных (а также секций ввода, чтобы задание осталось полностью параллелизуемым) или увеличить объем ресурсов приемника (например, число единиц запроса для CosmosDB).
    • На схеме задания есть метрика событий невыполненной работы секции для каждого набора входных данных. Если метрика событий невыполненных работ продолжает увеличиваться, это означает, что системные ресурсы ограничены (из-за регулирования приемника выходных данных или высокой загрузки ЦП).
  4. После определения границ выполнения задания с 6 единицами потоковой передачи, можно линейно экстраполировать емкость обработки задания по мере добавления дополнительных единиц потоковой передачи при отсутствии неравномерного распределения данных, создающего секции с высокой нагрузкой.

Примечание

Выберите правильное число единиц потоковой передачи: так как Stream Analytics создает узел обработки для каждой из добавленных шести единиц потоковой передачи, для равномерного распределения секций по узлам лучше всего сделать число секций делителем количества секций входных данных.
Например, вы измерили, что задание с 6 единицами потоковой передачи может достигнуть скорости обработки 4 МБ/с, а количество секций выходных данных — 4. Можно запустить задание с 12 единицами потоковой передачи, чтобы достичь скорости обработки 8 МБ/с, или 24 единицами потоковой передачи, чтобы достичь скорости обработки 16 МБ/с. Затем можно решить, когда увеличивать количество единиц потоковой передачи для задания и до какого значения, в зависимости от скорости ввода.

Вариант 2. Если запрос без усложненного параллелизма

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

  1. Сначала запустите запрос без PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО), чтобы избежать сложности секционирования, и выполните запрос с 6 единицами потоковой передачи, чтобы измерить максимальную нагрузку, как в варианте 1.
  2. При достижении ожидаемой нагрузки с точки зрения пропускной способности настройка завершена. Кроме того, можно измерить ту же задачу, выполняемую с 3 и 1 единицей потоковой передачи, чтобы узнать минимально необходимое для работы сценария число единиц хранения.
  3. Если необходимой пропускной способности достичь не удается, попробуйте (если это возможно) разбить запрос на несколько шагов, если этого еще не сделано, и выделите до 6 единиц потоковой передачи для каждого шага в запросе. Например, при наличии 3 шагов выделите 18 единиц хранения в параметре «Масштаб».
  4. При выполнении такого задания Stream Analytics помещает каждый шаг на отдельный узел с выделенными ресурсами 6 единиц потоковой передачи.
  5. Если необходимая нагрузка по прежнему не достигнута, можно использовать PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО) начиная с шагов ближе к входным данным. Для оператора GROUP BY (СГРУППИРОВАТЬ ПО), который не может быть легко секционирован, можно использовать локальный или глобальный шаблон вычисления при выполнении секционированного оператора GROUP BY (СГРУППИРОВАТЬ ПО) после не секционированного GROUP BY (СГРУППИРОВАТЬ ПО). Например, если необходимо подсчитать, сколько автомобилей проходит через каждый пропускной пункт каждые 3 минуты, а объем данных выходит за рамки того, что может быть обработано в рамках 6 единиц потоковой передачи.

Запрос:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

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

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

Примечание

Если запрос не может быть секционирован, добавление дополнительных единиц потоковой передачи в запрос с несколькими действиями не всегда может повысить пропускную способность. Один из способов повышения производительности — уменьшить объем начальных действий, используя локальный или глобальный шаблон вычисления, как описано выше в шаге 5.

Вариант 3. Выполнение большого количества независимых запросов в задании

Для определенных вариантов использования ISV наиболее эффективным способом обработки данных нескольких клиентов является одно задание, использующее отдельные входные и выходные данные для каждого клиента. В одном задании можно запустить довольно много (например, 20) независимых запросов. Предполагается, что загрузка каждого из вложенных запросов относительно невелика.
В этом случае можно выполнить следующие действия.

  1. В этом случае PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО) не используется в запросе.
  2. Если используется концентратор событий, уменьшите количество секций входных данных до наименьшего возможного значения — 2.
  3. Выполните запрос с 6 единицами потоковой передачи. С ожидаемой нагрузкой каждого вложенного запроса добавьте столько вложенных запросов, сколько возможно, пока задание не достигнет ограничений по системным ресурсам. Дополнительные сведения об этом см. в разделе Вариант 1. Запрос по своей природе полностью параллелизуемый в секциях ввода.
  4. При достижении измеренного выше ограничения вложенных запросов приступите к добавлению вложенных запросов в новую задачу. Количество задач, выполняемых в зависимости от количества независимых запросов, должно быть линейным при отсутствии среза нагрузки. Затем можно спрогнозировать, сколько задач с 6 единицами потоковой передачи необходимо выполнять в зависимости от количества клиентов, которых нужно обслужить.
  5. При использовании соединения справочных данных с такими запросами, необходимо объединить входные данные перед соединением с теми же ссылочными данными, а затем, если необходимо, разделить события. Затем, при необходимости, разделите события. В противном случае каждое соединение ссылочных данных будет хранить ссылочные данные в памяти, что вызовет излишнее использование памяти.

Примечание

Сколько клиентов помещать в каждое задание?
Этот шаблон запроса часто имеет большое количество вложенных запросов, что приводит к очень большой и сложной топологии. Контроллер задания может не справиться с обработкой такой большой топологии. Как правило, оставляйте до 40 клиентов для задания с 1 единицей потоковой передачи и 60 клиентов для заданий с 3 и 6 единицами потоковой передачи. Если емкость контроллера превышена, работа не начнется успешно.

Получить справку

За дополнительной помощью обратитесь к нашей странице Microsoft Q A вопрос для Azure Stream Analytics.

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

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