データ基盤

リキッドクラスタリングとは？Z-orderとの違いと仕組み

2026/10/11 シリーズ「Databricks 入門」 第5回 / 全6回

🤖 AIが執筆しています

SELECT * FROM sales.silver.orders WHERE order_date = '2026-10-01';
SELECT * FROM sales.silver.orders WHERE customer_id = 'C-00017';

ファイル    order_date の範囲          customer_id の範囲
part-0001   2026-10-01 〜 2026-10-01   C-00003 〜 C-99871
part-0002   2026-10-01 〜 2026-10-01   C-00011 〜 C-99950
  …
part-8640   2026-10-30 〜 2026-10-30   C-00007 〜 C-99902

ALTER TABLE sales.silver.orders CLUSTER BY (order_date, customer_id);
OPTIMIZE sales.silver.orders FULL;

ファイル    order_date の範囲          customer_id の範囲
part-a01    2026-10-01 〜 2026-10-01   C-00001 〜 C-33400
part-a02    2026-10-01 〜 2026-10-01   C-33401 〜 C-66800
part-a03    2026-10-01 〜 2026-10-01   C-66801 〜 C-99999
part-a04    2026-10-02 〜 2026-10-02   C-00001 〜 C-33400
  …

読み飛ばし：ファイルごとの最小値と最大値

Databricks は、各ファイルの列ごとの最小値と最大値、NULL の数、行数といった統計をクエリの時点で使い、条件に合わないファイルを読み飛ばす。これをデータスキップと呼ぶ³。外部テーブルでは、既定で先頭の 32 列について統計を取る。Unity Catalog のマネージドテーブルでは、予測的最適化が、クエリの絞り込みでよく使われる列の統計を取るので、32 列の制限は無い³。

注文日のように、行が届く順と一致する列で絞り込むと、追記したままの表でも多くのファイルを読み飛ばせる。各ファイルが、届いた時間の近い行だけを持つからである。Databricks の文書は、パーティションを持たない Delta Lake の表は、取り込んだ時刻の順に自然にまとまり、日時の列でパーティションを分けた場合に近い性能が、何も調整せずに得られるとしている⁷。ただし、UPDATE や MERGE で多くの行を変えると、この順は崩れる。そのため文書は、その場合には取り込みの順と一致する列（イベントの時刻や作成日など）をリキッドクラスタリングキーにするよう勧めている⁷。

一方、届いた順と関係の無い列、たとえば顧客 ID で絞り込むと、統計はほとんど役に立たない。以下の三つの方法は、どれも、このような列についてファイルの範囲を狭める方法である。

小さなファイルと OPTIMIZE

並べ方の前に、ファイルの数の問題がある。1 回の追記で 1 個のファイルができるとすると、5 分ごとの追記で一か月に約 8,600 個のファイルができ、それぞれがログに統計の記録を持つ。クエリはそのすべてを確かめたうえで、条件に合う行を含みうるファイルを一つずつ開く。ファイルが小さく多いほど、確かめる記録も、開くファイルも増える。2020 年の論文は、小さなファイルの問題は HDFS でもよく起きるが、クラウドのストレージでは性能への影響がより大きいと書いている⁸。

OPTIMIZE は、データファイルを書き直して、表のファイルの配置を整える命令である⁹。リキッドクラスタリングを使わない表では、既定で、小さなファイルを大きさのそろったファイルにまとめ直す（ビンパッキング）。表のデータは変えないので、OPTIMIZE の前後で読み取りの結果は同じである⁹。ログには、まとめる前のファイルの remove と、まとめたあとのファイルの add が一件の版として書かれる¹⁰。同じデータに二度実行しても、二度目は何もしない¹¹。

まとめる前の小さなファイルは、過去の版を読むためにストレージに残る。消すには VACUUM を実行する¹²。そのため、OPTIMIZE の直後には、ストレージの使用量はむしろ増える。また、Databricks には、書き込みのあとに小さなファイルをまとめる自動圧縮と、書き込みの前にデータを組み替えて少数の大きなファイルを書く最適化された書き込みがあるが、文書はどちらも OPTIMIZE の完全な代わりにはならないと書く¹³。

パーティション：値ごとにディレクトリを分ける

パーティションは、指定した列の値ごとに、データファイルを別の場所に分けて書く方法である。注文日でパーティションを分けると、表の中身は次のようになる。

orders/
├── _delta_log/
├── order_date=2026-10-01/
│   ├── part-0001.parquet
│   └── …
├── order_date=2026-10-02/
│   └── …
└── …

ログの add の記録には、そのファイルの列の値が "partitionValues": {"order_date": "2026-10-01"} のように書かれる²。注文日で絞り込むクエリは、統計を見るまでもなく、ほかの日のファイルをすべて除ける。order_date=… という名前のディレクトリは、オープンソースの実装が既定で使う慣習で、Delta Lake のプロトコルの一部ではない²⁷。どのファイルがどの値に属するかは、ディレクトリの名前ではなく、ログの記録で決まる。

この方法は、値の種類が少ない列にしか向かない。Databricks の文書は、パーティションがうまく働くのは日付や所在地のように値の種類が少ないか決まっている列で、タイムスタンプのように値の種類が多い列には向かないとする⁷。顧客 ID でパーティションを分ければ、顧客の数だけディレクトリができ、その中には小さなファイルしか入らない。文書は、各パーティションに少なくとも 1 GB のデータを入れること、1 TB 未満の表はパーティションに分けないこと、1 TB から 100 TB の表ではリキッドクラスタリングを使うことを勧め、この範囲ではパーティションは性能を上げるより下げることの方が多いと書く⁷。

Z-order：複数の列で値の近い行を集める

注文日で絞るクエリと顧客 ID で絞るクエリの両方で読み飛ばしを増やすには、両方の列について各ファイルの範囲を狭くしたい。一つの列で並べ替えるだけでは、これはできない。注文日の順に並べれば顧客 ID の範囲が広く残り、顧客 ID の順に並べれば、今度は注文日の範囲が広くなる。

2020 年の論文は、送信元の IP、送信先の IP、時刻のように、複数の列で厳しく絞り込まれるデータを例に挙げる。Hive の方式でディレクトリを分けると、複数の列で分けたときにパーティションの数が多くなりすぎる⁸。そこで Delta Lake は、指定した列について、行を Z-order 曲線の順に並べ替える⁸。

Z-order 曲線は、論文によれば、指定したすべての列で近さを保つ、計算の簡単な空間充填曲線である⁸。二つの列の場合でいえば、注文日を横軸、顧客 ID を縦軸にとった平面を、小さなます目に分け、Z の字を重ねた順にたどる線にあたる。この順に並べた行を前から順にファイルへ詰めると、一つのファイルには、多くの場合、平面の小さな範囲が入り、注文日と顧客 ID の両方の範囲が狭くなる。ただし、曲線が大きく跳ぶところでは、一方の列の範囲が広がる。論文は、Z-order は各ファイルが選んだ列のそれぞれで狭い範囲の値を持つようにし、統計による読み飛ばしと組み合わせて、読むファイルを減らすと説明する⁸。

2020 年の論文は、表に Z-order の指定を置き、あとから変えられる設計を述べていた⁸。現在の Databricks の命令では、OPTIMIZE sales.silver.orders ZORDER BY (order_date, customer_id) のように、OPTIMIZE を実行するたびに列を指定する³。ストレージの上では、ビンパッキングと同じく、並べ替えた行を新しいファイルに書き、ログに元のファイルの remove と新しいファイルの add を一件の版として記録する⁹。限界は三つある。

• 列を足すほど効果が落ちる。 Databricks の文書は、列を一つ足すごとに効果が落ちるとする³。列が増えると平面が立体、さらに高い次元になり、一つの列あたりの範囲の狭まり方が小さくなるためと考えられる。統計を取っていない列を指定しても効果は無い³。
• まとめ直しの範囲が広い。 オープンソース版の文書は、Z-order を実行するたびに、パーティションの中の新しいファイルも、前に Z-order を済ませたファイルも含めて、すべてのファイルを並べ直そうとすると書く¹¹。Databricks の文書は、Z-order は増分の操作を目指すが、繰り返すたびに時間が短くなる保証は無いとする。ただし、Z-order を済ませたパーティションに新しいデータが入っていなければ、そのパーティションにもう一度実行しても何も変わらない³。文書の構文の例は、WHERE で対象を直近 1 日のデータに絞っている³。
• パーティションをまたげない。 パーティションを分けた表では、Z-order はパーティションの中でしか働かない⁷。

リキッドクラスタリング：キーを表に記録して、少しずつまとめる

リキッドクラスタリングは、パーティションと Z-order に代わる、データの配置の最適化の方法である⁵。クラスタリングキーとする列を最大 4 つ選ぶと、そのキーの値が近い行が同じファイルに集まる。Databricks は、ストリーミングテーブルやマテリアライズドビューを含むすべての新しい表に、リキッドクラスタリングを勧めている⁵。パーティションや Z-order とは併用できない。

ストレージの上では、二つのことが変わる。一つは、値ごとにディレクトリを分けないことである。ログの add の記録の partitionValues は空になり、まとめたファイルの add には、どの実装でクラスタリングしたかを示す clusteringProvider が書かれる。まだまとめていない追記のファイルには、これが無い²。もう一つは、キーがログに記録されることである。仕様は、クラスタリングキーを、delta.clustering という名前の記録（ドメインメタデータ）に残すよう定めている²。モデルの表のログには、縮めて書くと次のような記録が入る。

{"domainMetadata": {"domain": "delta.clustering",
  "configuration": "{\"clusteringColumns\":[[\"order_date\"],[\"customer_id\"]]}"}}
{"add": {"path": "part-a01.parquet", "partitionValues": {},
         "clusteringProvider": "liquid", "stats": "..."}}

並べ方の曲線について、Microsoft で Fabric の Spark の機能を担当する Cole は、オープンソースの実装では、キーが一つなら Z-order 曲線を、二つ以上ならヒルベルト曲線を使うと書いている¹⁴。どちらも、複数の列の近さを保つ並べ方である。Z-order との違いは、曲線よりも、キーが表に記録されることから生まれる。

• キーを毎回指定しない。 キーは表の定義なので、OPTIMIZE は列を指定せずに実行でき、記録されたキーでまとめる⁵。書き込みの量が一定の大きさを超えると、書き込みの時点でもまとめる⁵。
• まとめる必要のあるデータだけを書き直す。 Databricks の説明では、リキッドクラスタリングは増分で働き、OPTIMIZE はまとめる必要のあるデータだけを書き直す⁵。仕様も、書き手が特定のファイルを特定の時点でまとめる必要は無いと定め、まとめ直す対象を、既定では同じ実装でまとめたファイルと、まだまとめていないファイルに限っている²。モデルでいえば、翌日に追記された約 290 個の小さなファイルを中心に、次の OPTIMIZE でまとめ直す。ただし、オープンソース版 3.2 の実装は、まとまりきっていないファイルの群れを丸ごと書き直していた¹⁴。Databricks は、予測的最適化を使わない場合、更新や追記の多い表では 1〜2 時間ごとに OPTIMIZE を実行するよう勧めている⁵。
• キーを変えてもデータを書き直さない。 ALTER TABLE ... CLUSTER BY でキーを変えると、新しいキーを書いた delta.clustering の記録が一件の版としてログに足され、データファイルは変わらない²⁵。その後の OPTIMIZE と書き込みが新しいキーを使う⁵。既存のデータも新しいキーでまとめ直すには OPTIMIZE ... FULL を実行し、大きな表では何時間もかかることがある⁵。初めてキーを付けたときとキーを変えたときには、FULL を付けて実行するよう文書は勧める⁵。

キーの数は多ければよいわけではない。10 TB 未満の表では、キーを増やすと、一つの列で絞り込むクエリが遅くなることがある⁵。キーの選び方に迷う場合は、CLUSTER BY AUTO で、Databricks にキーを選ばせることもできる。これは Unity Catalog のマネージドテーブルで使え、予測的最適化を前提にする⁵。

リキッドクラスタリングは、Databricks では 2024 年 5 月の Databricks Runtime 15.2 で一般提供になり¹⁵、現在の文書は Databricks Runtime 15.4 LTS 以降での利用を一般提供としている⁵。オープンソース版の Delta Lake では、3.1 でプレビューとして入り、3.2 でプレビューの設定が要らなくなった。既存の表で後から有効にする命令と OPTIMIZE ... FULL は、3.3 以降で使える¹⁶。

リキッドクラスタリングの効果についての証拠

リキッドクラスタリングが速いことを示す数字の多くは Databricks 自身のもので、外部の報告は処理系と版によって評価が分かれる。Databricks は一般提供の発表で、パーティションと Z-order を組み合わせた場合より書き込みが 7 倍速いと述べたが、これは社内のベンチマークによる数字である¹⁷。同じ Databricks の 2026 年の記事は、2 年前には、10 PB のリキッドクラスタリングの表で OPTIMIZE の計画の段階に最大 12 時間かかる場合があったと認め、その後 23 分まで縮めたと書いている⁶。

Databricks の外では、独立のデータエンジニアの Beach が、リキッドクラスタリングに移してクエリが大きく速くなったのを見たと書いているが、数字は示していない¹⁸。Microsoft の Cole は、オープンソース版 Delta Lake 3.2 を使う Fabric の処理系では、少しの追記のあとの OPTIMIZE が、まとまりきっていないファイルの群れを丸ごと書き直してしまう（書き込みの増幅）ので、無条件に採用することを考え直すよう顧客に注意していたと書いている¹⁴。同じ記事は、筆者自身が作った Fabric の Runtime 2.0 の機能が、まとめ直すファイルを、まだまとめていないファイル、小さなファイル、削除ベクトルの多いファイルに絞ってこれを解消したとし、リキッドクラスタリングは今や標準の配置の方法になるべきだと結んでいる¹⁴。これは Databricks の処理系についての話ではない。

リキッドクラスタリングと Z-order を、Databricks の社外の人が同じデータで比べ、方法と数字を示した測定は、見当たらなかった。

予測的最適化：保守を自動で行う

ここまでの OPTIMIZE と VACUUM を、表ごとに人が計画して実行するのは手間がかかる。予測的最適化は、Unity Catalog のマネージドテーブルについて、OPTIMIZE、VACUUM、統計を取る ANALYZE を Databricks が自動で実行する機能である¹⁹。外部テーブルは対象にならない。実行には、ジョブ用のサーバーレスの計算資源が使われ、その分が課金される¹⁹。

予測的最適化は、2024 年 11 月 11 日以降に作られたアカウントでは既定で有効で、既存のアカウントへも段階的に広げており、文書は 2026 年 10 月の時点でも、2026 年 8 月までに完了する見込みと書いている¹⁹。予測的最適化の下で実行される OPTIMIZE は Z-order を行わない¹⁹。また、表の保持期間を 7 日より短く設定しても、予測的最適化の VACUUM は、少なくとも 7 日分のファイルを残す¹⁹。

保守を怠った場合の影響については、外部の測定がある。Microsoft の研究者による LST-Bench は、Delta Lake を含む複数の表の形式を比べ、データファイルがたまると性能が落ち、その幅は調べた形式の中で最大 6.8 倍に達し、保守がそれを和らげることを示した²⁰。ただし、測った Delta Lake は調整を加えない 2.2.0 で、削除ベクトルやリキッドクラスタリングが広まる前の版である。原典は劣化の主な原因を、Spark の既定の設定が書き込みを細かく分け、数十万のデータファイルを作ったことに求めている²⁰。

削除ベクトル：ファイルを書き直さずに行を消す

一人の顧客の注文をすべて消すよう依頼が来たとする。削除ベクトルが無ければ、C-00017 の行を含むファイルごとに、その行を除いた写しを書き、ログで元のファイルを除いて写しを加える。Databricks の文書がいうように、削除ベクトルが無い表では、行を一つ変えるにもその Parquet のファイルを丸ごと書き直す²¹。

削除ベクトルを使うと、元のファイルは書き直さない。代わりに、そのファイルの何行目が消えたかを記録した小さなファイルを、deletion_vector で始まる名前で表の中に書く。小さければ、ログの記録の中に直接書くこともある²。ログには、元のファイルを削除ベクトル無しの形で除き、同じファイルを削除ベクトル付きの形で加える記録が入る。

{"remove": {"path": "part-a01.parquet", "dataChange": true}}
{"add": {"path": "part-a01.parquet", "dataChange": true,
         "deletionVector": {"storageType": "u", "pathOrInlineDv": "...",
                            "sizeInBytes": 40, "cardinality": 2}}}

仕様は、表の一つのファイルを、データファイルの場所と、どの行がもう表に無いかを示す削除ベクトルの組として扱う²。cardinality は、この削除ベクトルが消す行の数である。消した行はデータファイルに物理的に残っており、読み手は読むときにそれを飛ばさなければならない²。

書き込みは速くなり、読み取りには手間が加わる。Microsoft の Cole は、1 億行の表から一行を消す処理が、削除ベクトルを使うとほぼ 8 倍速かったと報告した²²。読み取りの遅れは変更の量で違い、同じ記事は、500 万行の MERGE だけを加えた場合は 1.5 倍、1 億行の表の 53% にあたる変更を加えて OPTIMIZE を実行しないままにした場合は 2.3 倍だったと書く²²。測ったのは Microsoft Fabric とオープンソース版の Delta Lake 3.2 で、Databricks ではない。

消した行をストレージから本当に消すには、別の手順が要る。ファイルの圧縮だけでは、削除ベクトルに記録した変更が必ずファイルに反映されるとは限らない²¹。Databricks の文書は、REORG TABLE ... APPLY (PURGE) で削除ベクトルの付いたファイルを書き直し、そのうえで VACUUM で古いファイルを消す手順を示し、ストレージの費用を減らすためや GDPR のような削除の求めに応えるために使うとしている²¹。

新しい機能と古いクライアント

削除ベクトルを知らないクライアントが part-a01.parquet をそのまま読むと、消したはずの C-00017 の行まで返してしまう。そのため仕様は、削除ベクトルを使う表に、読み取りのプロトコルの版 3 と、deletionVectors という読み取りの機能の宣言を求める²。この宣言を理解しないクライアントは、表を読むこと自体をしない²³。Databricks の文書によれば、オープンソース版の Delta Lake で削除ベクトルの表を読むには 2.3.0 以降が要る²¹。

一方、クラスタリングは、仕様の上では書き込みの機能だけを使う²。そのためオープンソース版の Delta Lake では、リキッドクラスタリングの表でも、読み取りのプロトコルの版は 1 のままである¹⁶。ところが Databricks でリキッドクラスタリングを有効にすると、v2 チェックポイントや削除ベクトルなどの機能も既定で一緒に有効になり²³、表は読み取りのプロトコルの版 3 を使うので、これに対応しない Delta Lake のクライアントは読めない⁵。別の部署が古いクライアントで注文の表を読んでいれば、既定のままリキッドクラスタリングを有効にした時点で、その読み取りは止まる。これを避けるため、文書は、既存の表では有効にする前に、一緒に有効になる機能を止める手順も示している⁵。

Databricks の文書は、プロトコルの引き上げの多くは元に戻せず、既存の読み手や書き手を壊しうると警告している²³。機能によっては DROP FEATURE で表から外せるが、外せない機能もある²⁴。checkpointProtection という機能に対応しない外部のクライアントで表に書き込む場合は、24 時間より古い履歴をすべて消す手順が要り、消した履歴の版にはタイムトラベルできなくなる²⁴。

削除ベクトルを新しい表で既定で有効にするかどうかは、ワークスペースの設定で決まり、その既定の値は地域によって違う²⁵。Databricks は、互換性の無い Databricks Runtime の版や、外部の Delta Lake のクライアントで使う表を除いて、すべての表で削除ベクトルを使うよう勧めている²⁵。また、Iceberg のクライアントから Delta Lake の表を読ませる機能のうち、Iceberg v2 での読み取りとは、削除ベクトルを同時に使えない²⁶。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。