Поделиться через

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

  • Статья

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

Общие сведения о размерах

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

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

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

размеры кластеров для хранилищ SQL

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

Примечание.

Для бессерверных хранилищ SQL размеры кластеров в некоторых случаях могут использовать разные типы экземпляров, отличающиеся от перечисленных в документации по хранилищам pro и classic SQL для эквивалентного размера кластера. Как правило, соотношение цен и производительности размеров кластера для бессерверных хранилищ SQL аналогично значениям для хранилищ 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, с учетом затрат на вычисление их результатов. Масштабирование кластеров на хранилище зависит от пропускной способности запросов, скорости входящих запросов и размера очереди. 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 кластера.

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

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

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

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

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

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

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

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

  • Чтобы уменьшить задержку запросов для данного бессерверного хранилища SQL:
    • Если запросы сбрасываются на диск, увеличьте размер футболки.
    • Если запросы очень параллелизуются, увеличьте размер футболки.
    • Если одновременно выполняется несколько запросов, добавьте дополнительные кластеры для автомасштабирования.
  • Чтобы сократить затраты, попробуйте сократить размер, не перемещая на диск и не значительно увеличивая задержку.

Средства для мониторинга и оценки производительности

Чтобы помочь в оптимизации размера вашего склада данных SQL, используйте следующие средства:

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