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

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

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

Случай 1 – Ваш запрос по сути полностью параллелизуем между входными разделами.

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

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

Замечание

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

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

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

  • Начните с запроса без PARTITION BY для начала, чтобы избежать сложности секционирования, и запустите запрос с 1 SU V2, чтобы измерить максимальную нагрузку, как в Case 1.
  • Если вы можете достичь ожидаемой нагрузки с точки зрения пропускной способности, вы завершили. В качестве альтернативы, можно выбрать выполнение того же задания с использованием дробных узлов на 2/3 SU V2 и 1/3 SU V2, чтобы определить минимальное количество единиц потоковой передачи, которые подходят для вашего сценария.
  • Если вы не можете достичь требуемой пропускной способности, попробуйте разбить запрос на несколько этапов, если он еще не разбит, и выделите до одного SU V2 на каждый этап в запросе. Например, если у вас есть три шага, назначьте три SU V2 в параметре "Масштаб".
  • Чтобы запустить такое задание, 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, чтобы каждая секция была размещена на своем собственном узле обработки.

Замечание

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

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

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

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

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

Замечание

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

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

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

Дальнейшие шаги

  • Last updated on