Databricks SQLのキャッシュ: 結果キャッシュ/データキャッシュ/マテビュー

Databricks SQLで「同じクエリなのに速いときと遅いときがある」と感じたことはないでしょうか。 その違いの多くはキャッシュの動作に起因します。Databricks SQLには3つの異なるキャッシュ層があり、 それぞれ動作レイヤー、保持条件、無効化タイミングが異なります。 この記事では、3つのキャッシュ層を正確に理解し、コスト効率の良いクエリ実行を実現する方法を整理します。

3種キャッシュ比較表

Result Cache の詳細

Result Cacheは、完全に同一のSQLテキストが同一のWarehouseで再実行されたときに、 前回の結果をそのまま返す仕組みです。クエリのコンパイル・最適化・データスキャンをすべてスキップするため、 ヒットした場合のレスポンスは数十ミリ秒レベルです。

ヒット条件

• SQLテキストが完全一致（ホワイトスペース、大文字小文字の違いも区別される）
• 基テーブルのデータが変更されていない（Delta Logのバージョンで検知）
• 非決定性関数（CURRENT_TIMESTAMP、rand、uuid等）を含まない
• 前回のキャッシュから24時間以内
• 同一Warehouseでの実行

ヒットしないケース

• WHERE句のパラメータが毎回異なるアドホッククエリ
• 基テーブルにINSERT/UPDATE/MERGE/DELETEが行われた後
• 異なるWarehouseから同じクエリを実行した場合
• CURRENT_DATE()を含むクエリ（日付が変わるとキャッシュが無効化される）

Disk Cache の詳細

Disk Cacheは、リモートストレージ（S3 / ADLS / GCS）からフェッチしたParquetファイルを WarehouseノードのローカルSSDにキャッシュする仕組みです。 Result Cacheがクエリ結果レベルのキャッシュであるのに対し、Disk Cacheはデータファイルレベルの キャッシュです。

動作の仕組み

1. クエリが実行されると、必要なParquetファイルがリモートストレージからフェッチされる
2. フェッチされたファイルがローカルSSDにキャッシュされる
3. 同じファイルを必要とする次のクエリでは、リモートI/Oを省略してSSDから直接読み取る
4. SSD容量が上限に達するとLRUでエビクトされる

無効化されるタイミング

• テーブルに対してOPTIMIZE（ファイルのコンパクション）が実行された
• VACUUMが実行されて古いファイルが削除された
• INSERT/MERGE等でDeltaログに新しいバージョンが追加された
• Warehouseが停止・再起動された

Materialized View の詳細

Materialized Viewは事前にクエリ結果を計算してDeltaテーブルとして保存する仕組みです。 Result CacheやDisk CacheがWarehouseのライフサイクルに依存するのに対し、 Materialized Viewはクラウドストレージに永続化されるため、Warehouseの停止・再起動に影響されません。

-- Materialized Viewの作成
CREATE MATERIALIZED VIEW sales_summary AS
SELECT
  region,
  product_category,
  DATE_TRUNC('month', order_date) AS month,
  COUNT(*) AS order_count,
  SUM(amount) AS total_amount
FROM catalog.schema.orders
GROUP BY region, product_category, DATE_TRUNC('month', order_date);

-- 手動リフレッシュ
REFRESH MATERIALIZED VIEW sales_summary;

-- 自動リフレッシュのスケジュール設定
ALTER MATERIALIZED VIEW sales_summary
SET TBLPROPERTIES (
  'pipelines.autoOptimize.managed' = 'true'
);

Result CacheとMaterialized Viewの使い分け

• 同じクエリが頻繁に繰り返される → Result Cacheで十分（設定不要）
• クエリパターンは異なるが同じ集計結果が必要 → Materialized View
• 基テーブルが頻繁に更新され、最新結果が必要 → Result Cache（データ変更で自動無効化）
• 基テーブルの更新頻度が低く、重い集計を事前計算したい → Materialized View

キャッシュウォームアップ戦略

Warehouseを停止・再起動するとDisk CacheとResult Cacheの両方が失われます。 朝のダッシュボードアクセスが集中する時間帯に「初回だけ遅い」問題を回避するための戦略です。

コスト最適化のポイント

• Auto Stopの延長はキャッシュに有利だが、アイドルDBUが発生する → ワークロードパターンに応じて最適値を決定
• 複数の小型Warehouseに分散するとキャッシュが分断される → 可能な限り同一Warehouseに統合
• OPTIMIZEのスケジュールはダッシュボードの利用時間帯を避ける → 深夜にOPTIMIZE実行後、朝にウォームアップクエリ
• Materialized Viewのリフレッシュコストとクエリ高速化の効果を比較 → リフレッシュ頻度は基テーブルの更新頻度に合わせる

試験で問われるポイント

• 「テーブルにINSERTした後、同じSELECTが遅くなった理由」→ Result Cacheが無効化されたため
• 「Warehouse再起動後にクエリが遅い理由」→ Disk CacheとResult Cacheの両方が消失したため
• 「OPTIMIZEを実行した後、一時的にクエリが遅くなる原因」→ Disk Cacheが無効化される（ファイルが再構成されるため）
• 「Warehouseの停止に関係なく高速な集計結果を提供する方法」→ Materialized View
• 「Result CacheとDisk Cacheの違い」→ Result Cacheは結果セットの再利用、Disk CacheはデータファイルのSSD保持

問題で確認

よくある質問