Azure Synapse Analytics の専用 SQL プールのワークロード分類

この記事では、Azure Synapse の専用 SQL プールを使用してワークロード グループと重要度を受信要求に割り当てるための、ワークロード分類プロセスについて説明します。

分類

ワークロード管理の分類では、リソース クラスと重要度を割り当てて、ワークロード ポリシーを要求に適用することができます。

データ ウェアハウスのワークロードを分類するにはさまざまな方法がありますが、最も簡単で一般的な分類は読み込みとクエリです。 データを読み込むには、INSERT、UPDATE、DELETE ステートメントを使用します。 データをクエリするには、SELECT を使用します。 データ ウェアハウス ソリューションには、多くの場合、より高いリソース クラスにはより多くのリソースを割り当てるなど、読み込みアクティビティに関するワークロード ポリシーがあります。 クエリには、読み込みアクティビティに比べて重要度を低くするなど、異なるワークロード ポリシーを適用できます。

読み込みとクエリのワークロードを下位分類することもできます。 下位分類を使用すると、ワークロードをより細かく制御できます。 たとえば、クエリ ワークロードがキューブの更新、ダッシュボードのクエリ、アドホック クエリで構成されているとします。 これらのクエリ ワークロードをそれぞれ異なるリソース クラスや重要度の設定で分類できます。 読み込みも、下位分類の利点を受けることができます。 大規模な変換を大規模なリソース クラスに割り当てることができます。 気象データやソーシャル データ フィードの前に主要な売上データが読み込まれるようにするため、より高い重要度を設定できます。

リソースを必要としないか、実行に影響を及ぼす重要度を必要としない一部のステートメントは分類されません。 DBCC コマンド、BEGIN、COMMIT、ROLLBACK TRANSACTION ステートメントは分類されません。

分類プロセス

現在、専用 SQL プールでの分類は、sp_addrolemember を使用して、対応するリソース クラスが割り当てられたロールにユーザーを割り当てることで実現されます。 1 つのリソース クラスへのログインを超えて要求を特徴付けることは、この機能によって制限されます。 より高度な分類方法として、CREATE WORKLOAD CLASSIFIER 構文を利用できるようになりました。 専用 SQL プール ユーザーは、この構文で workload_group パラメーターを使用して、要求に重要度を割り当て、割り当てるシステム リソース量を指定できます。

分類の重み付け

分類プロセスの一環として、どのワークロード グループを割り当てるかを判断するために重み付けが用意されています。 重み付けは次のようになります。

分類子パラメーター	Weight
MEMBERNAME:USER	64
MEMBERNAME:ROLE	32
WLM_LABEL	16
WLM_CONTEXT	8
START_TIME/END_TIME	4

MEMBERNAME パラメーターは必須です。 ただし、指定されたメンバー名がデータベース ロールではなくデータベース ユーザーである場合、ユーザーの重み付けの方が高くなるため、その分類子が選択されます。

ユーザーがさまざまなリソース クラスが割り当てられた、または複数の分類子が一致する複数のロールのメンバーである場合、そのユーザーには最上位のリソース クラスが割り当てられます。 この動作は、既存のリソース クラス割り当て動作と整合します。

Note

マネージド ID 動作の分類は、Azure Synapse ワークスペースの専用 SQL プールと、スタンドアロン専用 SQL プール (旧称 SQL DW) で異なります。 スタンドアロン専用 SQL プールのマネージド ID は割り当てられた ID を保持していますが、Azure Synapse ワークスペースでは、マネージド ID は dbo として実行します。 これは変更できません。 既定では、dbo ロールは smallrc に分類されます。 dbo ロールの分類子を作成すると、smallrc 以外のワークロード グループに要求を割り当てることができます。 dbo のみが分類に対して汎用的で、より広範な影響を与える場合は、ラベル、セッション、または時間ベースの分類を dbo ロールの分類と組み合わせて使用することを検討してください。

smallrc を除き、動的なリソース クラスは、定義済みのデータベース ロールとして実装されます。 smallrc はデータベース ロールとして表示されませんが、これは既定のリソース クラスです。

システム分類子

ワークロード分類には、システム ワークロード分類子が用意されています。 システム分類子は、既存のリソース クラス ロールのメンバーシップを通常の重要度でリソース クラスのリソース割り当てにマップします。 システム分類子は削除できません。 システム分類子を表示するには、次のクエリを実行します。

SELECT * FROM sys.workload_management_workload_classifiers where classifier_id <= 12

リソース クラス割り当てと分類子の併用

自動的に作成されるシステム分類子を利用すると、ワークロード分類に簡単に移行できます。 リソース クラス ロールのマッピングと分類の優先順位を併用すると、重要度を使用して新しい分類子を作成し始めるときに誤分類が起きやすくなります。

以下のシナリオについて考えてみます。

• 既存のデータ ウェアハウスで、データベース ユーザー DBAUser に largerc リソース クラス ロールが割り当てられています。 このリソース クラス割り当ては、sp_addrolemember. を使用して行われました。
• データ ウェアハウスのワークロード管理が更新されました。
• 新しい分類構文をテストするため、(DBAUser がそのメンバーである) データベース ロール DBARole を 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;

関連するコンテンツ

• 分類子の作成の詳細については、「CREATE WORKLOAD CLASSIFIER (Transact-SQL)」を参照してください。
• ワークロード分類子の作成方法については、ワークロード分類子の作成に関するクイック スタートを参照してください。
• ワークロードの重要度の構成と Workload Management の管理と監視に関するハウツー記事を参照してください。
• クエリと割り当てられている重要度を確認するには、「sys.dm_pdw_exec_requests」を参照してください。