Databricks SQL Warehouseチューニング: 同時実行・キャッシュ・サイズ選定

SQL Warehouseは「サイズを上げれば速くなる」と思われがちですが、実際にはサイズ・クラスタ数・キャッシュ設定の 3つのレバーを理解しないとコストが膨らむだけで性能が出ません。 この記事では、サイズ選定の考え方から同時実行制御、キャッシュ層の動作、チューニング手順までを体系的に整理します。

SQL Warehouseサイズ選定表

SQL Warehouseのサイズはクラスタのコンピュートリソース量を決定します。 サイズが大きいほど1クエリあたりの処理能力が上がりますが、DBUコストも比例して増加します。

クラスタ数を増やすとスケールアウトで同時実行数を伸ばせますが、各クラスタが個別のDisk Cacheを持つため、 キャッシュヒット率が下がる可能性があります。サイズアップ（スケールアップ）は1クエリの処理能力を上げ、 クラスタ数増加（スケールアウト）は並列クエリ数を上げる、と使い分けます。

同時実行とQuery Queuing対策

SQL Warehouseはリソースが不足するとクエリをキュー（待機列）に入れます。 ダッシュボードのロード時に多数のクエリが同時発行されるとQueuing Timeが支配的になり、 ユーザー体験が大幅に悪化します。

Queuing が発生する典型パターン

• ダッシュボードの自動リフレッシュで数十〜数百クエリが同時発行される
• BIツール（Tableau / Power BI）が並列でクエリを投げる
• ETL完了直後に複数ユーザーがアドホッククエリを実行する

対策の優先順位

1. スケーリングポリシーを「Optimized」にして需要に応じたクラスタ自動増減を有効にする
2. ウォームアップ時間を考慮し、Min Clustersを1以上に設定してコールドスタートを回避する
3. Max Clustersを適切に設定して上限コストを制御する
4. ダッシュボードのリフレッシュ間隔を適切に設定し、不要な同時実行を減らす
5. ワークロードの特性に応じてWarehouseを分割する（重いアドホック用 / 軽いダッシュボード用）

Result Cache（結果キャッシュ）

Result Cacheは、まったく同じSQLテキストが再実行されたときに、前回の結果セットをそのまま返す仕組みです。 クエリのコンパイルやデータスキャンを完全にスキップするため、最も高速なキャッシュ層です。

キャッシュ有効条件

• SQLテキストが完全一致する（ホワイトスペースの違いも不一致扱い）
• 基になるテーブルのデータが変更されていない（Delta Logで検知）
• CURRENT_TIMESTAMP()やrand()などの非決定性関数を含まない
• キャッシュの有効期限（デフォルト24時間）以内である

ダッシュボードのように同じクエリが繰り返し実行されるワークロードでは、Result Cacheが非常に効果的です。 逆に、WHERE句のパラメータが毎回異なるアドホッククエリではヒットしません。

Disk Cache（SSDキャッシュ）

Disk Cacheは、リモートストレージ（S3/ADLS/GCS）から読み込んだデータをWarehouseノードのローカルSSDに キャッシュする仕組みです。2回目以降のクエリでは、ネットワーク越しのI/Oを回避してローカルSSDから データを読み取るため、スキャン速度が大幅に向上します。

• キャッシュ単位はDeltaテーブルのParquetファイル単位
• テーブルに対してOPTIMIZEやVACUUMを実行するとファイルが変わるためキャッシュが無効化される
• Warehouseが停止・再起動するとDisk Cacheは失われる
• Auto Stopの時間を長めに設定するとキャッシュの恩恵を受けやすいが、アイドルコストとのトレードオフ

Predictive I/O

Predictive I/Oは、Databricksが過去のクエリパターンを学習し、次に必要になりそうなデータを先読みする仕組みです。 テーブル統計情報とクエリ履歴を活用して、フィルタ条件に合致するファイルを事前にフェッチします。

• Pro / Serverless Warehouseで自動的に有効
• 特に大規模テーブルに対する範囲フィルタ（日付範囲など）で効果が顕著
• Disk Cacheと組み合わさると、初回クエリでもキャッシュ済みに近い速度が出る場合がある

IWM（Intelligent Workload Management）

IWMはPro / Serverless Warehouseで使える機能で、Warehouse内のリソースをクエリ単位で動的に配分します。 従来のClassic Warehouseでは固定スロットにクエリを割り当てていましたが、IWMでは小さなクエリに少ないリソースを、 大きなクエリに多くのリソースを自動配分します。

チューニング手順 5ステップ

以下は実務でSQL Warehouseのパフォーマンスを改善するための推奨手順です。

ステップ1: ワークロードの分類

まずクエリを「ダッシュボード用（繰り返し同じクエリ）」「アドホック（毎回異なるクエリ）」 「ETL検証（重い結合・集計）」に分類します。特性が大きく異なるワークロードは別のWarehouseに分離します。

ステップ2: 適正サイズの初期選定

Query Profileでスキャンデータ量と実行時間を確認し、上記のサイズ選定表を目安に初期サイズを決定します。 迷ったら小さめから始めて段階的にサイズアップするのが安全です。

ステップ3: スケーリング設定

Scaling PolicyをOptimizedに設定し、Min Clustersを1（コールドスタート回避）、 Max Clustersをピーク時の同時実行数に基づいて設定します。

ステップ4: キャッシュ効率の最大化

Auto Stop時間を10分程度に設定してDisk Cacheの保持時間を確保しつつ、アイドルコストとのバランスを取ります。 ダッシュボード用WarehouseではResult Cacheのヒット率を監視し、非決定性関数の排除やクエリテキストの統一を検討します。

ステップ5: 監視と継続改善

Query HistoryでQueuing Time、Execution Time、Rows Scannedを定期的に確認します。 Queuing Timeが全体の10%を超える場合はクラスタ数の追加、Execution Timeが長い場合はサイズアップ、 Rows Scannedが過大な場合はクエリ最適化（パーティショニング、Z-ORDER、フィルタ追加）を検討します。

試験で問われるポイント

• 「Result CacheとDisk Cacheの違いは何か」→ Result Cacheは結果セットの再利用、Disk CacheはデータファイルのSSDキャッシュ
• 「Queuing Timeが長い場合の対処法」→ クラスタ数の追加（スケールアウト）が最優先
• 「テーブルにOPTIMIZEを実行した後、クエリが遅くなった原因」→ Disk Cacheが無効化されたため
• 「Warehouseのサイズを上げるべきか、クラスタ数を増やすべきか」→ 1クエリが遅い場合はサイズアップ、同時実行で待ちが出る場合はクラスタ追加

問題で確認

よくある質問