Azure Synapse Analytics でのワークロードを管理する

10 分

Azure Synapse Analytics では、ワークロードが競合している場合にリソースの可用性を作成、制御、管理できます。これにより、使用可能なリソースのために待機しているときに、各ワークロードの相対的な重要度を管理できます。

読み込み時間を短縮するために、"重要度" を above_normal または High に設定して、読み込みユーザーのワークロード分類子を作成できます。ワークロードの重要度により、優先度の低い他の待機中のタスクよりも読み込みが優先されます。ワークロードの分離のための独自のワークロードグループの定義と併せて使用して、繁忙期および閑散期のリソース割り当ての最小値と最大値を管理します。

Azure Synapse の専用 SQL プールのワークロード管理は、次の 3 つの大まかな概念で構成されています。

ワークロードの分類
ワークロードの重要度
ワークロードの分離

これらの機能により、ワークロードによるシステムリソースの活用方法をより細かく制御できます。

ワークロード分類

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

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

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

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

ワークロードの重要度

ワークロードの重要度は、要求がリソースにアクセスする順序に影響します。ビジー状態のシステムでは、重要度の高い要求がリソースに最初にアクセスします。重要度によって、ロックへの順次アクセスも保証されます。重要度のレベルには、low、below_normal、normal、above_normal、high の 5 つがあります。重要度が設定されない要求には、既定のレベルである normal が割り当てられます。同じ重要度レベルが設定された要求については、現時点で存在しているスケジュール動作と同じになります。

ワークロードの分離

ワークロードの分離では、ワークロードグループのリソースが予約されます。ワークロードグループに予約されているリソースは、そのワークロードグループのみで実行されるように保証されます。ワークロードグループでは、リソースクラスと同様に、要求ごとに割り当てられるリソースの量を定義することもできます。ワークロードグループを使用すると、一連の要求で消費できるリソースの量を予約したり上限を設定したりできます。最後に、ワークロードグループは、クエリタイムアウトなどのルールを要求に適用するためのメカニズムです。

ワークロード管理を実行するには、次の手順を実行します

ワークロード分類子を作成して、特定のクエリに重要度を追加する

組織から、CEO によって実行されるクエリを他のユーザーより重要なものとしてマークして、大量のデータ読み込みやキュー内の他のワークロードが原因で低速に見えないようにする方法がないか聞かれました。ワークロード分類子を作成し、重要度を追加して、CEO のクエリを優先することにしました。

[開発] ハブを選択します。
[開発] メニューの [+] ボタン (1) を選択し、コンテキストメニューから [SQL スクリプト] (2) を選択します。
ツールバーメニューで、SQL プール データベースに接続してクエリを実行します。

クエリウィンドウで、スクリプトを次のように置き換えて、asa.sql.workload01 (組織の CEO を表す) または asa.sql.workload02 (プロジェクトで作業しているデータアナリストを表す) としてログインしているユーザーによる現在実行中のクエリがないことを確認します。

--First, let's confirm that there are no queries currently being run by users logged in workload01 or workload02

SELECT s.login_name, r.[Status], r.Importance, submit_time, 
start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s 
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload01','asa.sql.workload02') and Importance
is not NULL AND r.[status] in ('Running','Suspended') 
--and submit_time>dateadd(minute,-2,getdate())
ORDER BY submit_time ,s.login_name

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

クエリが実行されていないことを確認したので、次に、システムで多くのクエリを実行し、asa.sql.workload01 と asa.sql.workload02 の動作を確認する必要があります。これを行うには、クエリをトリガーする Azure Synapse パイプラインを実行します。
[統合] ハブを選択します。
[Lab 08 - Execute Data Analyst and CEO Queries] (ラボ 08 - データ分析と CEO クエリを実行する) パイプライン (1) を選択します。これは、asa.sql.workload01 と asa.sql.workload02 クエリを実行またはトリガーします。 [トリガーの追加] (2) を選択し、[今すぐトリガーする] (3) を選択します。表示されるダイアログで、[OK] を選択します。

トリガーされたクエリをシステムに投入ときに何が起こったかを見てみましょう。クエリウィンドウで、スクリプトを次のように置き換えます。

SELECT s.login_name, r.[Status], r.Importance, submit_time, start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s 
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload01','asa.sql.workload02') and Importance
is not NULL AND r.[status] in ('Running','Suspended') and submit_time>dateadd(minute,-2,getdate())
ORDER BY submit_time ,status

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

次のような出力が表示されます。

すべてのクエリの重要度レベルが normal に設定されていることに注意してください。
asa.sql.workload01機能を実装することによって、asa.sql.workload01 ユーザークエリの優先順位を指定します。クエリウィンドウで、スクリプトを次のように置き換えます。
```
IF EXISTS (SELECT * FROM sys.workload_management_workload_classifiers WHERE name = 'CEO')
BEGIN
    DROP WORKLOAD CLASSIFIER CEO;
END
CREATE WORKLOAD CLASSIFIER CEO
  WITH (WORKLOAD_GROUP = 'largerc'
  ,MEMBERNAME = 'asa.sql.workload01',IMPORTANCE = High);
```
このスクリプトを実行して、largerc ワークロードグループを使用してクエリの重要度レベルを High に設定する、CEO という名前の新しいワークロード分類子を作成します。
ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。
次に、クエリをシステムに投入し、asa.sql.workload01 および asa.sql.workload02 クエリの結果を確認してみましょう。これを行うには、クエリをトリガーする Azure Synapse パイプラインを実行します。 Integrate タブを選択し、[Lab 08 - Execute Data Analyst and CEO Queries] (ラボ 08 - データ分析と CEO クエリを実行する) パイプラインを実行します。これにより、asa.sql.workload01 および asa.sql.workload02 クエリが実行またはトリガーされます。

クエリウィンドウで、スクリプトを次のように置き換えて、今回は asa.sql.workload01 クエリがどのように動作するかを確認します。

SELECT s.login_name, r.[Status], r.Importance, submit_time, start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s 
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload01','asa.sql.workload02') and Importance
is not NULL AND r.[status] in ('Running','Suspended') and submit_time>dateadd(minute,-2,getdate())
ORDER BY submit_time ,status desc

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

次のような出力が表示されます。

asa.sql.workload01 ユーザーによって実行されるクエリの重要度が asa.sql.workload01 であることに注意してください。
[監視] ハブを選択します。
[パイプラインの実行] (1) を選択し、[実行中] (3) とマークされている各 Lab 08 パイプラインの [再帰のキャンセル] (2) を選択します。これにより、残りのタスクを高速化できます。

ワークロードの分離を使用して特定のワークロードのリソースを予約する

ワークロードの分離とは、リソースがワークロードグループ専用で予約されることを意味します。ワークロードグループは、一連の要求のコンテナーであり、ワークロードの分離などのワークロードの管理をシステム上で構成するための基礎となります。単純なワークロード管理構成では、データの読み込みとユーザークエリを管理できます。

ワークロードの分離がされない場合、要求はリソースの共有プールで動作します。共有プール内のリソースへのアクセスは保証されず、重要度基準で割り当てられます。

Tailwind Traders が提供するワークロードの要件を考慮して、CEO によって実行されるクエリのリソースを予約する CEODemo という新しいワークロードグループを作成することにしました。

まず、さまざまなパラメーターを試してみましょう。

クエリウィンドウで、スクリプトを次のように置き換えます。
```
IF NOT EXISTS (SELECT * FROM sys.workload_management_workload_groups where name = 'CEODemo')
BEGIN
    Create WORKLOAD GROUP CEODemo WITH  
    ( MIN_PERCENTAGE_RESOURCE = 50        -- integer value
    ,REQUEST_MIN_RESOURCE_GRANT_PERCENT = 25 --  
    ,CAP_PERCENTAGE_RESOURCE = 100
    )
END
```
このスクリプトでは、CEODemo というワークロードグループを作成し、そのワークロードグループ専用のリソースを予約します。この例では、MIN_PERCENTAGE_RESOURCE が 50% に設定され、REQUEST_MIN_RESOURCE_GRANT_PERCENT が 25% に設定されているワークロードグループに、2 つの同時実行が保証されます。
ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。
クエリウィンドウで、スクリプトを次のように置き換えて、ワークロードグループと、着信要求に重要度を割り当てる CEODreamDemo というワークロード分類子を作成します。
```
IF NOT EXISTS (SELECT * FROM sys.workload_management_workload_classifiers where  name = 'CEODreamDemo')
BEGIN
    Create Workload Classifier CEODreamDemo with
    ( Workload_Group ='CEODemo',MemberName='asa.sql.workload02',IMPORTANCE = BELOW_NORMAL);
END
```
このスクリプトは、新しい CEODreamDemo ワークロード分類子を使用して、asa.sql.workload02 ユーザーに対して重要度を BELOW_NORMAL に設定します。
ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

クエリウィンドウで、スクリプトを次のように置き換えて、asa.sql.workload02 により実行されているアクティブなクエリがないことを確認します (中断されたクエリは OK です)。

SELECT s.login_name, r.[Status], r.Importance, submit_time,
start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload02') and Importance
is not NULL AND r.[status] in ('Running','Suspended')
ORDER BY submit_time, status

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。
[統合] ハブを選択します。
[ラボ 08 - ビジネスアナリストクエリを実行する] パイプライン (1) を選択します。これにより、asa.sql.workload02 クエリが実行またはトリガーされます。 [トリガーの追加] (2) を選択し、[今すぐトリガーする] (3) を選択します。表示されるダイアログで、[OK] を選択します。

クエリウィンドウで、スクリプトを次のように置き換えて、トリガーされ、システムに投入されたすべての asa.sql.workload02 クエリに何が起こったかを確認します。

SELECT s.login_name, r.[Status], r.Importance, submit_time,
start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload02') and Importance
is not NULL AND r.[status] in ('Running','Suspended')
ORDER BY submit_time, status

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

次のような出力が表示され、各セッションの重要度が below_normal に設定されています。

実行中のスクリプトが asa.sql.workload02 ユーザー asa.sql.workload02 によって below_normal (2) の重要度レベルで実行されていることに注意してください。 CEO のクエリよりも低い重要度で実行するようにビジネスアナリストのクエリを構成することに成功しました。 CEODreamDemo ワークロード分類子が期待どおりに動作することを確認することもできます。
[監視] ハブを選択します。
[パイプラインの実行] (1) を選択し、[実行中] (3) とマークされている各 Lab 08 パイプラインの [再帰のキャンセル] (2) を選択します。これにより、残りのタスクを高速化できます。
[開発] ハブの下にあるクエリウィンドウに戻ります。クエリウィンドウで、スクリプトを次のように置き換えて、要求ごとに 3.25% の最小リソースを設定します。
```
IF  EXISTS (SELECT * FROM sys.workload_management_workload_classifiers where group_name = 'CEODemo')
BEGIN
    Drop Workload Classifier CEODreamDemo
    DROP WORKLOAD GROUP CEODemo
    --- Creates a workload group 'CEODemo'.
        Create  WORKLOAD GROUP CEODemo WITH  
    (MIN_PERCENTAGE_RESOURCE = 26 -- integer value
        ,REQUEST_MIN_RESOURCE_GRANT_PERCENT = 3.25 -- factor of 26 (guaranteed more than 4 concurrencies)
    ,CAP_PERCENTAGE_RESOURCE = 100
    )
    --- Creates a workload Classifier 'CEODreamDemo'.
    Create Workload Classifier CEODreamDemo with
    (Workload_Group ='CEODemo',MemberName='asa.sql.workload02',IMPORTANCE = BELOW_NORMAL);
END
```
注意

ワークロードの包含の構成では、コンカレンシーの最大レベルが暗黙的に定義されます。 CAP_PERCENTAGE_RESOURCE を 60% に設定し、REQUEST_MIN_RESOURCE_GRANT_PERCENT を 1% に設定した場合、ワークロードグループではレベル 60 のコンカレンシーが保証されます。最大コンカレンシーを決定するには、次に含まれるメソッドを検討してください: [Max Concurrency] = [CAP_PERCENTAGE_RESOURCE] / [REQUEST_MIN_RESOURCE_GRANT_PERCENT]
ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。
システムにもう一度投入し、asa.sql.workload02 に何が起こるかを見てみましょう。これを行うには、クエリをトリガーする Azure Synapse パイプラインを実行します。 [Integrate] タブを選択します。[ラボ 08 - ビジネスアナリストクエリを実行する] パイプラインを [実行] します。これにより、asa.sql.workload02 クエリが実行またはトリガーされます。

SELECT s.login_name, r.[Status], r.Importance, submit_time,
start_time ,s.session_id FROM sys.dm_pdw_exec_sessions s
JOIN sys.dm_pdw_exec_requests r ON s.session_id = r.session_id
WHERE s.login_name IN ('asa.sql.workload02') and Importance
is  not NULL AND r.[status] in ('Running','Suspended')
ORDER BY submit_time, status

ツールバーメニューから [実行] を選択して、SQL コマンドを実行します。

しばらくすると (最大 1 分)、asa.sql.workload02 の重要度で実行されている asa.sql.workload02 ユーザーによる複数の同時実行が表示されます。変更したワークロードグループとワークロード分類子が想定どおりに動作することを検証しました。
[監視] ハブを選択します。
[パイプラインの実行] (1) を選択し、[実行中] (3) とマークされている各 Lab 08 パイプラインの [再帰のキャンセル] (2) を選択します。これにより、残りのタスクを高速化できます。