Liquid Clustering完全解説｜Delta Lakeの次世代クラスタリング

Delta Lakeのテーブルが大規模になると、クエリがスキャンするデータ量の制御が パフォーマンスの決定要因になります。従来はパーティショニングやZ-ORDERでデータレイアウトを最適化していましたが、 パーティションキーの変更にはテーブルの再作成が必要で、 Z-ORDERは毎回テーブル全体を再ソートするコストがありました。

Liquid ClusteringはDBR 13.3 LTS（2023年後半GA）で導入された Delta Lakeの次世代データレイアウト最適化機能です。 パーティション不要・クラスタリングキーの動的変更・増分再クラスタリングの3つの特長により、 従来手法の制約を根本的に解消します。

Liquid Clusteringの3つの特長

Liquid Clusteringが従来手法と根本的に異なるのは、以下の3点です。

• パーティション不要: PARTITIONED BYで物理ディレクトリを分割する必要がありません。 パーティションカラムのカーディナリティ（値の種類数）を気にする必要がなく、 高カーディナリティカラム（user_id、timestampなど）でもデータスキッピングが効きます
• キー変更が即座に可能: ALTER TABLE一文でクラスタリングキーを変更できます。 テーブルの再作成やデータの全コピーは不要で、メタデータの更新だけで完了します。 次回のOPTIMIZE時に新しいキーで増分的に再クラスタリングされます
• 増分最適化: OPTIMIZEはまだクラスタリングされていないデータ（新規INSERTされたファイル）だけを 対象に処理します。毎回テーブル全体を再ソートするZ-ORDERと異なり、 処理量が新規データ量に比例するため、大規模テーブルでも短時間で完了します

CLUSTER BY構文

Liquid Clusteringの設定は CLUSTER BY 句で行います。 テーブル作成時に指定する方法と、既存テーブルに後から設定する方法があります。

テーブル作成時に指定

-- 新規テーブルをLiquid Clusteringで作成
CREATE TABLE catalog.schema.sales (
  sale_id     BIGINT,
  customer_id BIGINT,
  region      STRING,
  sale_date   DATE,
  amount      DECIMAL(18,2)
)
CLUSTER BY (region, sale_date);

-- CTASでLiquid Clusteringテーブルを作成
CREATE TABLE catalog.schema.sales_optimized
CLUSTER BY (customer_id, sale_date)
AS SELECT * FROM catalog.schema.raw_sales;

クラスタリングキーの変更

-- クラスタリングキーを変更（メタデータ更新のみ、即時完了）
ALTER TABLE catalog.schema.sales
CLUSTER BY (customer_id, region);

-- クラスタリングを無効化
ALTER TABLE catalog.schema.sales
CLUSTER BY NONE;

CLUSTER BY NONE でクラスタリングを無効化できます。 無効化しても既存データのレイアウトは維持されますが、 以降のOPTIMIZEではクラスタリングが行われなくなります。

Z-ORDER / パーティショニング / Liquid Clustering 比較

3つのデータレイアウト最適化手法の特性を比較します。 Liquid Clusteringは両方の利点を取り込みつつ、欠点を解消した手法です。

Databricksは新規テーブルではLiquid Clusteringの使用を公式に推奨しており、パーティショニングやZ-ORDERは既存テーブルの互換性維持のために残されています。

内部動作：Hilbert Curveと増分再クラスタリング

Liquid Clusteringの内部では、Hilbert Curve（ヒルベルト曲線） というSpace-Filling Curve（空間充填曲線）を使って多次元データを1次元に射影しています。 Z-ORDERが使用するZ-curve（Morton曲線）と比較して、 Hilbert Curveは空間的に隣接するデータポイントが1次元上でもより近くに配置される特性があり、 データスキッピングの精度が向上します。

┌──────────────────────────────────────────────────────┐
│  Z-Curve (Morton曲線)           Hilbert Curve         │
│                                                       │
│  0 ─ 1   4 ─ 5                0 ─ 1   14─ 15        │
│  │   │   │   │                │   │    │   │         │
│  3 ─ 2   7 ─ 6                3 ─ 2   13─ 12        │
│                                    │        │         │
│  12─ 13  8 ─ 9                4 ─ 5   10─ 11        │
│  │   │   │   │                │   │    │   │         │
│  15─ 14  11─ 10               7 ─ 6    9 ─ 8        │
│                                                       │
│  → 空間的に近いデータが       → 空間的に近いデータが  │
│    1次元で離れるケースあり       常に1次元でも近接     │
└──────────────────────────────────────────────────────┘

Hilbert Curveの利点:
  - 空間的局所性がZ-Curveより高い
  - WHERE region = 'APAC' AND sale_date = '2026-03-01'
    のような多次元フィルタでスキッピング精度が向上
  - 統計情報（min/max）の範囲が狭くなり、
    不要ファイルの除外率が高まる

増分再クラスタリングの仕組み

Liquid Clusteringは各データファイルに「クラスタリング済み」か 「未クラスタリング」かのメタデータを付与します。 OPTIMIZEを実行すると、未クラスタリングのファイル（新規INSERT・UPDATE・MERGEで追加されたファイル） だけがクラスタリング処理の対象となります。

-- 増分再クラスタリングの流れ

-- Step 1: テーブル作成
CREATE TABLE events CLUSTER BY (user_id, event_date) ...;

-- Step 2: データ追加（未クラスタリング状態でファイルが追加）
INSERT INTO events SELECT * FROM raw_events;
-- → 新規ファイルは is_clustered = false

-- Step 3: OPTIMIZE実行
OPTIMIZE events;
-- → is_clustered = false のファイルだけを読み込み
-- → Hilbert Curveで再配置し、新しいファイルとして書き出し
-- → 新ファイルは is_clustered = true
-- → 古いファイルはトランザクションログで無効化

-- Step 4: 追加データのみ再クラスタリング
INSERT INTO events SELECT * FROM new_events;
OPTIMIZE events;
-- → Step 4のINSERTで追加されたファイルだけが対象
-- → Step 3でクラスタリング済みのファイルは処理しない

OPTIMIZEとの関係

Liquid Clusteringが設定されたテーブルでは、OPTIMIZEコマンドの動作が通常のDelta Tableと異なります。

-- Liquid Clusteringテーブルでの正しいOPTIMIZE
OPTIMIZE catalog.schema.sales;
-- → 未クラスタリングデータだけを増分処理

-- エラーになる例
OPTIMIZE catalog.schema.sales ZORDER BY (region);
-- → Error: CLUSTER BYが設定されたテーブルにZORDER BYは使用できません

自動OPTIMIZEとの関係

DatabricksのPredictive Optimization（予測的最適化）が有効な場合、 Unity Catalogのマネージドテーブルに対してOPTIMIZEが自動的にスケジュールされます。 Liquid Clusteringテーブルでは、この自動OPTIMIZEで増分再クラスタリングも同時に実行されます。 手動でOPTIMIZEを実行する必要がなくなるため、運用負荷が大幅に軽減されます。

-- Predictive Optimizationの有効化（Unity Catalogスキーマ単位）
ALTER SCHEMA catalog.schema
SET DBPROPERTIES ('delta.enablePredictiveOptimization' = 'true');

-- テーブル単位での設定
ALTER TABLE catalog.schema.sales
SET TBLPROPERTIES ('delta.enablePredictiveOptimization' = 'true');

-- 有効な場合のLiquid Clusteringテーブルの運用:
-- 1. OPTIMIZE が自動スケジュールされる
-- 2. 増分再クラスタリングが自動実行される
-- 3. VACUUMも自動スケジュールされる
-- → 手動でのメンテナンスコマンド実行が不要に

既存テーブルからの移行パターン

パーティションテーブルやZ-ORDERテーブルからLiquid Clusteringへの移行手順は、テーブルの種類によって異なります。

パターン1: パーティションなしテーブル（Z-ORDER使用）からの移行

-- Step 1: Liquid Clusteringを有効化
ALTER TABLE catalog.schema.events
CLUSTER BY (user_id, event_date);

-- Step 2: 増分再クラスタリング実行
OPTIMIZE catalog.schema.events;

-- これ以降、OPTIMIZE ZORDER BY は不要（使用するとエラー）
-- 以降のOPTIMIZEで自動的にHilbert Curveベースのクラスタリングが実行

パターン2: パーティションテーブルからの移行

パーティションテーブルにはLiquid Clusteringを直接設定できません。CTAS（CREATE TABLE AS SELECT）またはDEEP CLONEで新テーブルを作成する必要があります。

-- 方法A: CTAS で新テーブル作成
CREATE TABLE catalog.schema.events_v2
CLUSTER BY (region, event_date)
AS SELECT * FROM catalog.schema.events_partitioned;

-- 方法B: DEEP CLONE + ALTER TABLE
CREATE TABLE catalog.schema.events_v2
DEEP CLONE catalog.schema.events_partitioned;

ALTER TABLE catalog.schema.events_v2
CLUSTER BY (region, event_date);

OPTIMIZE catalog.schema.events_v2;

-- 移行後の検証
SELECT COUNT(*) FROM catalog.schema.events_v2;
DESCRIBE DETAIL catalog.schema.events_v2;
-- clusteringColumns に [region, event_date] が表示されることを確認

パターン3: クラスタリングキーの変更

-- 分析パターンの変化に応じてキーを変更
-- Before: region と sale_date でフィルタが多かった
-- After:  customer_id と product_category でフィルタが増えた

ALTER TABLE catalog.schema.sales
CLUSTER BY (customer_id, product_category);

-- 次回のOPTIMIZEで新キーによる増分再クラスタリングが開始
OPTIMIZE catalog.schema.sales;

制約と要件

• DBR 13.3 LTS以降が必要です。それより古いランタイムではCLUSTER BY構文が認識されません
• Photon推奨:クラスタリング処理はPhoton Engine上で最適化されています。Photonなしでも動作しますが、OPTIMIZE処理の速度が低下します
• パーティションとの併用不可:PARTITIONED BYとCLUSTER BYは同一テーブルに設定できません。パーティションテーブルへの移行にはCTASまたはDEEP CLONEが必要です
• Z-ORDERとの併用不可:CLUSTER BYが設定されたテーブルにOPTIMIZE ... ZORDER BYを実行するとエラーになります
• クラスタリングキーのカラム数:最大4カラムまで指定可能です。カラム数が増えるとクラスタリングの効果が分散するため、フィルタ頻度の高い2〜3カラムが推奨です
• 対応カラム型:数値型・日付型・タイムスタンプ型・文字列型が対応しています。構造体型（STRUCT）やマップ型（MAP）はクラスタリングキーに指定できません
• Delta Lake専用:Parquet・CSV・JSONテーブルには使用できません。Delta形式（マネージドテーブルまたは外部Delta Table）が必要です

試験での出題ポイント

Liquid ClusteringはData Engineer Associate（DEA）とSpark Developer試験で出題される重要トピックです。特にZ-ORDERとの違いが頻出で、「どちらを選ぶべきか」の判断が問われます。

• Z-ORDERとの決定的な違い:Z-ORDERは毎回全データを再ソートする。Liquid Clusteringは未クラスタリングデータだけを増分処理する。この違いから「大規模テーブルで定期的にOPTIMIZEを実行する場合、どちらが効率的か？」の問いにはLiquid Clusteringが正解
• パーティションとの共存制約:PARTITIONED BYとCLUSTER BYは同一テーブルに設定できない。パーティションテーブルからの移行にはCTASが必要。この制約を問う問題が出題される
• ALTER TABLEでのキー変更:ALTER TABLE t CLUSTER BY (new_col) でキーを変更できる。テーブルの再作成は不要。「クエリパターンが変化したときに最も低コストで対応する方法」として問われる
• CLUSTER BY NONE:クラスタリングの無効化構文。既存データのレイアウトは維持されるが、以降のOPTIMIZEでクラスタリングは行われなくなる
• Predictive Optimization:Unity Catalogのマネージドテーブルでは自動OPTIMIZEが可能。Liquid Clusteringと組み合わせることで完全自動のデータレイアウト最適化が実現する
• Hilbert Curveの優位性:Z-ORDERのZ-curve（Morton曲線）と比較して空間的局所性が高く、多次元フィルタのスキッピング精度が向上する。「なぜLiquid ClusteringはZ-ORDERより効率的か」の根拠として理解しておく

サンプル問題

よくある質問