Azure Synapse Analytics の専用 SQL プール (以前の SQL DW) 用の Data Warehouse ユニット

[アーティクル]
10/30/2023

このドキュメントでは、価格とパフォーマンスを最適化するために専用 SQL プール (以前の SQL DW) の Data Warehouse ユニット (DWU) の最適な数を選択する際の推奨事項と、ユニットの数を変更する方法を示します。

Data Warehouse ユニットとは

専用 SQL プール (以前の SQL DW) は、プロビジョニングされている分析リソースのコレクションを表します。分析リソースは、CPU、メモリ、および IO の組み合わせとして定義されます。

これらの 3 つのリソースは、Data Warehouse ユニット (DWU) と呼ばれるコンピューティングスケールのユニットにバンドルされます。 DWU は、コンピューティングリソースとパフォーマンスの抽象的な正規化された単位を表します。

サービスレベルを変更すると、システムで使用できる DWU の数が変更され、それによってさらにシステムのパフォーマンスやコストが調整されます。

パフォーマンス向上のために、Data Warehouse ユニットの数を増やすことができます。パフォーマンスを低下させるには、Data Warehouse ユニットの数を減らします。ストレージのコストとコンピューティングのコストは、別々に請求されます。したがって、Data Warehouse ユニットの数を変更してもストレージコストには影響しません。

Data Warehouse ユニットのパフォーマンスは、次のようなデータウェアハウスのワークロードのメトリックに基づいています。

標準的な専用 SQL プール (以前の SQL DW) クエリがどれだけ速く多数の行をスキャンし、次に複雑な集計を実行できるか。これは I/O と CPU を集中的に使用する操作です。
専用 SQL プール (以前の SQL DW) がどれだけ速く Azure Storage Blob または Azure Data Lake からデータを取り込むことができるか。これはネットワークと CPU を集中的に使用する操作です。
CREATE TABLE AS SELECT T-SQL コマンドがどれだけ速くテーブルをコピーできるか。この操作には、ストレージからのデータの読み取り、アプライアンスのノード間でのデータ分散、ストレージへのデータの再書き込みが必要です。これは CPU、IO、ネットワークを集中的に使用する操作です。

DWU の数を増やすと、次のメリットが得られます。

スキャン、集計、CTAS ステートメントに関するシステムのパフォーマンスが直線的に向上します。
PolyBase の読み込み操作のリーダーとライターの数が増えます。
同時クエリとコンカレンシースロットの最大数が増えます。

サービスレベル目標

サービスレベル目標 (SLO) は、専用 SQL プール (以前の SQL DW) のコストとパフォーマンスレベルを決定するスケーラビリティ設定です。 Gen2 専用 SQL プール (以前の SQL DW) のサービスレベルは、DW2000c など、Data Warehouse ユニット (DWU) で測定されます。

注意

専用 SQL プール (以前の SQL DW) Gen2 には最近、DW100c 程度に低いコンピューティングレベルをサポートするための新しいスケーリング機能が追加されました。現在 Gen1 を使用していて小さいコンピューティングレベルを必要とする既存のデータウェアハウスでは、現在追加コストなしで利用可能なリージョンで Gen2 にアップグレードできます。お使いのリージョンがまだサポートされていない場合は、サポートされているリージョンにアップグレードできます。詳細については、Gen2 へのアップグレードに関するページを参照してください。

T-SQL では、SERVICE_OBJECTIVE 設定によって専用 SQL プール (以前の SQL DW) のサービスレベルとパフォーマンスレベルが決まります。

CREATE DATABASE mySQLDW
(Edition = 'Datawarehouse'
 ,SERVICE_OBJECTIVE = 'DW1000c'
)
;

パフォーマンスレベルと Data Warehouse ユニット

各パフォーマンスレベルで、Data Warehouse ユニットの測定単位は若干異なります。スケールの単位は課金に直接つながるため、この違いは請求書に反映されます。

Gen1 データウェアハウスは、データウェアハウス単位 (DWU) で測定されます。
Gen2 データウェアハウスは、コンピューティングデータウェアハウス単位 (cDWU) で測定されます。

DWU と cDWU はいずれも、コンピューティングのスケールアップとスケールダウン、データウェアハウスの使用が不要になった場合のコンピューティングの一時停止をサポートしています。これらの操作はすべて、オンデマンドで実行できます。 Gen2 では、パフォーマンス向上のためにコンピューティングノードでのローカルディスクベースのキャッシュを使用します。スケール操作やシステムの一時停止を行うと、このキャッシュが無効化されるため、最適なパフォーマンスを実現する前にキャッシュの準備期間が必要となります。

容量制限

各 SQL Server (たとえば myserver.database.windows.net) には、特定の数の Data Warehouse ユニットを許可するデータベーストランザクションユニット (DTU) クォータがあります。詳細については、ワークロード管理の容量制限に関する記事を参照してください。

必要な Data Warehouse ユニットの数

理想的な Data Warehouse ユニットの数は、ワークロードと、システムに読み込まれているデータの量に大きく依存します。

ワークロードに最適な DWU を特定する手順は次のとおりです。

最初に小さな DWU を選択します。
システムへのデータの読み込みをテストする際に、アプリケーションのパフォーマンスを監視し、選択した DWU の数に対するパフォーマンスの変化を観察します。
定期的なピークアクティビティ期間のための追加要件があれば識別します。アクティビティに顕著なピークと谷があることを示すワークロードには、頻繁なスケーリングが必要になる場合があります。

専用 SQL プール (以前の SQL DW) は、大量のコンピューティングをプロビジョニングし、相当な量のデータのクエリを実行できるスケールアウトシステムです。

特に大規模な DWU での実際のスケール機能を確認する場合は、CPU に十分なデータをフィードできるように、スケール時のデータセットのスケールを決定してください。スケールのテストでは、少なくとも 1 TB を使用することをお勧めします。

注意

コンピューティングノード間で作業を分割することができる場合、クエリのパフォーマンスを引き上げるには、並列処理を増やすしかありません。スケーリングしてもパフォーマンスが変わらない場合は、テーブルのデザインやクエリのチューニングが必要な可能性があります。クエリのチューニングの概要については、ユーザークエリの管理に関するページを参照してください。

アクセス許可

Data Warehouse ユニットを変更するには、「ALTER DATABASE」で説明されているアクセス許可が必要です。

SQL DB 共同作成者や SQL Server 共同作成者などの Azure 組み込みロールで DWU 設定を変更できます。

現在の DWU 設定の表示

現在の DWU 設定を表示するには、次の手順に従います。

Visual Studio で SQL Server オブジェクトエクスプローラーを開きます。
論理 SQL サーバーに関連付けられている master データベースに接続します。
sys.database_service_objectives 動的管理ビューから選択します。たとえば次のようになります。

SELECT  db.name [Database]
,        ds.edition [Edition]
,        ds.service_objective [Service Objective]
FROM    sys.database_service_objectives   AS ds
JOIN    sys.databases                     AS db ON ds.database_id = db.database_id
;

Data Warehouse ユニットの変更

Azure portal

DWU を変更するには、次の手順に従います。

Azure Portal を開き、データベースを開いて、 [スケール] をクリックします。
[スケール] で、スライダーを左または右に移動して DWU 設定を変更します。
[保存] をクリックします。確認メッセージが表示されます。 [はい] をクリックして確定します。キャンセルするには、 [いいえ] をクリックします。

PowerShell

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

DWU を変更するには、Set-AzSqlDatabase PowerShell コマンドレットを使用します。次の例では、MyServer サーバーにホストされているデータベース MySQLDW のサービスレベル目標を DW1000 に設定します。

Set-AzSqlDatabase -DatabaseName "MySQLDW" -ServerName "MyServer" -RequestedServiceObjectiveName "DW1000c"

詳細については、専用 SQL プール (以前の SQL DW) 用の PowerShell コマンドレットに関するページを参照してください

T-SQL

T-SQL で現在の DWU の設定を表示したり、設定を変更したり、進行状況を確認したりできます。

DWU を変更するには、次の手順に従います。

サーバーに関連付けられている master データベースに接続します。
ALTER DATABASE TSQL ステートメントを使います。次の例では、MySQLDW データベースのサービスレベル目標を DW1000c に設定します。

ALTER DATABASE MySQLDW
MODIFY (SERVICE_OBJECTIVE = 'DW1000c')
;

REST API

DWU を変更するには、データベースの作成または更新 REST API を使います。次の例では、サーバー MyServer でホストされているデータベース MySQLDW のサービスレベル目標を DW1000c に設定します。サーバーは "ResourceGroup1" という名前の Asure リソースグループ内にあります。

PUT https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}?api-version=2014-04-01-preview HTTP/1.1
Content-Type: application/json; charset=UTF-8

{
    "properties": {
        "requestedServiceObjectiveName": "DW1000c"
    }
}

その他の REST API の例については、専用 SQL プール (以前の SQL DW) 用の REST APIに関するページを参照してください。

DWU 変更の状態の確認

DWU の変更は、完了までに数分かかる場合があります。スケーリングを自動的に行う場合は、別のアクションに進む前に特定の操作が完了していることを確認するロジックを実装することを検討してください。

さまざまなエンドポイントを通じてデータベースの状態を確認することで、自動化を適切に実装できます。ポータルでは、操作の完了通知とデータベースの現在の状態が提供されます。ただし、プログラムを使って状態を確認することはできません。

Azure Portal でスケールアウト操作のデータベースの状態を確認することはできません。

DWU の変更の状態を確認するには、次の手順に従います。

サーバーに関連付けられている master データベースに接続します。

次のクエリを送信して、データベースの状態を確認します。

SELECT    *
FROM      sys.dm_operation_status
WHERE     resource_type_desc = 'Database'
AND       major_resource_id = 'MySQLDW'
;

この DMV は、操作や操作の状態 (IN_PROGRESS または COMPLETED のどちらか) などの専用 SQL プール (以前の SQL DW) に対するさまざまな管理操作に関する情報を返します。

スケーリングのワークフロー

スケール操作を開始すると、システムはまず、すべての開いているセッションを強制終了し、すべての開いているトランザクションをロールバックして整合性のある状態を確保します。スケール操作の場合、このトランザクションのロールバックが完了した後でのみスケーリングが行われます。

スケールアップ操作の場合、システムはすべてのコンピューティングノードをデタッチし、追加のコンピューティングノードをプロビジョニングした後、ストレージレイヤーに再アタッチします。
スケールダウン操作の場合、システムはすべてのコンピューティングノードをデタッチした後、必要なノードのみをストレージレイヤーに再アタッチします。

次のステップ

パフォーマンスの管理の詳細については、ワークロード管理用のリソースクラスと、メモリとコンカレンシーの制限に関するページを参照してください。