Google
Cloud Platform
Amazon Web Services
Microsoft AzureSQLウェアハウスのサイジング、スケーリング、およびキューイングの動作
この記事では、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ウェアハウスの価格/性能比と似ています。
サーバレスのオートスケールとクエリーキューイング
インテリジェント・ワークロード・マネジメント (IWM) は、サーバレス SQLウェアハウスが多数のクエリーを迅速かつコスト効率よく処理する能力を強化する一連の機能です。 IWMは、AIを活用した予測機能を使用して受信クエリーを分析し、より高速で効率的なもの(予測IO)を決定することで、ワークロードに適切な量のリソースを迅速に確保します。 主な違いは、静的なしきい値を使用するのではなく、ワークロードの要求に動的に応答する Databricks SQL の AI 機能にあります。
この応答性により、次のことが保証されます。
低レイテンシーを維持するために、必要に応じてより多くのコンピュートを取得するための迅速なアップスケーリング。
クエリー admittance がハードウェアの限界に近づく。
迅速なダウンスケーリングにより、需要が低いときにコストを最小限に抑え、最適化されたコストとリソースで一貫したパフォーマンスを提供します。
クエリーが倉庫に到着すると、IWM はクエリーのコストを予測します。 同時に、IWMは倉庫の利用可能なコンピュート容量をリアルタイムでモニタリングします。 次に、IWMは機械学習モデルを使用して、受信クエリーが既存のコンピュートで必要なコンピュートを使用できるかどうかを予測します。 必要なコンピュートがない場合、クエリーはキューに追加されます。 必要なコンピュートがある場合、クエリーはすぐに実行を開始します。
IWM は、キューを約 10 秒ごとにモニターします。 キューが十分に速く減少しない場合、オートスケールが作動して、より多くのコンピュートを迅速に調達します。 新しい容量が追加されると、キューに入れられたクエリーが新しいクラスターに許可されます。 サーバレス SQLウェアハウスを使用すると、新しいクラスターをすばやく追加でき、一度に複数のクラスターを作成できます。 すべての SQLウェアハウスタイプのキュー内のクエリーの最大数は 1000 です。
プロおよびクラシックSQLウェアハウスのクラスターサイズ
このセクションの表では、SQLウェアハウス クラスターのサイズを Databricks クラスター ドライバーのサイズとワーカー数にマップします。 ドライバーのサイズは、pro と classic SQLウェアハウスにのみ適用されます。
クラスターサイズ |
ドライバーのインスタンスの種類 |
ワーカー数 |
合計 vCPU |
永続ディスク SSD の合計 (TB) |
ローカル SSD の合計 (TB) |
|---|---|---|---|---|---|
XXS |
N2 - HighMem - 8 |
1×N2-HighMEM-8 |
16 時間 |
.2 |
3 |
X-Small |
N2 - HighMem - 8 |
2のx N2-Highmem-8 |
24 |
.3 |
4.5 |
S |
N2 - HighMEM - 16 |
4個のx N2-Highmem-8 |
48 |
.5 |
7.5 |
M |
N2 - HighMem - 32 |
8 x N2-Highmem-8 |
96 |
.9 |
15 |
Large |
N2 - HighMem - 32 |
16個のx N2-Highmem-8 |
160 |
1.7 |
27 |
X-Large |
N2-ハイメム-64 |
32のx N2-Highmem-8 |
320 |
3.3 |
54 |
XXL |
N2-ハイメム-64 |
64のx N2-Highmem-8 |
576 |
6.5 |
102 |
XXXL |
N2-ハイメム-64 |
128のx N2 - HIGHMEM - 8 |
1088 |
12.9 |
198 |
4X-Large |
N2-ハイメム-64 |
256のx N2 - HIGHMEM - 8 |
2112 |
25.7 |
390 |
すべてのワーカーのインスタンスサイズは n2-highmem-8 です。
注：
この表の情報は、製品またはリージョンの可用性とワークスペースの種類によって異なる場合があります。
コンピュート エンジン API のクォータ要件
関連するコンピュート エンジン API の関連するクォータ フィールドは次のとおりです。
N2 CPU (英語)
永続ディスク SSD (GB)
ローカル SSD (GB)
クォータ要件の詳細については、 コンピュート Engine APIを参照してください。
警告
必要な量の CPU とストレージ リソースがない場合、SQL ウェアハウスは起動しません。 コンピュートエンジンAPI参照してください。 必要に応じて、SQLwarehouse の使用をサポートするためにリソース クォータを増やすことができます。 「 クォータの確認と引き上げ」を参照してください。 ワークスペースのコストに関する情報については、 ワークスペースあたりのコストを参照してください。
プロおよびクラシック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 つのクラスターを保持します。
