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

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

サイジングの概要

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

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

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

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

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

注記

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

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

すべてのワーカーのインスタンス サイズは 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 は、予想されるクエリ負荷が 15 分増えるごとに 3 つのクラスターと 1 つのクラスターを追加します。

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

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

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

インテリジェント・ワークロード管理 (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 より大きい ディスクにこぼれたバイト 数を探します)。 「クエリ プロファイル」を参照してください。