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

Общие сведения об единице потоковой передачи и узле потоковой передачи

Единицы потоковой передачи (SUS) представляют вычислительные ресурсы, выполняющие задание Stream Analytics. Чем больше единиц SUS, тем больше ресурсов ЦП и памяти, которые вы выделяете для задания. Эта способность позволяет сосредоточиться на логике запросов и устраняет необходимость управления оборудованием для своевременного выполнения задания Stream Analytics.

Azure Stream Analytics поддерживает две структуры единиц потоковой передачи: SU V1 (не рекомендуется) и SU V2 (рекомендуется).

Модель SU V1 — это исходное предложение Azure Stream Analytics, где каждые 6 единиц SUS соответствуют одному узлу потоковой передачи для задания. Задания могут выполняться с 1 и 3 единицами SUS, и они соответствуют дробным узлам потоковой передачи. Масштабирование выполняется с шагом в 6 после 6 заданий SU, увеличиваясь до 12, 18, 24 и более, добавляя дополнительные потоковые узлы, которые предоставляют распределенные вычислительные ресурсы.

Модель SU V2 (рекомендуется) — это упрощенная структура с благоприятными ценами на те же вычислительные ресурсы. В модели SU V2 1 SU V2 соответствует одному стриминговому узлу для вашего задания. 2 SU V2s соответствуют 2 узлам потоковой передачи, 3–3 и т. д. Задачи с 1/3 и 2/3 SU V2 также доступны при использовании одного узла потоковой передачи, но с уменьшенной долей вычислительных ресурсов. Задачи 1/3 и 2/3 SU V2 являются экономичным решением для меньших по масштабу рабочих нагрузок.

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

Снимок экрана: таблица сопоставления SU V1 и SU V2.

Дополнительные сведения о ценах на SU см. на странице цен Azure Stream Analytics.

Общие сведения о преобразованиях единиц потоковой передачи и их применении

Система автоматически преобразует единицы потоковой передачи из слоя REST API в пользовательский интерфейс (портал Azure и Visual Studio Code). Это преобразование также отображается в журнале действий , где значения единиц потоковой передачи отличаются от значений пользовательского интерфейса. Это поведение является намеренным. Поля REST API ограничены целыми значениями, но задания Stream Analytics поддерживают дробные узлы (1/3 и 2/3 единиц потоковой передачи). Пользовательский интерфейс Azure Stream Analytics отображает значения узлов как 1/3, 2/3, 1, 2, 3 и т. д., а серверная часть (журналы действий, уровень REST API) отображает те же значения, умноженные на 10, 3, 7, 10, 20 и 30 соответственно.

Стандарт Стандартная версия 2 (пользовательский интерфейс) Стандартная версия 2 (серверная часть, например журналы, REST API и т. д.)
1 1/3 3
3 2/3 7
6 1 10
12 2 20
18 3 30
... ... ...

Это преобразование передает ту же степень детализации и устраняет десятичную точку на уровне API для единиц хранения запасов версии 2 (SKU). Это преобразование автоматически и не влияет на производительность задания.

Понимание потребления ресурсов и использования памяти

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

Показатель использования SU (%), который колеблется от 0% до 100%, описывает потребление памяти вашей рабочей нагрузки. Для потоковой задачи с минимальными ресурсами этот показатель обычно находится в диапазоне от 10 % до 20 %. Если использование SU% высоко (выше 80%) или если события ввода накапливаются (даже при низком использовании SU%, так как это не отображает использование ЦП), то для вашей рабочей нагрузки, скорее всего, требуется больше вычислительных ресурсов, что требует увеличить количество потоковых единиц. Для учета случайных всплесков лучше поддерживать метрику SU ниже 80 %. Чтобы своевременно реагировать на повышение объема рабочих нагрузок увеличением количества единиц потоковой передачи, настройте оповещение при значении 80 % для метрики потребления единиц потоковой передачи. Кроме того, вы можете использовать метрики предельной задержки и событий невыполненной работы, чтобы проверить влияние изменений.

Настройка единиц потоковой передачи Stream Analytics

  1. Войдите в портал Azure.

  2. В списке ресурсов найдите задание Stream Analytics для масштабирования и откройте его.

  3. На странице задания под заголовком Настройка выберите Масштаб. Количество SU по умолчанию равно 1 при создании задания.

Снимок экрана: меню на портале Azure Stream Analytics.

  1. Выберите параметр SU в раскрывающемся списке, чтобы задать SU для задания. Вы ограничены определённым диапазоном SU.

  2. Вы можете изменить количество единиц SUS, назначенных заданию во время его выполнения. При выполнении задания может возникнуть ограничение на выбор из набора значений SU, если задание использует неразделенные выходные данные или имеет многоэтапный запрос с разными значениями PARTITION BY.

Мониторинг производительности задания

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

Снимок экрана: мониторинг производительности заданий.

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

Сколько SUs требуется для задания?

Количество требуемых SU зависит от конфигурации разделов для вводов и определяемого в задании запроса. На странице Масштаб можно задать правильное количество SU. Выделите больше единиц, чем вы думаете, вам нужно. Подсистема обработки Stream Analytics оптимизирует задержку и пропускную способность за счет выделения дополнительной памяти.

Как правило, начните с 1 SU V2 для запросов, которые не используют PARTITION BY. Затем найдите лучшее число по пробе и ошибке. Измените количество сервисных единиц после передачи репрезентативных объемов данных и проверьте метрику уровня использования SU (%). Максимальное количество единиц потоковой передачи, которое может использовать задание Stream Analytics, зависит от количества шагов в запросе, определенного для задания, и количества секций на каждом шаге. Дополнительные сведения об ограничениях см. здесь.

Дополнительные сведения о выборе нужного количества единиц SUS см. в статье Масштабирование заданий Azure Stream Analytics для повышения пропускной способности.

Примечание.

Количество единиц SUS, необходимых заданию, зависит от конфигурации секции для входных данных и запроса, определенного для задания. Вы можете выбрать для задания количество единиц потоковой передачи согласно указанной квоте. Сведения о квоте подписки Azure Stream Analytics можно найти в разделе ограничения Stream Analytics. Чтобы увеличить количество SUs для своих подписок сверх этой квоты, свяжитесь со службой технической поддержки Майкрософт. Допустимые значения для SUs на задание: 1/3, 2/3, 1, 2, 3 и так далее.

Факторы, увеличивающие использование SU%

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

Задание со сложной логикой запросов может иметь высокий уровень использования SU%, даже если оно не постоянно получает входные события. Это может произойти после внезапного всплеска входных и выходных событий. При сложном запросе задача может продолжать поддерживать состояние в памяти.

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

При сравнении использования за период времени используйте метрики скорости событий. Метрики InputEvents и OutputEvents показывают, сколько событий было прочитано и обработано. Метрики, такие как ошибки десериализации, указывают количество событий ошибок. При увеличении числа событий на единицу времени в большинстве случаев повышается процент загрузки системы (SU%).

Логика запросов с отслеживанием состояния во временных элементах

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

Концепция временного окна представлена в следующих элементах запросов Stream Analytics.

  1. Оконные агрегаты: GROUP BY перекрывающиеся, перемещающиеся и скользящие окна

  2. Темпоральные соединения: JOIN с DATEDIFF функцией

  3. Функции темпоральной аналитики: ISFIRST, LASTи LAG с LIMIT DURATION

Следующие факторы влияют на объем памяти (элемент метрики единиц потоковой передачи), потребляемый заданиями Stream Analytics.

Оконные агрегаты

Объем потребляемой памяти (размер состояния) для агрегата оконного типа не всегда прямо пропорционален размеру окна. На самом деле, потребляемая память пропорциональна кратности данных или количеству групп в каждом периоде.

Например, в следующем запросе число, связанное с clusterid, является кратностью запроса. 

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Чтобы устранить проблемы, вызванные высокой кардинальностью в предыдущем запросе, отправьте события в Event Hubs, секционированные по clusterid. Масштабируйте запрос, позволяя системе обрабатывать каждую входную секцию отдельно с помощью PARTITION BY , как показано в следующем примере:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

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

Разбивайте Центры событий на секции по ключу группировки, чтобы избежать шага уменьшения. Дополнительные сведения см. в статье Что такое Центры событий? 

Временные объединения

Объем памяти (размер состояния) темпорального соединения пропорционален количеству событий в временном запасе соединения. Это число равно скорости ввода событий, умноженное на размер допустимых отклонений. Другими словами, объем памяти, потребляемой соединениями, пропорциональен диапазону времени DateDiff, умноженному на среднюю частоту событий.

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

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

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

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

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

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

Темпоральные аналитические функции

Объем используемой памяти (размер состояния) темпоральной аналитической функцией пропорциональен частоте событий, умноженной на длительность. Объем памяти, потребляемой функциями аналитики, не пропорциональна размеру окна, а к количеству секций в каждом окне времени.

Устранение аналогично темпоральному соединению. Вы можете масштабировать запрос с помощью PARTITION BY. 

Буфер с нарушением порядка

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

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

Количество входных секций

Каждый входной раздел задания имеет буфер. Чем больше число входных разделов, тем больше ресурсов использует задание. Для каждой единицы потоковой передачи Azure Stream Analytics может обрабатывать примерно 7 МБ/с входных данных. Таким образом можно выполнить оптимизацию, сопоставив число единиц потоковой передачи Stream Analytics с числом секций в концентраторе событий.

Как правило, задание, настроенное с одной третьей единицей потоковой передачи, достаточно для концентратора событий с двумя секциями (что является минимальным для концентратора событий). Если в концентраторе событий больше разделов, задание Stream Analytics потребляет больше ресурсов, но не обязательно использует дополнительную пропускную способность, предоставляемую концентратором событий.

Для задания с одной единицей потоковой обработки V2, может потребоваться 4 или 8 разделов из концентратора событий. Однако избегайте слишком большого количества ненужных разделов, так как они вызывают чрезмерное использование ресурсов. Например, концентратор событий с 16 секциями (и больше) в задании Stream Analytics с 1 единицей потоковой передачи.

Справочные данные

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

Использование определяемых пользователем функций

При добавлении функции UDF служба Azure Stream Analytics загружает в память среду выполнения JavaScript, что влияет на SU%.

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

  • Last updated on