SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作

2025-02-04

この記事では、SQL ウェアハウスのクラスターのサイズ設定、キュー、および自動スケーリングの動作について説明します。

サイズ設定の概要

SQL ウェアハウスは、サーバーレス、プロ、クラシックの各種類で利用できます。これらの種類のパフォーマンス機能と最適化は、ウェアハウスのクエリのパフォーマンスに影響を与える可能性があります。「SQL ウェアハウスの種類」を参照してください。 Databricks では、使用可能な場合はサーバーレス SQL ウェアハウスを使用することをお勧めします。

どの種類の倉庫でも、そのコンピューティングリソースの クラスターサイズ を選択します。 Databricks SQL ウェアハウスのサイズを最適化するには、データボリュームやユーザー数以上の要素を考慮する必要があります。クエリの複雑さと同時クエリの数も、パフォーマンスの重要な要因です。

Databricks SQL ウェアハウスでは、動的コンカレンシーを使用してこれらの要求を処理します。 Databricks SQL は、静的容量ウェアハウスとは異なり、同時実行負荷を管理し、スループットを最大化するために、コンピューティングリソースをリアルタイムで調整します。各倉庫サイズカテゴリにはユニットあたりの固定コンピューティング容量がありますが、システムはさまざまな需要に対応するためにリソースの数をスケーリングします。

SQLウェアハウスのクラスターサイズ

このセクションの表で、SQL Warehouse クラスターのサイズを Azure Databricks クラスタードライバーのサイズとワーカーの数にマップします。ドライバーのサイズは、プロおよびクラシック SQL ウェアハウスにのみ適用されます。

注

サーバーレス SQL ウェアハウスの場合、クラスターのサイズは、場合によっては、同等のクラスターサイズに対してプロおよびクラシック SQL ウェアハウスのドキュメントに記載されているものとは異なるインスタンスの種類を使用する場合があります。一般に、サーバーレス SQL ウェアハウスのクラスターサイズの価格/パフォーマンス比は、プロおよびクラシック SQL ウェアハウスのものと同様です。

クラスターサイズ	ドライバーのインスタンスの種類 (プロおよびクラシック SQL ウェアハウスにのみ適用されます)	ワーカー数
2 倍小	Standard_E8ds_v4	1 x Standard_E8ds_v4
微小	Standard_E8ds_v4	2 x Standard_E8ds_v4
小さい	Standard_E16ds_v4	4 × Standard_E8ds_v4
ミディアム	Standard_E32ds_v4	8 x Standard_E8ds_v4
大きい	Standard_E32ds_v4	16 x Standard_E8ds_v4
X-Large	Standard_E64ds_v4	32 x Standard_E8ds_v4
2 倍大	Standard_E64ds_v4	64 x Standard_E8ds_v4
3 倍大	Standard_E64ds_v4	128 x Standard_E8ds_v4
4 倍大	Standard_E64ds_v4	256 x Standard_E8ds_v4

すべてのワーカーのインスタンスサイズは Standard_E8ds_v4 です。

各ドライバーとワーカーには、8 台の 128 GB の Standard LRS マネージドディスクが接続されています。接続されたディスクは 1 時間ごとに課金されます。

クラシックおよびプロ SQL ウェアハウスに必要な Azure vCPU クォータ

クラシックまたはプロ SQL ウェアハウスを開始するには、Azure アカウントの Standard_E8ds_v4 インスタンスに十分な Azure vCPU クォータが必要です。次のガイドラインを使用して、必要な vCPU クォータを決定します。

SQL ウェアハウスが 1 つまたは 2 つしかない場合は、クラスター内のコアごとに 8 つの Azure vCPU が使用可能であることを確認します。これにより、ウェアハウスの再プロビジョニングを可能にする適切な Azure vCPU が確保されます。これは、約 24 時間ごとに行われます。 SQL ウェアハウスで自動スケーリングまたはマルチクラスター負荷分散を使用する場合は、乗数を増やす必要がある場合があります。

SQL ウェアハウスの数が増えるにつれて、クラスター内の各コアに対して 4 個から 8 個の Azure vCPU を使用できるようになります。 Databricks は、より多くの個数で始め、安定性のために監視することをお勧めします。
SQL ウェアハウスで使用される Azure vCPU は、Data Science & Engineering または Databricks 以外のワークロードによって使用されるクラスターによって使用される Azure vCPU に加えて使用されます。

追加の Azure vCPU クォータを要求するには、Azure ドキュメントの「標準クォータ: VM シリーズでの制限の引き上げ」を参照してください。

注

この表の情報は、製品またはリージョンの可用性とワークスペースの種類によって異なる場合があります。

プロおよびクラシックの SQL ウェアハウスのキューと自動スケーリング

Azure Databricks は、結果を計算するコストに基づいて、SQL Warehouse に割り当てられるクラスターのクエリ数を制限します。ウェアハウスごとのクラスターのアップスケーリングは、クエリのスループット、受信クエリのレート、キューのサイズに基づきます。 Databricks では、10 個の同時クエリごとにクラスターが推奨されます。全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。

Azure Databricks は、現在実行中のすべてのクエリ、キューに置かれたすべてのクエリ、および次の 2 分間に予想される受信クエリを処理するのにかかる時間に基づいてクラスターを追加します。

2 分未満の場合は、スケールアップしないでください。
2 分から 6 分の場合は 1 つのクラスターを追加します。
6 分から 12 分の場合は 2 つのクラスターを追加します。
12 分から 22 分の場合は 3 つのクラスターを追加します。

それ以外の場合は、Azure Databricks は、予想されるクエリ負荷の追加の 15 分ごとに、3 つのクラスターに加えて 1 つのクラスターを追加します。

さらに、クエリがキュー内で 5 分間待機する場合、ウェアハウスは常にアップスケールされます。

負荷が 15 分間低下した場合、Azure Databricks は SQL Warehouse をダウンスケールします。これにより、過去 15 分間のピーク負荷を処理するのに十分なクラスターが維持されます。たとえば、ピーク時の負荷が 25 個の同時実行クエリの場合、Azure Databricks は 3 個のクラスターを保持します。

サーバーレス自動スケールとクエリをキューに入れる

インテリジェントワークロード管理 (IWM) は、多数のクエリを迅速かつコスト効率よく処理するサーバーレス SQL ウェアハウスの機能を強化する一連の機能です。機械学習モデルを使用してワークロードを動的に管理し、ウェアハウスの使用可能なコンピューティング容量をリアルタイムで監視しながら、受信クエリのリソース需要を予測します。ウェアハウス内のこれらの信号やその他の信号をトラッキングすることで、IWM はワークロードの需要の変化に対応できます。

この動的管理により、IWM は次の操作を実行できます。

コンピューティングを迅速にアップスケールし、待機時間を短く維持します。
ハードウェアの制限に近いレートでクエリの許可を提供します。
需要が少ない場合にコストを最小化するために、迅速にスケールダウンします。

クエリがウェアハウスに到着すると、IWM はクエリのコストを予測します。同時に、IWM はウェアハウスの利用可能なコンピューティング容量をリアルタイムで監視しています。次に、機械学習モデルを使用して、IWMは、受信クエリが既存のコンピューティングで利用できる必要な計算が可能かどうかを予測します。必要なコンピューティングがない場合は、クエリがキューに追加されます。必要なコンピューティングがある場合、クエリはすぐに実行を開始します。

IWM は、キューをリアルタイムで監視します。キューが十分に速く減少していない場合、自動スケーリングにより、より多くのコンピューティングが自動的にプロビジョニングされます。新しい容量が追加されると、キューに入れられたクエリが新しいコンピューティングリソースに入ります。サーバーレス SQL ウェアハウスを使用すると、新しいコンピューティングを直ちに追加できます。全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。

サーバーレス SQL ウェアハウスのサイズ設定

まず、サーバーレス SQL ウェアハウスのサイズを、テスト時に必要と思うよりも大きくし、サイズを下げてください。サーバーレス SQL ウェアハウス用の小さなサイズから始めて、上に進めないでください。一般的には、単一サーバーレス SQL ウェアハウスから開始し、Azure Databricks に依存して、サーバーレスクラスター、ワークロードの優先順位付け、高速データ読み取りなどで適切なサイズにします。「サーバーレス自動スケールとクエリをキューに入れる」を参照してください。

サーバーレス SQL ウェアハウスのクエリ待ち時間を短縮するには、次のようにします。
- クエリがディスクに流出する場合は、T シャツのサイズを大きくしてください。
- クエリが高度に並列化されている場合は、T シャツのサイズを大きくしてください。
- 一度に複数のクエリを実行する場合は、自動スケール用にクラスターを追加してください。
コストを削減するには、ディスクにこぼしたり、待機時間を大幅に長くしたりせずに、サイズを下げてみます。

パフォーマンスを監視および評価するためのツール

SQL ウェアハウスのサイズを適切に設定するには、次のツールを使用します。

[監視] ページ: ピーク時のクエリ数を確認します。キューの登録ピークが一般的に 1 以上の場合は、クラスターを追加します。全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。「SQL Warehouse を監視する」を参照してください。
クエリの履歴。「クエリ履歴」を参照してください。
クエリプロファイル (ディスクに流出したバイト数が 1 以上であることを確認します)。「クエリプロファイル」を参照してください。