Масштабирование задания Azure Stream Analytics для повышения пропускной способности

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

Azure Stream Analytics измеряет вычислительные ресурсы в единицах потоковой передачи (SUs). Каждая su V2 представляет полную емкость одного вычислительного узла. Тривиально распараллеливаемый запрос — это запрос, в котором каждый входной раздел может обрабатываться независимо, без совместно используемых данных между разделами.

Необходимые условия

Перед началом работы ознакомьтесь со следующими статьями:

• Общие сведения и настройка единиц потоковой передачи
• Создание параллельных заданий

Масштабирование полностью параллельного запроса

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

1. Создайте запрос для использования ключевого слова PARTITION BY . Дополнительные сведения см. в статье "Использование параллелизации запросов" в Azure Stream Analytics.

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

   Тип выходных данных	Поддержка параллелизации
   Хранилище BLOB-объектов Azure, Azure Table Storage, Azure Data Lake Storage, Служебная шина Azure, Функции Azure	Автоматический
   База данных SQL Azure, Azure Synapse Analytics	Optional. Требуется конфигурация
   Центры событий Azure	Требуется, чтобы PartitionKey соответствовал полю PARTITION BY (обычно PartitionId). Согласуйте количество входных и выходных партиций, чтобы избежать перекрёстного распределения.
   Power BI	Не параллелизуемо. Выходные данные всегда объединяются перед отправкой в приемник

3. Запустите запрос с 1 SU V2 (которая является полной емкостью одного вычислительного узла), чтобы измерить максимальную достижимую пропускную способность. Если вы используете GROUP BY, оцените, сколько групп (кардинальность) может обработать задача.

4. Проверьте ограничения системных ресурсов. Следующие симптомы показывают, что задание Azure Stream Analytics достигает ограничений ресурсов:

   Симптом	Вероятно, причина	Действие
   Метрика использования SU превышает 80 %	Высокая загрузка памяти. Ознакомьтесь с разделом "Общие сведения и настройка единиц потоковой передачи".	Добавьте дополнительные версии SU 2.
   Выходная метка времени отстает от астрономического времени	В зависимости от логики запроса метка времени вывода может иметь смещение логики от времени настенных часов. Тем не менее, они должны прогрессировать примерно с той же скоростью. Если метка времени на выходе всё больше отстаёт, это указывает на то, что система перегружена. Это может быть результат регулирования нижнего выходного приемника или высокой загрузки ЦП. В настоящее время Stream Analytics не предоставляет метрику загрузки ЦП, поэтому бывает трудно различить эти два варианта.	Если проблема вызвана ограничением пропускной способности приемника, увеличьте количество выходных разделов (и входных разделов, чтобы сохранить параллелизм) или увеличьте ресурсы приемника (например, единицы запросов (RU) для Azure Cosmos DB).
   Метрика событий невыполненной работы по секциям продолжает увеличиваться (видимый на схеме заданий)	Регулирование приемника вывода или высокая загрузка ЦП	То же, что и выше.

5. Экстраполируйте ёмкость линейно. После того как вы определите, какую нагрузку может обрабатывать 1 SU V2, пропорционально добавляйте дополнительные единицы SU, при условии отсутствия перекоса данных между разделами.

Масштабирование непараллельного запроса

Если ваш запрос не распараллеливается тривиальным образом, выполните следующие действия:

1. Начните без PARTITION BY, чтобы избежать излишней сложности. Запустите запрос с 1 SU V2, чтобы измерить максимальную пропускную способность. Проверьте наличие тех же симптомов ограничения ресурсов, описанных в предыдущем разделе (использование SU выше 80 %, отставание выходной метки времени, рост очереди необработанных данных).

2. Если вы достигнете целевой пропускной способности, все готово. При необходимости проведите тестирование с 2/3 и 1/3 от числа SU V2, чтобы определить минимально необходимое количество SU V2 для вашего сценария.

3. Если вы не можете достичь требуемой пропускной способности, разорвайте запрос на несколько шагов. Выделите до 1 SU V2 для каждого шага. Например, для трехэтапного запроса требуется 3 SU V2. Azure Stream Analytics размещает каждый шаг на собственном выделенном узле.

4. Если вы всё ещё не достигли целевой пропускной способности, добавьте PARTITION BY к шагам, расположенным ближе к входным данным. Для операций GROUP BY , которые не являются естественно секционируемыми, используйте локальный или глобальный шаблон статистической обработки: сначала выполните секционированную ГРУППУ BY , а затем непартиментированную ГРУППУ BY. Например, для подсчета автомобилей, проезжающих через каждый пункт взимания платы каждые 3 минуты, когда объем превышает возможности обработки 1 SU V2:

   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
   

   Этот запрос на шаге Step1 подсчитывает количество автомобилей для каждого пункта взимания платы в каждом разделе, а затем на последнем шаге агрегирует результаты подсчёта по разделам.

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

   Замечание

   Если запрос не может быть секционирован, добавление дополнительных единиц SU V2 в многофакторный запрос может не повысить пропускную способность. Чтобы повысить производительность, уменьшите объем в начальных шагах с помощью локального или глобального статистического шаблона, показанного на шаге 4.

Масштабирование нескольких независимых запросов в одном задании

Для сценариев мультитенантного независимого поставщика программного обеспечения (ISV) при обработке данных из нескольких клиентов в одном задании Azure Stream Analytics (с отдельными входными и выходными данными для каждого клиента) загрузка каждого подзадачного запроса обычно невелика. Выполните следующие действия:

1. Не используйте PARTITION BY в запросе.

2. Если вы используете Центры событий Azure, уменьшите количество входных секций до минимального значения 2.

3. Запустите запрос с 1 SU V2. Добавьте вложенные запросы, пока задание не достигнет ограничений ресурсов. Симптомы такие же, как у полностью распараллеливаемого запроса: использование SU выше 80 %, отставание выходной метки времени или растущий объем необработанных данных.

4. После достижения ограничения вложенных запросов добавьте новые вложенные запросы в отдельное задание. Число заданий линейно зависит от числа независимых запросов (при условии отсутствия перекоса нагрузки). Затем можно предсказать, сколько заданий SU V2 необходимо выполнить в качестве функции числа клиентов, которые вы хотите обслуживать.

5. Для соединения ссылочных данных необходимо объединить все входные данные перед присоединением к эталонным данным, а затем разделить события. В противном случае каждое соединение ссылочных данных сохраняет отдельную копию эталонных данных в памяти, что может привести к ненужному использованию памяти.

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

Дополнительные сведения см. на странице вопросов Microsoft Q&A для Azure Stream Analytics.

Связанный контент

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