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比と似ています。

クラスターサイズ

ドライバーのインスタンスの種類

ワーカー数

合計 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 のクォータ要件

関連するコンピュート エンジン (Engine API ) クォータ フィールドは次のとおりです。

  • N2 CPU (英語)

  • 永続ディスク SSD (GB)

  • ローカル SSD (GB)

クォータ要件の詳細については、 コンピュート Engine APIを参照してください。

警告

必要な CPU とストレージ リソースをプロビジョニングしないと、SQLウェアハウスは起動しません。「コンピュート エンジン API」を参照してください。必要に応じて、リソース クォータを増やして、 SQLウェアハウスの使用をサポートできます。 「クォータの確認と増加」を参照してください。ワークスペースのコストに関する情報については、「 ワークスペースあたりのコスト」を参照してください。

プロおよびクラシック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 より上の ディスクにあふれたバイト数 を探します)。 「 クエリ プロファイル」を参照してください。