Azure SQL Data Warehouse のワークロードの重要度Azure SQL Data Warehouse workload importance

この記事では、ワークロードの重要度が、SQL Data Warehouse の要求の実行順序にどのような影響を与えるかについて説明します。This article explains how workload importance can influence the order of execution for SQL Data Warehouse requests.

重要度Importance

ビジネス ニーズでは、データ ウェアハウスのワークロードを他よりも重要視することが求められる場合があります。Business needs can require data warehousing workloads to be more important than others. 会計期間が終了する前にミッション クリティカルな販売データが読み込まれるというシナリオを検討します。Consider a scenario where mission critical sales data is loaded before the fiscal period close. 気象データなど、その他のソースのデータ読み込には、厳密な SLA はありません。Data loads for other sources such as weather data don't have strict SLAs. 売上データのロード要求の重要度を高く設定し、気象データのロード要求の重要度を低く設定すると、売上データのロードがリソースに最初にアクセスしてより速く完了します。Setting high importance for a request to load sales data and low importance to a request to load weather data ensures the sales data load gets first access to resources and completes quicker.

重要度のレベルImportance levels

重要度のレベルには、low、below_normal、normal、above_normal、high の 5 つがあります。There are five levels of importance: low, below_normal, normal, above_normal, and high. 重要度が設定されない要求には、既定のレベルである normal が割り当てられます。Requests that don't set importance are assigned the default level of normal. 同じ重要度レベルが設定された要求については、現時点で存在しているスケジュール動作と同じになります。Requests that have the same importance level have the same scheduling behavior that exists today.

重要度のシナリオImportance scenarios

上記で説明した売上データと気象データに関する重要度の基本的なシナリオのほかに、さらに、データ処理およびクエリのニーズを満たす場合にワークロードの重要度が役に立つというシナリオもあります。Beyond the basic importance scenario described above with sales and weather data, there are other scenarios where workload importance helps meet data processing and querying needs.

ロックLocking

読み取りおよび書き込みアクティビティ用のロックへのアクセスは、自然な競合の 1 つの領域です。Access to locks for read and write activity is one area of natural contention. パーティションの切り替えオブジェクトの名前変更などのアクティビティには、管理者特権でのロックが必要です。Activities such as partition switching or RENAME OBJECT require elevated locks. ワークロードの重要度が設定されていなくても、SQL Data Warehouse ではスループットの最適化が行われます。Without workload importance, SQL Data Warehouse optimizes for throughput. スループットの最適化とは、実行中の要求とキューに置かれた要求が同じロック ニーズを持ち、リソースが利用可能な場合、キューに置かれた要求は、要求キューに先に到達した、より高いロック ニーズを持つ要求をバイパスする可能性があることを意味しています。Optimizing for throughput means that when running and queued requests have the same locking needs and resources are available, the queued requests can bypass requests with higher locking needs that arrived in the request queue earlier. より高いロック ニーズを持つ要求にワークロードの重要度が適用されると、Once workload importance is applied to requests with higher locking needs. 重要度の高い方の要求が、重要度の低い方の要求よりも先に実行されます。Request with higher importance will be run before request with lower importance.

次の例を確認してください。Consider the following example:

  • Q1 はアクティブに実行されていて、SalesFact からデータを選択しています。Q1 is actively running and selecting data from SalesFact.
  • Q2 はキューに置かれ、Q1 が完了するのを待機しています。Q2 is queued waiting for Q1 to complete. それは午前 9 時に送信され、SalesFact への新しいデータのパーティション切り替えを試みています。It was submitted at 9am and is attempting to partition switch new data into SalesFact.
  • Q3 は午前 9 時 01 分に送信され、SalesFact からデータを選択することを必要としています。Q3 is submitted at 9:01am and wants to select data from SalesFact.

Q2 と Q3 が同じ重要度を持ち、Q1 がまだ実行中である場合、Q3 は実行を開始します。If Q2 and Q3 have the same importance and Q1 is still executing, Q3 will begin executing. Q2 は引き続き SalesFact に対する排他的なロックを待機します。Q2 will continue to wait for an exclusive lock on SalesFact. Q2 の重要度が Q3 より高い場合、Q3 は Q2 が終了するのを待って実行を開始する必要があります。If Q2 has higher importance than Q3, Q3 will wait until Q2 is finished before it can begin execution.

均一でない要求Non-uniform requests

クエリ要求を満たすのに重要度を役立てることができるというもう 1 つのシナリオは、リソース クラスが異なる要求を送信する場合に適用されます。Another scenario where importance can help meet querying demands is when requests with different resource classes are submitted. 既に述べたように、同じ重要度の下では、SQL Data Warehouse のスループットが最適化されます。As was previously mentioned, under the same importance, SQL Data Warehouse optimizes for throughput. 混在したサイズ要求 (Smallrc または mediumrc など) がキューに置かれると、使用可能なリソース内で収まる最も早く到着した要求が SQL Data Warehouse によって選択されます。When mixed size requests (such as smallrc or mediumrc) are queued, SQL Data Warehouse will choose the earliest arriving request that fits within the available resources. ワークロードの重要度が適用されると、重要度の最も高い要求が次にスケジュールされます。If workload importance is applied, the highest importance request is scheduled next.

DW500c に対する次の例について考えてみてください。Consider the following example on DW500c:

  • Q1、Q2、Q3、および Q4 は、smallrc クエリを実行しています。Q1, Q2, Q3, and Q4 are running smallrc queries.
  • Q5 は、午前 9 時に mediumrc リソース クラスを使用して送信されます。Q5 is submitted with the mediumrc resource class at 9am.
  • Q6 は、午前 9 時 01 分に smallrc リソース クラスを使用して送信されます。Q6 is submitted with smallrc resource class at 9:01am.

Q5 は mediumrc であるために、2 つの同時実行スロットが必要になります。Because Q5 is mediumrc, it requires two concurrency slots. Q5 は、2 つの実行中のクエリが完了するまで待機する必要があります。Q5 needs to wait for two of the running queries to complete. ただし、実行中のクエリ (Q1 から Q4 まで) のいずれかが完了すると、クエリを実行するリソースが存在するため Q6 がすぐにスケジュールされます。However, when one of the running queries (Q1-Q4) completes, Q6 is scheduled immediately because the resources exist to execute the query. Q5 の重要度は Q6 よりも高いため、Q6 は Q5 が実行されるのを待って、実行を開始する必要があります。If Q5 has higher importance than Q6, Q6 waits until Q5 is running before it can begin executing.

次のステップNext steps