メインコンテンツまでスキップ

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

クラスターサイズ

ドライバーのインスタンスタイプ

ワーカー数

合計 vCPU

永続ディスク SSD の合計 (TB)

ローカル SSD の合計 (TB)

XXS

N2-ハイmem-8

1 x N2-HighMem-8

16 時間

.2

1.5

X-Small

N2-ハイmem-8

2 x N2-HighMem-8

24

.3

2.25

S

N2-ハイMEM-16

4 x N2-HighMem-8

48

.5

4.5

M

N2-ハイMEM-32

8 x N2-HighMem-8

96

.9

9

Large

N2-ハイMEM-32

16 x N2-HighMem-8

160

1.7

18

X-Large

N2-ハイMEM-64

32 x N2-HighMem-8

320

3.3

30

XXL

N2-ハイMEM-64

64 x N2-HighMem-8

576

6.5

54

XXXL

N2-ハイMEM-64

128 x N2-HighMem-8

1088

12.9

102

4X-Large

N2-ハイMEM-64

256 x N2-HighMem-8

2112

25.7

198

すべてのワーカーのインスタンスサイズは n2-highmem-8 です。

注記

この表の情報は、製品または地域の可用性とワークスペースの種類によって異なる場合があります。

コンピュート Engine API quota requirements​

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

  • N2 CPU
  • 永続ディスク SSD (GB)
  • ローカル SSD (GB)

クォータ要件の詳細については、「コンピュート エンジン 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 は、予想されるクエリ負荷が 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 より大きい ディスクにこぼれたバイト 数を探します)。 「クエリ プロファイル」を参照してください。
に最終更新