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

Классификация рабочей нагрузки для выделенного пула 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.

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

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

Параметр классификатора Вес
Имя участника:Пользователь 64
MEMBERNAME:РОЛЬ 32
WLM_LABEL 16
WLM_CONTEXT 8
СТАРТ_ВРЕМЯ/КОНЕЦ_ВРЕМЯ 4

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

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

Примечание.

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

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