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ウェアハウスの価格/性能比と似ています。
サーバレスのオートスケールとクエリーキューイング
Intelligent Workload Management (IWM) は、サーバレス SQLウェアハウスが大量のクエリを迅速かつコスト効率よく処理する機能を強化する一連の機能です。 機械学習モデルを使用してワークロードを動的に管理し、受信クエリのリソース需要を予測しながら、ウェアハウスの使用可能なコンピュート容量をリアルタイムに監視します。 ウェアハウスでこれらの信号やその他の信号を追跡することで、IWMはワークロードの要求の変化に対応できます。
この動的管理により、IWM は次のことを行うことができます。
コンピュートを迅速にアップスケールして、低遅延を維持します。
クエリのアドミタンスを、ハードウェアの制限に近いレートで提供します。
需要が少ないときにコストを最小限に抑えるために、迅速にダウンスケールします。
クエリがウェアハウスに到着すると、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 |
1.5 |
X-Small |
N2 - HighMem - 8 |
2のx N2-Highmem-8 |
24 |
.3 |
2.25 |
S |
N2 - HighMEM - 16 |
4個のx N2-Highmem-8 |
48 |
.5 |
4.5 |
M |
N2 - HighMem - 32 |
8 x N2-Highmem-8 |
96 |
.9 |
9 |
Large |
N2 - HighMem - 32 |
16個のx N2-Highmem-8 |
160 |
1.7 |
18 |
X-Large |
N2-ハイメム-64 |
32のx N2-Highmem-8 |
320 |
3.3 |
30 |
XXL |
N2-ハイメム-64 |
64のx N2-Highmem-8 |
576 |
6.5 |
54 |
XXXL |
N2-ハイメム-64 |
128のx N2 - HIGHMEM - 8 |
1088 |
12.9 |
102 |
4X-Large |
N2-ハイメム-64 |
256のx N2 - HIGHMEM - 8 |
2112 |
25.7 |
198 |
すべてのワーカーのインスタンスサイズは 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 つのクラスターを保持します。