Классификация рабочей нагрузки для выделенного пула SQL в Azure Synapse Analytics

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

Классификация

Классификация управления рабочими нагрузками позволяет применять политики рабочей нагрузки к запросам путем назначения классов ресурсов и их важности.

Существует множество способов классификации рабочих нагрузок хранилища данных, однако самая простая и наиболее распространенная классификация — это загрузка и запрос. Данные загружаются с помощью инструкций INSERT, UPDATE и DELETE. Для запроса данных используются инструкции SELECT. Решение для хранения данных зачастую имеет политику рабочей нагрузки для действия загрузки, например назначение более высокого класса ресурсов с большим количеством ресурсов. К запросам может применяться другая политика рабочей нагрузки, например низкая важность по сравнению с действиями загрузки.

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

Однако не все инструкции классифицируются, поскольку для выполнения им не требуются ресурсы или указание уровня важности. Команды консоли базы данных (DBCC), инструкции BEGIN, COMMIT и ROLLBACK TRANSACTION не классифицируются.

Процесс классификации

Классификация для выделенного пула SQL сегодня реализуется путем назначения пользователям роли, которой соответствует определенный класс ресурсов, с помощью sp_addrolemember. Возможность классифицировать запросы после входа с их распределением по классам ресурсов ограничена этой функциональностью. Благодаря синтаксису CREATE WORKLOAD CLASSIFIER теперь доступен более гибкий метод классификации. С помощью этого синтаксиса пользователи выделенного пула SQL могут назначать запросу важность и количество системных ресурсов через параметр workload_group.

Весовые коэффициенты классификации

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

Параметр классификатора Вес
MEMBERNAME:USER 64
MEMBERNAME:ROLE 32
WLM_LABEL 16
WLM_CONTEXT 8
START_TIME/END_TIME 4

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

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

Примечание

Классификация поведения управляемых экземпляров (MI) отличается в выделенном пуле SQL в рабочих областях Azure Synapse и в изолированном выделенном пуле SQL (ранее называвшемся Хранилище данных SQL). В изолированном выделенном пуле SQL Управляемый экземпляр сохраняет назначенное удостоверение, а в рабочих областях Azure Synapse он запускается в виде dbo. Это поведение изменить невозможно. По умолчанию роль "dbo" классифицируется в группу "smallrc". Создание классификатора для роли "dbo" позволяет назначать запросы другим группам рабочей нагрузки, помимо "smallrc". Если отдельно взятая роль "dbo" слишком широка для классификации и может повлечь дополнительные последствия, используйте с ней классификации меток и сеансов или классификацию на основе времени.

Системные классификаторы

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

SELECT * FROM sys.workload_management_workload_classifiers where classifier_id <= 12

Использование назначений классов ресурсов вместе с классификаторами

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

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

  • В имеющемся хранилище данных есть пользователь базы данных DBAUser, назначенный роли класса ресурсов largerc. Для назначения класса ресурсов использовалась процедура sp_addrolemember.
  • В хранилище данных развертывается система управления рабочими нагрузками.
  • Для проверки нового синтаксиса классификации для роли базы данных DBARole (к которой относится DBAUser) создается классификатор, связанный с классом ресурсов mediumrc и высокой важностью.
  • Когда DBAUser входит в систему и выполняет запрос, он назначается классу largerc. Это происходит, так как пользователь имеет приоритет над членством в роли.

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

SELECT  r.name AS [Resource Class]
,       m.name AS membername
FROM    sys.database_role_members rm
JOIN    sys.database_principals AS r ON rm.role_principal_id = r.principal_id
JOIN    sys.database_principals AS m ON rm.member_principal_id = m.principal_id
WHERE   r.name IN ('mediumrc','largerc','xlargerc','staticrc10','staticrc20','staticrc30','staticrc40','staticrc50','staticrc60','staticrc70','staticrc80');
--for each row returned run in the previous query
EXEC sp_droprolemember '[Resource Class]', membername;

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