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

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

  • Статья

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

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

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

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

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

Однако не все инструкции классифицируются, поскольку для выполнения им не требуются ресурсы или указание уровня важности. DBCCкоманды, BEGINCOMMITROLLBACK 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 является обязательным. Однако если указанное имя члена является пользователем базы данных, а не ролью базы данных, то вес пользователя выше и таким образом выбирается классификатор.

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

Примечание.

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

За исключением smallrc, динамические классы ресурсов реализуются как предварительно определенные роли базы данных. Smallrc не отображается как роль базы данных, но является классом ресурсов по умолчанию.

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

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

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;

Связанный контент