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

  • Статья

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

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

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

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

  • Создайте запрос с усложненным параллелизмом с помощью ключевого слова PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО). Дополнительные сведения см. в статье "Использование параллелизации запросов" в Azure Stream Analytics.
  • В зависимости от типов выходных данных, используемых в запросе, некоторые выходные данные могут быть не параллельными или нуждаться в дальнейшей настройке. Например, выходные данные Power BI не могут быть параллелизуемыми. Выходные данные всегда объединяются перед отправкой в приемник выходных данных. Большие двоичные объекты, таблицы, Azure Data Lake служба хранилища, служебная шина и функция Azure автоматически параллелизируются. Выходные данные SQL и Azure Synapse Analytics имеют возможность параллелизации. Концентратор событий должен иметь набор конфигурации PartitionKey, чтобы соответствовать полю PARTITION BY (обычно PartitionId). Для Центров событий также обратите особое внимание на соответствие количеству секций для всех входных данных и всех выходных данных, чтобы избежать перекрестного взаимодействия между секциями.
  • Запустите запрос с 1 единицей потоковой передачи (SU) версии 2 (которая является полной емкостью одного вычислительного узла), чтобы измерить максимальную достижимую пропускную способность, и если вы используете GROUP BY, проверьте, сколько групп (карта inality) задание может обрабатывать. Ниже перечислены общие признаки задания, достигшего ограничения по ресурсам.
    • Метрика использования единиц потоков (SU) превышает 80 %. Это означает, что использование памяти высоко. Факторы, влияющие на увеличение этой метрики, описаны в разделе "Общие сведения и корректировка единиц потоковой передачи Stream Analytics".
    • Метка времени выходных данных отстает от реального времени. В зависимости от логики запроса метка времени вывода может иметь смещение логики от времени настенных часов. Тем не менее они будут выполняться примерно с такой же скоростью. Если метка времени выходных данных отстает все сильнее, это является индикатором того, что система перегружена. Это может быть результатом нисходящего регулирования приемника выходных данных или высокой загрузки ЦП. В настоящее время метрика использования процессора не предоставляется, поэтому их может быть трудно различить.
      • Если проблема связана с регулированием приемника, необходимо увеличить количество выходных секций (а также входных секций для полной параллелизации задания) или увеличить объем ресурсов приемника (например, количество единиц запросов для Cosmos DB).
    • На схеме заданий есть метрика события невыполненной работы секции для каждого входного ввода. Если метрика событий невыполненных работ продолжает увеличиваться, это означает, что системные ресурсы ограничены (из-за регулирования приемника выходных данных или высокой загрузки ЦП).
  • После определения ограничений того, что может достичь одного задания SU V2, вы можете экстраполировать линейно емкость обработки задания при добавлении дополнительных единиц SUS, при условии, что у вас нет каких-либо данных, что делает определенную секцию "горячей".

Примечание.

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

Случай 2. Если запрос не смущает параллель.

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

  • Начните с запроса без СЕКЦИОНИРОВАНИЯ BY сначала, чтобы избежать сложности секционирования, и запустите запрос с 1 SU V2, чтобы измерить максимальную нагрузку, как в случае 1.
  • Если вы можете достичь ожидаемой нагрузки в течение срока пропускной способности, все готово. Кроме того, можно измерить одно задание с дробными узлами с 2/3 SU V2 и 1/3 SU V2, чтобы узнать минимальное количество единиц потоковой передачи, которые работают в вашем сценарии.
  • Если вы не можете достичь требуемой пропускной способности, попробуйте разбить запрос на несколько шагов, если у него еще нет нескольких шагов, и выделить до одного su V2 для каждого шага запроса. Например, если у вас есть три шага, выделите три su версии 2 в параметре "Масштаб".
  • Чтобы запустить такое задание, Stream Analytics помещает каждый шаг на свой собственный узел с выделенным ресурсом SU V2.
  • Если необходимая нагрузка по прежнему не достигнута, можно использовать PARTITION BY (СЕКЦИОНИРОВАНИЕ ПО) начиная с шагов ближе к входным данным. Для оператора GROUP BY , который не является естественно секционируемым, можно использовать локальный или глобальный статистический шаблон для выполнения секционированной ГРУППЫ BY , а затем непартиментированной ГРУППЫ BY. Например, если вы хотите подсчитать, сколько автомобилей проходит через каждый платный стенд каждые 3 минуты, а объем данных выходит за рамки того, что можно обрабатывать одним 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

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

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

Примечание.

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

Случай 3. Вы выполняете множество независимых запросов в задании.

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

В этом случае можно выполнить следующие действия.

  • В этом случае не используйте PARTITION BY в запросе
  • Уменьшите количество входных секций до наименьшего возможного значения 2, если вы используете Центры событий.
  • Запустите запрос с одной версией SU V2. С ожидаемой нагрузкой каждого вложенного запроса добавьте столько вложенных запросов, сколько возможно, пока задание не достигнет ограничений по системным ресурсам. Обратитесь к варианту 1 для симптомов, когда это происходит.
  • После того как вы задаете ограничение вложенного запроса, начните добавлять вложенный запрос в новое задание. Количество задач, выполняемых в зависимости от количества независимых запросов, должно быть линейным при отсутствии среза нагрузки. Затем можно предсказать, сколько заданий SU V2 необходимо выполнить в качестве функции числа клиентов, которые вы хотите обслуживать.
  • При использовании соединения справочных данных с такими запросами, необходимо объединить входные данные перед соединением с теми же ссылочными данными, а затем, если необходимо, разделить события. Затем, при необходимости, разделите события. В противном случае каждое соединение ссылочных данных будет хранить ссылочные данные в памяти, что вызовет излишнее использование памяти.

Примечание.

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

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

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

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