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

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

Управление бессерверным хранилищем SQL

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

Интеллектуальное управление рабочими нагрузками и автомасштабирование

IWM использует модели машинного обучения для динамического управления вычислительными ресурсами:

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

Этот подход обеспечивает следующее:

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

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

Размер кластера (например, X-Small, Medium, Large) определяет вычислительные ресурсы, доступные для одного кластера. Средство автомасштабирования добавляет или удаляет кластеры этого размера по мере необходимости.

Используйте следующие рекомендации, чтобы помочь выбрать нужный размер:

• Начните с одного крупного хранилища и позвольте бессерверным функциям управлять параллелизмом и производительностью. Обычно это более эффективно, чтобы уменьшить размер, если это необходимо, чем начать небольшой и увеличить масштаб.
• Если запросы сбрасываются на диск, увеличьте размер кластера. Проверьте наличие растекания в профиле запроса.
• Для рабочих нагрузок с множеством параллельных запросов настройте достаточное максимальное количество кластеров для обработки пиковых нагрузок. Отслеживайте метрику "Пиковые запросы в очереди " на странице мониторинга хранилища.

Примечание.

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

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

Вы можете отслеживать и оптимизировать любое хранилище данных SQL с помощью этих средств. Максимальное количество запросов в очереди для всех типов хранилища — 1000.

• Страница мониторинга: На вкладке мониторинга хранилища SQL проверьте пиковые запросы в очереди. Согласованное значение выше 0 указывает, что может потребоваться более крупный размер кластера или несколько кластеров.
• Журнал запросов: Проверьте производительность журнала запросов, чтобы определить узкие места.
• Профиль запроса: Проверьте планы выполнения для метрик, таких как байты, разливаемые на диск, что означает, что размер хранилища может быть слишком мал.

Классические и профессиональные хранилища SQL

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

Настройка размера и подготовки кластера

Это важно

Размер кластера размером 5X в настоящее время находится в бета-версии для хранилищ pro и бессерверных хранилищ SQL. Администраторы рабочей области могут управлять доступом к этой функции на странице "Предварительные версии ". См. статью "Управление предварительными версиями Azure Databricks".

При создании классического или pro-хранилища выберите размер кластера и задайте минимальное и максимальное количество кластеров. Эти артикулы SKU имеют фиксированное ограничение: один кластер на каждые 10 одновременных запросов.

Размер кластера	Тип экземпляра драйвера	Количество работников
2X-Маленький	Standard_E8ds_v4	1 × Standard_E8ds_v4
X-Small	Standard_E8ds_v4	2 × 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-Большой	Standard_E64ds_v4	128 x Standard_E8ds_v4
4X-Large	Standard_E64ds_v4	256 x Standard_E8ds_v4
5X-большой	Standard_E64ds_v4	512 x Standard_E8ds_v4

Размер экземпляра всех работающих машин — Standard_E8ds_v4.

Каждому водителю и рабочему прикреплен один управляемый диск с премиальным SSD LRS объемом 256 ГБ. Подключенные диски оплачиваются почасово.

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

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

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

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

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

Примечание.

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

Логика очередей и автомасштабирования

Для классических и профессиональных хранилищ автомасштабирование добавляет кластеры на основе предполагаемого времени обработки всех выполняемых и очередных запросов:

• 2–6 минут загрузки запроса: добавьте 1 кластер.
• 6–12 минут: добавьте 2 кластера.
• 12–22 минуты: добавьте 3 кластера.
• Более 22 минут: добавьте 3 кластера плюс 1 кластер для каждых дополнительных 15 минут загрузки.

Дополнительные правила:

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