SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作
この記事では、SQL ウェアハウスのクラスターのサイズ設定、キュー、および自動スケーリングの動作について説明します。
サーバーレス SQL ウェアハウスのサイズ設定
サーバーレス SQL ウェアハウスの T シャツのサイズは、常に必要だと思われるサイズより大きめで開始し、テストしながらサイズを小さくしていきます。 サーバーレス SQL ウェアハウスの T シャツのサイズは、小さいものから始めて大きくしないでください。 一般的には、単一サーバーレス SQL ウェアハウスから開始し、Azure Databricks に依存して、サーバーレス クラスター、ワークロードの優先順位付け、高速データ読み取りなどで適切なサイズにします。 「サーバーレス自動スケールとクエリをキューに入れる」を参照してください。
- サーバーレス SQL ウェアハウスのクエリ待ち時間を短縮するには、次のようにします。
- クエリがディスクに流出する場合は、T シャツのサイズを大きくしてください。
- クエリが高度に並列化されている場合は、T シャツのサイズを大きくしてください。
- 一度に複数のクエリを実行する場合は、自動スケール用にクラスターを追加してください。
- コストを削減するには、ディスクに流出したり、待ち時間を大幅に増加させることなく、T シャツのサイズを段階的に小さくするようにします。
- サーバーレス SQL ウェアハウスの適切なサイズを設定するには、次のようなツールを使用します。
- 監視ページ: ピーク クエリ数に注目します。 キューの登録ピークが一般的に 1 以上の場合は、クラスターを追加します。 全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。 「SQL Warehouse を監視する」を参照してください。
- クエリの履歴。 「クエリ履歴」を参照してください。
- クエリ プロファイル (ディスクに流出したバイト数が 1 以上であることを確認します)。 「クエリ プロファイル」を参照してください。
Note
サーバーレス SQL ウェアハウスでは、クラスター サイズに関して、プロおよびクラシック SQL ウェアハウスのドキュメントに記載されている、同等のクラスター サイズに対応するものとは異なるインスタンスの種類が使われる場合があります。 一般に、サーバーレス SQL ウェアハウスのクラスター サイズの価格/パフォーマンス比は、プロおよびクラシック SQL ウェアハウスのものと同様です。
サーバーレス自動スケールとクエリをキューに入れる
インテリジェント ワークロード管理 (IWM) は、サーバーレス SQL ウェアハウスが大量のクエリを迅速かつコスト効率よく処理する能力を強化する一連の機能です。 機械学習モデルを使用してワークロードを動的に管理し、ウェアハウスの使用可能なコンピューティング容量をリアルタイムで監視しながら、着信クエリのリソース需要を予測します。 ウェアハウス内のこれらの信号やその他の信号をトラッキングすることで、IWM はワークロードの需要の変化に対応できます。
この動的管理により、IWM は次の操作を実行できます。
- コンピューティングを迅速にアップスケールし、待機時間を短く維持します。
- ハードウェアの上限に近い許可をクエリに入れます。
- 需要が少ない場合にコストを最小化するために、迅速にスケールダウンします。
クエリがウェアハウスに到着すると、IWM はクエリのコストを予測します。 同時に、IWM はウェアハウスの利用可能なコンピューティング容量をリアルタイムで監視しています。 次に、機械学習モデルを使用して、IWMは、受信クエリが既存のコンピューティングで利用できる必要な計算が可能かどうかを予測します。 必要なコンピューティングがない場合、クエリはキューに追加されます。 必要なコンピューティングがある場合、クエリはすぐに実行を開始します。
IWM は、キューを約 10 秒ごとに監視しています。 キューが十分早く減少しない場合、自動スケーリングが起動し、より多くのコンピューティングが迅速に確保されます。 新しい容量が追加されると、キューに入れられたクエリが新しいコンピューティング リソースに入ります。 サーバーレス SQL ウェアハウスを使用すると、新しいコンピューティングを直ちに追加できます。 全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。
プロおよびクラシックの SQL ウェアハウスのクラスター サイズ
このセクションの表で、SQL Warehouse クラスターのサイズを Azure Databricks クラスター ドライバーのサイズとワーカーの数にマップします。 ドライバーのサイズは、プロおよびクラシック SQL ウェアハウスにのみ適用されます。
| クラスター サイズ | ドライバーのインスタンスの種類 (プロおよびクラシック SQL ウェアハウスにのみ適用されます) | ワーカー数 |
|---|---|---|
| 2 倍小 | Standard_E8ds_v4 | 1 x Standard_E8ds_v4 |
| 微小 | Standard_E8ds_v4 | 2 x Standard_E8ds_v4 |
| Small | Standard_E16ds_v4 | 4 x Standard_E8ds_v4 |
| Medium | Standard_E32ds_v4 | 8 x Standard_E8ds_v4 |
| Large | 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 マネージド ディスクが接続されています。 接続されたディスクは時間単位で課金されます。
クラシックおよびプロ SQL ウェアハウスに必要な Azure vCPU クォータ
クラシックまたはプロ SQL ウェアハウスを開始するには、Azure アカウントの Standard_E8ds_v4 インスタンスに十分な Azure vCPU クォータが必要です。 次のガイドラインを使用して、必要な vCPU クォータを決定します。
- SQL ウェアハウスが 1 つまたは 2 つしかない場合は、クラスター内のコアごとに 8 個の Azure vCPU が使用可能であることを確認します。 これにより、ほぼ 24 時間ごとに実行されるウェアハウスの再プロビジョニングを考慮して、適切な Azure vCPU を確保することができます。 SQL ウェアハウスで自動スケールまたはマルチクラスターの負荷分散を使用する場合は、乗数の増加が必要になる可能性があります。
- SQL ウェアハウスの数が増えるにつれて、クラスター内の各コアに対して 4 個から 8 個の Azure vCPU を使用できるようになります。 Databricks は、より多くの個数で始め、安定性のために監視することをお勧めします。
- SQL ウェアハウスで使用される Azure vCPU は、Data Science & Engineering または Databricks 以外のワークロードで使用されるクラスターによって使用される Azure vCPU に加えて使用されます。
追加の Azure vCPU クォータを要求するには、Azure ドキュメントの「標準クォータ: VM シリーズでの制限の引き上げ」を参照してください。
Note
この表の情報は、製品またはリージョンの可用性とワークスペースの種類によって異なる場合があります。
プロおよびクラシックの SQL ウェアハウスのキューと自動スケーリング
Azure Databricks は、結果を計算するコストに基づいて、SQL Warehouse に割り当てられるクラスターのクエリ数を制限します。 ウェアハウスごとのクラスターのアップスケールは、クエリのスループット、受信クエリの割合と、キューのサイズに基づきます。 Azure Databricks では、10 個の同時クエリごとに 1 台のクラスターが推奨されます。 全種類の 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 個のクラスターを保持します。
プロおよびクラシックの SQL ウェアハウスのクエリをキューに入れる
ウェアハウスに割り当てられているすべてのクラスターが能力の限界までクエリを実行しているとき、またはウェアハウスが STARTING 状態であるとき、Azure Databricks はクエリをキューに入れます。 全種類の SQL ウェアハウスのキュー内のクエリの最大数は 1000 です。
ウェアハウスが STARTING 状態の場合を除き、メタデータ クエリ (たとえば DESCRIBE <table>) や状態の変更クエリ (たとえば SET) はキューに登録されません。