Размер, масштабирование и организация очереди в хранилище SQL

В этой статье объясняется поведение размера кластера, очереди и автоматического масштабирования хранилищ SQL.

Изменение размера бессерверного хранилища SQL

Всегда начинайте с большего размера футболки для вашего бессерверного хранилища SQL, чем вы думаете, что вам потребуется и размер по мере тестирования. Не начинайте с небольшого размера футболки для вашего бессерверного хранилища SQL и идти вверх. Как правило, начните с одного бессерверного хранилища SQL и использует Azure Databricks для правильного размера с бессерверными кластерами, приоритетами рабочих нагрузок и быстрых операций чтения данных. См . бессерверные автомасштабирование и очередь запросов.

• Чтобы уменьшить задержку запросов для данного бессерверного хранилища SQL:
  • Если запросы сбрасываются на диск, увеличьте размер футболки.
  • Если запросы очень параллелизуются, увеличьте размер футболки.
  • Если одновременно выполняется несколько запросов, добавьте дополнительные кластеры для автомасштабирования.
• Чтобы сократить затраты, попробуйте уйти в размер футболки без разлива на диск или значительно увеличить задержку.
• Чтобы помочь правильному размеру бессерверного хранилища SQL, используйте следующие средства:
  • Страница мониторинга: посмотрите на число пиковых запросов. Если пиковая очередь обычно превышает одну, добавьте кластеры. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000. См. раздел "Мониторинг хранилища SQL".
  • Журнал запросов. См . журнал запросов.
  • Профили запросов (поиск байтов, разливаемых на диск выше 1). См. раздел Профиль запроса.

Примечание.

Для бессерверных хранилищ SQL размеры кластера могут в некоторых случаях использовать разные типы экземпляров, отличные от перечисленных в документации по хранилищам pro и классических хранилищ SQL для эквивалентного размера кластера. Как правило, соотношение цен и производительности размеров кластера для бессерверных хранилищ SQL аналогично значениям для хранилищ pro и классических хранилищ SQL.

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

Интеллектуальное управление рабочими нагрузками (IWM) — это набор функций, которые повышают способность бессерверных хранилищ SQL обрабатывать большое количество запросов быстро и экономично. С помощью возможностей прогнозирования на основе искусственного интеллекта для анализа входящих запросов и определения самого быстрого и эффективного (прогнозного ввода-вывода) IWM работает, чтобы обеспечить быстрый объем ресурсов рабочих нагрузок. Ключевое различие заключается в возможностях искусственного интеллекта в Databricks SQL для динамического реагирования на требования рабочей нагрузки, а не с использованием статических пороговых значений.

Эта скорость реагирования обеспечивает:

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

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

IWM отслеживает очередь примерно каждые 10 секунд. Если очередь не уменьшается достаточно быстро, автомасштабирование запускается, чтобы быстро получить больше вычислений. После добавления новой емкости очереди запросы будут приняты в новые кластеры. С помощью бессерверных хранилищ SQL новые кластеры можно быстро добавлять и создавать несколько кластеров одновременно. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.

Размеры кластера для профессиональных и классических хранилищ SQL

В таблице в этом разделе сопоставлены размеры кластера хранилища SQL с размером драйвера Azure Databricks и количеством рабочих ролей. Размер драйвера применяется только к хранилищам pro и классического SQL.

Размер кластера	Тип экземпляра для драйвера (применяется только к хранилищам pro и классического SQL)	Количество рабочих ролей
2X-Small	Standard_E8ds_v4	1 x Standard_E8ds_v4
X-Small	Standard_E8ds_v4	2 x Standard_E8ds_v4
Небольшой	Standard_E16ds_v4	4 x Standard_E8ds_v4
Средняя	Standard_E32ds_v4	8 x Standard_E8ds_v4
Большой	Standard_E32ds_v4	16 x Standard_E8ds_v4
Очень крупный	Standard_E64ds_v4	32 x Standard_E8ds_v4
2X-Large	Standard_E64ds_v4	64 x Standard_E8ds_v4
3X-Large	Standard_E64ds_v4	128 x Standard_E8ds_v4
4X-Large	Standard_E64ds_v4	256 x Standard_E8ds_v4

Размер экземпляра всех рабочих ролей — Standard_E8ds_v4.

К каждому драйверу и рабочей роли подключено 8 управляемых дисков LRS уровня "Стандартный" по 128 ГБ. Подключенные диски оплачиваются почасово.

Требуемая квота виртуального ЦП Azure для классических и профессиональных хранилищ SQL

Чтобы запустить классическое или pro хранилище SQL, необходимо иметь достаточную квоту виртуального ЦП Azure для Standard_E8ds_v4 экземпляров в учетной записи Azure. Чтобы определить требуемую квоту виртуальных ЦП, следуйте приведенным ниже рекомендациям.

• Если у вас есть только одно или два хранилища SQL, убедитесь, что для каждого ядра в кластере доступно 8 виртуальных ЦП Azure. В таком случае в вашем распоряжении будет достаточно виртуальных ЦП Azure, чтобы учитывать повторную подготовку хранилища, которая выполняется примерно каждые 24 часа. Если хранилища SQL используют автоматическое масштабирование или балансировку нагрузки между несколькими кластерами, может потребоваться увеличить множитель.
• По мере увеличения количества хранилищ SQL используйте от 4 до 8 виртуальных ЦП Azure для каждого ядра в кластере. Databricks рекомендует начать с большего числа и отслеживать стабильность.
• Виртуальные ЦП Azure, используемые хранилищами SQL, в дополнение к виртуальным ЦП Azure, используемым кластерами, используемыми Обработка и анализ данных и инженерией или рабочими нагрузками, не использующий Databricks.

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

Примечание.

Сведения в этой таблице могут отличаться в зависимости от доступности продукта или региона и типа рабочей области.

Очереди и автоматическое масштабирование для pro и классических хранилищ SQL

Azure Databricks ограничивает количество запросов к кластеру, назначенному хранилищу SQL, с учетом затрат на вычисление их результатов. Увеличение числа кластеров на каждое хранилище основано на пропускной способности запросов, частоте входящих запросов и размере очереди. Azure Databricks рекомендует кластер для каждых 10 одновременных запросов. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.

Azure Databricks добавляет кластеры в зависимости от времени, необходимого для обработки всех текущих запросов, всех очередных запросов и входящих запросов, ожидаемых в течение следующих двух минут.

• Если менее 2 минут, не масштабируемые.
• Если 2–6 минут, добавьте 1 кластер.
• Если 6–12 минут, добавьте 2 кластера.
• Если 12–22 минуты, добавьте 3 кластера.

В противном случае Azure Databricks добавляет 3 кластера плюс 1 кластер для каждых 15 минут ожидаемой загрузки запроса.

Кроме того, хранилище всегда масштабируется, если запрос ожидает 5 минут в очереди.

При низкой загрузке в течение 15 минут Azure Databricks уменьшает количество кластеров для хранилища SQL. Сохраняется достаточное количество кластеров, чтобы справиться с пиковой нагрузкой за последние 15 минут. Например, если пиковая нагрузка составляла 25 параллельных запросов, Azure Databricks сохранит 3 кластера.

Очередь запросов для профессиональных и классических хранилищ SQL

Azure Databricks помещает запросы в очередь, если все назначенные хранилищу кластеры выполняют запросы с полной нагрузкой или если хранилище находится в состоянии STARTING. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.

Запросы к метаданным (например, DESCRIBE <table>) и запросы с изменением состояния (например SET) никогда не ставятся в очередь, если хранилище не находится в состоянии STARTING.