Важность рабочей нагрузки аналитики Azure синапсе

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

Важность

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

Уровни важности

Существует пять уровней важности: low, below_normal, normal, above_normal и high. Запросам, которые не задают важность, назначается стандартный уровень normal. Запросы с одинаковым уровнем важности имеют одинаковое поведение планирования, существующее сегодня.

Сценарии важности

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

Блокировка

Доступ к блокировкам для операций чтения и записи является одной областью естественного состязания. Для таких действий, как Переключение секций или ПЕРЕименование объектов , требуются повышенные блокировки. Без важности рабочей нагрузки выделенный пул SQL в Azure синапсе оптимизирует для пропускной способности. Оптимизация для пропускной способности означает, что если запросы на выполнение и очереди имеют те же требования к блокировке и доступны ресурсы, запросы в очереди могут обходить запросы с более высокими требованиями к блокировке, которые поступили в очередь запросов ранее. После применения важности рабочей нагрузки к запросам с более высокими требованиями к блокировке. Запрос с повышенной важностью будет выполняться перед запросом с более низкой важностью.

Рассмотрим следующий пример.

  • Q1 активно работает и выбирает данные из SalesFact.
  • Q2 находится в состоянии ожидания завершения Q1. Он был отправлен в 9:00 и пытается секционировать новые данные в SalesFact.
  • Q3 отправляется по адресу 9:01am и хочет выбрать данные из SalesFact.

Если Q2 и Q3 имеют одинаковую важность, а Q1 по-прежнему выполняется, то Q3 начнет выполняться. Q2 будет продолжать ожидать монопольной блокировки на SalesFact. Если Q2 имеет более высокий уровень важности, чем Q3, то Q3 будет ожидать завершения Q2, прежде чем он сможет начать выполнение.

Неоднородные запросы

Другой сценарий, где важность может помочь удовлетворить требования запроса, — это то, что передаются запросы с разными классами ресурсов. Как упоминалось ранее, при такой же важности выделенный пул SQL в Azure синапсе оптимизирует для пропускной способности. Если запросы смешанного размера (например, smallrc или mediumrc) помещаются в очередь, выделенный пул SQL выберет самый ранний запрос, поступающий в доступные ресурсы. Если применяется важность рабочей нагрузки, запрос с наибольшей важностью будет назначен далее.

Рассмотрим следующий пример в DW500c:

  • Q1, Q2, Q3 и Q4 выполняются с запросами smallrc.
  • Вопрос 5 отправляется с классом ресурсов mediumrc по адресу 9:00.
  • Вопрос 6 отправляется с классом ресурсов smallrc по адресу 9:01am.

Так как вопрос 5 — mediumrc, для него требуется два слота выдачи. Вопрос 5 должен ожидать завершения двух выполняющихся запросов. Однако при завершении одного из выполняемых запросов (Q1-Q4) вопрос 6 планируется немедленно, так как существуют ресурсы для выполнения запроса. Если вопрос 5 имеет более высокий уровень важности, чем вопрос 6, то вопрос 6 ждет, пока не будет запущен вопрос 5, прежде чем он сможет начать выполнение.

Дальнейшие действия