Amazon
Web Services
Microsoft Azure
Google Cloud PlatformSQLウェアハウスのサイジング、スケーリング、およびキューイングの動作
この記事では、SQLウェアハウスのクラスターのサイズ設定、キューイング、オートスケールの動作について説明します。
サーバレス SQLウェアハウスのサイズ設定
サーバレス SQLウェアハウスの T シャツのサイズは、必要と思われるサイズよりも大きく設定し、テスト時にサイズを小さくしてください。 サーバレス SQLウェアハウスの小さな T シャツ サイズから始めて増やしていくという方法はやめましょう。 一般に、1 つのサーバレス SQLウェアハウスから開始し、Databricks を使用してサーバレス クラスター、ワークロードの優先順位付け、高速データ読み取りで適切なサイズを設定します。 サーバレスのオートスケールとクエリーキューイングを参照してください。
特定のサーバレス SQLウェアハウスのクエリー レイテンシーを減らすには:
クエリーがディスクにあふれている場合は、T シャツのサイズを大きくします。
クエリーの並列化が可能な場合は、T シャツのサイズを大きくします。
一度に複数のクエリーを実行する場合は、オートスケールのクラスターをさらに追加します。
コストを削減するには、ディスクにこぼれたり、レイテンシーが大幅に増加したりすることなく、T シャツのサイズを小さくするようにしてください。
サーバレス SQLウェアハウスのサイズを適正化するには、次のツールを使用します。
モニタリング ページ: ピーク時のクエリ数を確認します。 キューに入れられたピークが通常 1 を超える場合は、クラスターを追加します。 すべての SQL ウェアハウス タイプのキュー内のクエリの最大数は 1000 です。 「SQL ウェアハウスの監視」を参照してください。
クエリ履歴。 「 クエリ履歴」を参照してください。
クエリ プロファイル (1 より上の ディスクにあふれたバイト数 を探します)。 「 クエリ プロファイル」を参照してください。
注：
サーバレス SQLウェアハウスの場合、クラスターサイズは、同等のクラスターサイズに対して、pro および classic SQLウェアハウスのドキュメントに記載されているものとは異なるインスタンスタイプを使用する場合があります。 一般に、サーバレス SQLウェアハウスのクラスターサイズの価格性能比は、pro SQLウェアハウスと従来のSQLウェアハウスの価格/性能比と似ています。
サーバレスのオートスケールとクエリーキューイング
Intelligent Workload Management (IWM) は、サーバレス SQLウェアハウスが大量のクエリを迅速かつコスト効率よく処理する機能を強化する一連の機能です。 機械学習モデルを使用してワークロードを動的に管理し、受信クエリのリソース需要を予測しながら、ウェアハウスの使用可能なコンピュート容量をリアルタイムに監視します。 ウェアハウスでこれらの信号やその他の信号を追跡することで、IWMはワークロードの要求の変化に対応できます。
この動的管理により、IWM は次のことを行うことができます。
コンピュートを迅速にアップスケールして、低遅延を維持します。
クエリのアドミタンスを、ハードウェアの制限に近いレートで提供します。
需要が少ないときにコストを最小限に抑えるために、迅速にダウンスケールします。
クエリがウェアハウスに到着すると、IWM はそのコストを予測します。 同時に、IWM はウェアハウスの利用可能なコンピュート容量をリアルタイム モニタリングします。 次に、機械学習モデルを使用して、IWM は、受信クエリの既存のコンピュートに必要なコンピュートがあるかどうかを予測します。 必要なコンピュートがない場合、クエリはキューに追加されます。 必要なコンピュートがある場合、クエリはすぐに実行を開始します。
IWM は、約 10 秒ごとにキューをモニタします。 行列が十分に速く減少しない場合、オートスケールが作動して、より多くのコンピュートを迅速に調達します。 新しい容量が追加されると、キューに入れられたクエリは新しいコンピュート リソースに許可されます。 サーバレス SQLウェアハウスを使えば、新しいコンピュートをどんどん追加できます。 すべての SQLウェアハウス タイプのキュー内のクエリの最大数は 1000 です。
プロおよびクラシックSQLウェアハウスのクラスターサイズ
このセクションの表では、SQLウェアハウス クラスターのサイズを Databricks クラスター ドライバーのサイズとワーカー数にマップします。 ドライバーのサイズは、pro と classic 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 つのクラスターを保持します。