目次 › 第6章 › 6-3

第6章 トラブルシューティング・監視・最適化 / 想定学習時間:30〜40分 / 最終確認:2026年8月

6-3. Liquid ClusteringとPredictive Optimization

1. なぜデータレイアウトが性能を左右するのか

6-2 では実行中のクエリのボトルネックを診断しました。しかし、クエリが遅い原因はしばしばデータの置き方(レイアウト)にあります。テーブルをスキャンするとき、Delta Lake はファイルごとの統計情報(各列の最小値・最大値)を使って「読む必要のないファイル」を丸ごと飛ばします(データスキッピング)。フィルタ条件に使う列の値が近い行同士を同じファイルにまとめて配置できていれば、このスキップが強力に効きます。逆に値が散らばっていると、ほぼ全ファイルを読む羽目になります。

この「よく使う列で行を物理的に寄せて配置する」ための手法が、従来は静的パーティショニング(PARTITIONED BY)と ZORDER でした。そして現在 Databricks が推奨するのが Liquid Clustering です。

2. 従来手法の限界:静的パーティションとZORDER

つまり従来は、「パーティション列を何にするか」をテーブル設計の最初に当てなければならず、外すと後から直すのが大変でした。クエリパターンは運用の中で変わっていくのに、レイアウトが固定的だったのです。

3. Liquid Clustering:柔軟でスキューに強いレイアウト

Liquid Clustering は、静的パーティショニングと ZORDER の両方を置き換える、Delta テーブルのデータレイアウト方式です。テーブル作成時に CLUSTER BY でクラスタリングキーを指定します。

-- 作成時にクラスタリングキーを指定
CREATE TABLE sales (
  order_id BIGINT,
  customer_id BIGINT,
  order_date DATE,
  amount DOUBLE
)
CLUSTER BY (order_date, customer_id);

-- クエリパターンが変わったら、キーは後から変更できる
ALTER TABLE sales CLUSTER BY (customer_id);

-- キーの指定自体を Databricks に任せる(自動クラスタリング)
CREATE TABLE events (...) CLUSTER BY AUTO;

Liquid Clustering の特長を整理します。

• キー変更が容易 — ALTER TABLE ... CLUSTER BY だけで変更でき、テーブルの書き直しは不要です。クエリパターンの変化に追従できます。
• 高カーディナリティ列も使える — 物理ディレクトリを切らないため、ID のような値の種類が多い列をキーにしてもファイル爆発が起きません。
• スキュー耐性 — 静的パーティションでは値の偏り(例:特定日付にデータが集中)がそのまま巨大パーティションになりますが、Liquid Clustering はファイルサイズをそろえるようにデータを配置するため、偏ったデータでも安定します。
• 増分クラスタリング — 新しく書き込まれたデータだけを対象に最適化を進められ、ZORDER のような全面書き直しを避けられます。
• CLUSTER BY AUTO(自動クラスタリング) — キー選定そのものを Databricks に委ねる指定です。実際のクエリワークロードを分析して最適なクラスタリングキーを自動選択・自動調整します(Predictive Optimization が有効な Unity Catalog 管理テーブルで利用)。「どの列で絞り込まれるか事前に読めない」テーブルに適します。

4. Predictive Optimization:テーブルメンテナンスの自動化

レイアウトを決めても、テーブルには継続的なメンテナンスが必要です。従来は次の作業をエンジニアが手動またはジョブのスケジュールで運用してきました。

• OPTIMIZE — 小ファイルを適正サイズに統合(コンパクション)し、クラスタリングを進める
• VACUUM — 不要になった古いデータファイルを削除し、ストレージコストを削減する

Predictive Optimization は、これらのメンテナンス操作を Databricks が自動で判断・実行する機能です。対象は Unity Catalog の管理テーブル(managed table)で、各テーブルの利用パターンとデータの状態を分析し、「最適化する価値があるテーブルに、価値があるタイミングで」OPTIMIZE や VACUUM をサーバーレスコンピュート上で実行します。

5. 手法の総合比較と選択指針

新規に作る Delta テーブルでは、特別な理由がない限り Liquid Clustering を第一候補とし、Unity Catalog 管理テーブルであれば Predictive Optimization を有効にして OPTIMIZE / VACUUM の運用を手放す、というのが現在の推奨構成です。既存の試験問題や現場のテーブルには静的パーティションや ZORDER も残っているため、それぞれの弱点(=Liquid Clustering が解決した点)を対比で覚えるのが効率的です。

練習問題