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

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

サイジングの概要

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

どのウェアハウスタイプでも、そのコンピュートリソースの クラスターサイズ を選択します。 Databricks SQL ウェアハウスのサイズを最適化するには、データ量やユーザー数を考慮するだけでは不十分です。クエリの複雑さと並列クエリの数も、パフォーマンスの主要な要因です。

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

クラスター sizes for SQLウェアハウス

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

注：

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

クラスターサイズ	ドライバーのインスタンスタイプ(proおよびclassic SQLウェアハウスにのみ適用)	ワーカー数
XXS	i3.2xlarge	1×i3.2xlarge
X-Small	i3.2xlarge	2 x i3.2xlarge
S	i3.4xlarge	4 x i3.2xlarge
M	i3.8xlarge	8 x i3.2xlarge
Large	i3.8xlarge	16個のx i3.2xlarge
X-Large	i3.16xlarge	32 x i3.2xlarge
XXL	i3.16xlarge	64 x i3.2xlarge
XXXL	i3.16xlarge	128個のi3.2xlarge
4X-Large	i3.16xlarge	256のx i3.2xlarge

すべてのワーカーのインスタンスサイズは i3.2xlarge です。ワークスペースでコンプライアンスセキュリティプロファイルが有効になっている場合、ウェアハウスはi3ではなくi3enインスタンスタイプを使用します。

注：

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

プロおよびクラシックSQLウェアハウスのアベイラビリティーゾーン (AZ)

SQLウェアハウスの場合、AWS アベイラビリティーゾーンは自動 (Auto-AZ) に設定され、ワークスペースサブネットで使用可能な IP に基づいて AZ が自動的に選択されます。自動 AZ は、AWS が容量不足エラーを返した場合に、他のアベイラビリティーゾーンで再試行します。アベイラビリティーゾーンの詳細については、 AWS のドキュメントを参照してください。

プロおよびクラシックSQLウェアハウスのキューイングとオートスケール

Databricks 、 SQLウェアハウスに割り当てられたクラスターに対するクエリの数を、その結果をコンピュートするためのコストに基づいて制限します。ウェアハウスあたりのクラスターのアップスケーリングは、クエリのスループット、受信クエリの速度、およびキューのサイズに基づいています。 Databricks では、10 個の並列クエリごとにクラスターを使用することをお勧めします。すべての SQLウェアハウスタイプのキュー内のクエリの最大数は 1000 です。

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

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

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

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

負荷が 15 分間低い場合、Databricks は SQLウェアハウスをダウンスケールします。過去 15 分間のピーク負荷を処理するのに十分なクラスターが保持されます。たとえば、ピーク負荷が 25 並列クエリーの場合、Databricks は 3 つのクラスターを保持します。

サーバレスのオートスケールとクエリーキューイング

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

この動的管理により、IWM は次のことを行うことができます。

コンピュートを迅速にアップスケールして、低遅延を維持します。
クエリのアドミタンスを、ハードウェアの制限に近いレートで提供します。
需要が少ないときにコストを最小限に抑えるために、迅速にダウンスケールします。

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

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

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

サーバレス SQLウェアハウスのサイズは、必要になると思うよりも大きいサイズから始めて、テストするときにサイズを小さくします。サーバレス SQLウェアハウス用の小さいサイズから始めて上に行くのはやめましょう。一般に、1 つのサーバレス SQLウェアハウスから始めて、サーバレスクラスターで適切なサイズに Databricks し、ワークロードを優先し、データ読み取りを高速化します。サーバレスオートスケールとクエリ・キューイングを参照してください。

特定のサーバレス SQLウェアハウスのクエリーレイテンシーを減らすには:
- クエリーがディスクにあふれている場合は、T シャツのサイズを大きくします。
- クエリーの並列化が可能な場合は、T シャツのサイズを大きくします。
- 一度に複数のクエリーを実行する場合は、オートスケールのクラスターをさらに追加します。
コストを削減するには、ディスクにこぼれたり、待機時間が大幅に増加したりしないように、サイズを段階的に縮小してみてください。

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

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

モニタリングページ: ピーククエリ数を確認します。キューに入れられるピークが一般的に 1 を超える場合は、クラスターを追加します。すべての SQLウェアハウスタイプのキュー内のクエリの最大数は 1000 です。「SQLウェアハウスの監視」を参照してください。
クエリ履歴。「クエリ履歴」を参照してください。
クエリプロファイル (1 より上の ディスクにあふれたバイト数 を探します)。「クエリプロファイル」を参照してください。