データ基盤

Delta Lakeとは？ファイルとトランザクションログの仕組み

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

🤖 AIが執筆しています

orders/
├── _delta_log/
│   ├── 00000000000000000000.json   版 0：表を作る（列の定義）
│   ├── 00000000000000000001.json   版 1：part-A を加える
│   ├── 00000000000000000002.json   版 2：part-B を加える
│   └── 00000000000000000003.json   版 3：part-A を除き、part-C を加える
├── part-A.parquet   1回目の注文（顧客 C-00017 の注文を含む）
├── part-B.parquet   2回目の注文
└── part-C.parquet   part-A から C-00017 の注文を除いた写し

Delta Lake とは：Parquet のファイルとトランザクションログ

Databricks の文書は、Delta Lake を、Parquet のデータファイルに、ACID のトランザクションと規模の大きいメタデータの扱いのための、ファイルによるトランザクションログを加えたオープンソースのソフトウェアと説明する¹。Delta Lake は Databricks でのすべての操作の既定の形式で、特に指定しない限り、Databricks の表はすべて Delta Lake の表になる¹。

トランザクションログの形式は、どのシステムでも読めるオープンなプロトコルとして公開されている¹。プロトコルの仕様は、表のメタデータをすべてデータの横に置く設計を、自己記述的と呼ぶ³。この設計なら、データを読むためだけに別のメタストアを保つ必要が無い。Delta Lake は Databricks が最初に開発した形式で¹、2019 年から Linux Foundation の傘下のプロジェクトになっている⁴。

Parquet のファイル：列ごとにまとめ、一度に書く

Parquet は、表のデータを列ごとにまとめて持つ、オープンソースのファイルの形式である⁵。一つのファイルには一行ではなく多数の行が入り、その中は三つの段に分かれる⁵。

• 行グループ： 行をいくつかのまとまりに区切ったもの。一つのファイルは一つ以上の行グループからなる。
• 列のかたまり（列チャンク）： 行グループの中の、一つの列の値だけを集めたもの。ファイルの中で連続して置かれる。
• ページ： 列のかたまりをさらに分けたもので、圧縮と符号化はこの単位で行う。

注文の表のデータファイルの中身は、おおよそ次のようになる。

part-A.parquet
├── 行グループ 1
│   ├── order_id の列のかたまり
│   ├── order_date の列のかたまり
│   └── customer_id の列のかたまり
├── 行グループ 2
│   └── …
└── ファイルのメタデータ（列の定義、各列のかたまりの位置、最小値と最大値など）

読み手は、まずファイルの末尾のメタデータを読み、必要な列のかたまりの位置を知ってから、その部分だけを読む⁵。注文日だけを集計するクエリなら、顧客 ID や金額の列は読まずに済む。

この作りは、ファイルを先頭から終わりまで一度に書くことを前提にしている。仕様は、メタデータをデータの後ろに置く理由を、一度の通しで書けるようにするためだと説明する⁵。また、行グループ一つの大きさを 512 MB から 1 GB と大きく取るよう勧めている⁵。行を一つ足すには、どこかの列のかたまりに値を加え、そのページを圧縮し直し、後ろに続くかたまりの位置とメタデータを書き直すことになり、実質的にはファイルを作り直すのと変わらない。

保存先のストレージにも同じ制約がある。クラウドのオブジェクトストレージ（Google Cloud なら Cloud Storage）では、置いたオブジェクトは変えられず、末尾に足すことも途中で切ることもできない。できるのは、オブジェクトを丸ごと新しいものに置き換えることだけである⁶。

そのため、Delta Lake の表では、行を一つ足すときは、その行を入れた新しいファイルを書く。行を一つ変えるときは、その行を含むファイルの写しを書く。どちらの場合も、元のファイルには手を付けず、どのファイルが表に属するかをログで切り替える。この方式は、行を一つずつ頻繁に書き換える使い方には向かない。2020 年の論文は、書き込みのトランザクションの速さはログの記録を作る操作の遅延で決まり、1 秒に数件が上限になると書いている⁷。それでも足りるのは、取り込みの処理が多くの行と多くのファイルを一つのトランザクションにまとめて書くからだと論文は説明する⁷。注文を一件ずつ受け付ける業務のデータベースは別にあり、そこから変更の記録を取り出して、Delta Lake の表にまとめて流し込む構成が、論文の例に挙がっている⁷。

なぜログが要るのか：オブジェクトストレージの上の表

Delta Lake の設計を説明した 2020 年の論文は、クラウドのオブジェクトストレージに表を置くときの問題を二つ挙げる⁷。

一つは、複数のファイルにまたがる更新が原子的でないことである。ログが無い表では、ディレクトリにあるファイルがすべて表の中身になる。ある顧客の注文を除いた新しいファイル（モデルの part-C）を書き終え、元のファイル（part-A）を消す前に処理が落ちると、両方に入っているほかの顧客の注文が二重に数えられる。読む側から見ると、書きかけの part-D も表の一部に見えてしまう。

もう一つは、数百万のファイルからなる大きな表では、メタデータの操作が高くつくことである。どのファイルが表にあるかを知るには、ディレクトリの一覧を取る必要がある。また、各ファイルを読み飛ばせるかを確かめるには、ファイルごとにその統計を読む必要がある。オブジェクトストレージでは一回ごとの遅延が大きいので、これがクエリそのものより長くかかることがある⁷。

論文の著者は全員 Databricks の所属である（うち 3 人は大学や研究所と兼任）。サービスの初期（2014〜2016 年）に受けたサポートのエスカレーション（上位の担当への引き継ぎ）の約半分が、こうしたクラウドのストレージの使い方に起因する破損、一貫性、性能の問題だったと、経験談として書いている⁷。

Delta Lake は、どのファイルが表に含まれるかをログに記録することで、この二つに答える。表の今の状態は、ログで有効とされたデータファイルの全体であり、ログに載らないファイルは追跡されない⁸。また、ファイルの一覧と統計をログから読めるので、ディレクトリの一覧を取ったり、各ファイルを開いたりせずに、読むべきファイルを決められる⁷。

ディレクトリの中身：データファイルと _delta_log

オブジェクトストレージには、本当の意味のディレクトリは無い。各ファイルは、orders/part-A.parquet のような名前（キー）で置かれ、同じ文字列で始まるキーの集まりがディレクトリのように扱われる。この共通の先頭部分をプレフィックスと呼ぶ。論文は、Delta Lake の表を、ファイルシステムのディレクトリ、またはオブジェクトストレージで同じプレフィックスで始まるオブジェクトの集まりとして説明している⁷。

データファイルは、表の直下か、名前が _ で始まらない下のディレクトリに置かれる³。その名前は、書き手が重ならないように作る一意な識別子で、どのファイルがどの版に属するかは名前ではなくログで決まる⁷。仕様に載っているデータファイルの名前は、part-00000-3935a07c-416b-4344-ad97-2a38342ee2fc.c000.snappy.parquet のような形である³。本稿のモデルの part-A などは、これを縮めたものである。

トランザクションログは、表の中の _delta_log という名前の場所に置かれる。ログの記録は、版の番号を 20 桁にそろえた名前の JSON のファイルで、00000000000000000003.json は版 3 の記録である³。番号の先頭を 0 で埋めるのは、名前の辞書順が版の順と一致し、オブジェクトストレージの一覧の操作で、ある版より後の記録だけを効率よく見つけられるからである⁷。

ログの一件に書かれること

ログの一件には、前の版の表に当てて次の版を作るための操作（アクション）が並ぶ⁷。主なものは次のとおりである。

• add： ファイルを表に加える。ファイルの場所、大きさに加えて、行の数と列ごとの最小値・最大値・NULL の数といった統計を持てる³。
• remove： ファイルを表から除く。除いた時刻を持つ³。
• metaData： 列の定義やパーティションの列、表の設定を変える。表の最初の版には必ず含まれる⁷。
• protocol： この表を読み書きするのに要るプロトコルの版を上げる⁷。
• commitInfo： だれがどの操作をしたかといった来歴を残す⁷。

ある顧客の注文を含む part-A を表から除き、その顧客以外の注文を写した part-C を加える削除（モデルの版 3）の記録を縮めて書くと、次のようになる。

{"commitInfo": {"operation": "DELETE", ...}}
{"remove": {"path": "part-A.parquet", "deletionTimestamp": 1791676800000, "dataChange": true}}
{"add": {"path": "part-C.parquet", "size": 841454, "dataChange": true,
         "stats": "{\"numRecords\":118,\"minValues\":{...},\"maxValues\":{...}}"}}

読み手は、ログの初めから順に add と remove を当てていき、加えられてまだ除かれていないファイルの集まりを求める。これがその版の表の中身である⁷。add の統計は、クエリの条件に合う行を含みえないファイルを読み飛ばすのに使われる³。

版が増えると、すべての JSON を順に読むのは遅くなる。そこで、ある版までの表の状態を、Parquet のファイルにまとめて置く。これをチェックポイントと呼ぶ⁹。仕様が示す 00000000000000000042.checkpoint.parquet は版 42 までの状態を持ち、読み手はそこから後の JSON だけを読めばよい³。最新のチェックポイントの番号は _delta_log/_last_checkpoint に書かれ、読み手はまずこれを読む⁷。

書き込みとコミット：楽観的同時実行制御

プロトコルの仕様によれば、書き込みは二段階で進む³。まず、新しいデータファイルや、既存のファイルを書き換えた写しを書き出す。次に、ログに新しい記録を一件足して、表の新しい版を原子的に作る。これをコミットと呼ぶ。モデルで part-D を書いたあとに落ちた取り込みは、一段目を終えて二段目に進まなかった場合にあたる。

二段目を原子的にするには、次の番号の JSON を作れるのが一つの書き手だけである必要がある。論文によれば、Google Cloud Storage と Azure Blob Storage には、同じ名前のオブジェクトがまだ無いときだけ書く操作があり、それを使う⁷。当時の Amazon S3 にはこの操作が無く、Databricks のサービスでは、ログの書き込みだけを調整する軽いサービスを別に置いていた⁷。S3 は 2024 年 8 月に、オブジェクトがすでにあるかを確かめてから作る条件付きの書き込みに対応した¹⁰。

同時に書き込む処理どうしの調整には、楽観的同時実行制御が使われる⁸。これは、書き込みの前に表をロックせず、多くの書き込みは互いに衝突しないと見込んで進め、コミットの時点で衝突を確かめる方式である。二つの取り込みが同時に版 4 を作ろうとすれば、00000000000000000004.json を作れるのは一方だけである。仕様は、書き手が既存のログの記録を決して上書きしてはならないと定め、できる限りストレージの原子的な操作を使うべきだとする³。負けた側は、書いたデータファイルをそのまま使い、次の版として記録を書き直せる⁷。追記どうしは衝突しない¹¹。同じファイルを書き換える更新どうしのように衝突する場合は、後から来た書き込みが例外で失敗し、表は壊れない⁸。ただし、Databricks の文書によれば、S3 に置いた表では、複数のクラスターから同時に書いても壊れないという保証は一つのワークスペースの中に限られ、別のワークスペースから同じ表を変えないよう勧めている¹²。

既定では、読み取りにはスナップショット分離（読み手は、読み始めた時点の一つの版だけを見る）が、書き込みにはそれより強い書き込みの直列化可能性が保証される⁸。表のスキーマやプロトコルといったメタデータを変えると、同時に走るすべての書き込みが失敗しうる¹³。

外部の分析者の Vanlightly は、2024 年に Delta Lake の中心のプロトコルを TLA+ という形式仕様の言語でモデル化して検査し、上書きを防ぐ仕組みがある限り一貫性の違反は見つからず、複数の書き手がいても ACID の保証が成り立つと結論した¹⁴。ただし、検査したのは論理的なモデルで、チェックポイントやファイルの細部は対象の外だと本人が断っている。

更新と削除：ファイルを書き換えずに置き換える

削除ベクトルを使わない表では、行を変えるとき、Delta Lake の書き手は既存のデータファイルを書き換えず、その写しを新しく書き、ログで古いファイルを除いて新しいファイルを加える³。モデルで C-00017 の注文を消した版 3 がこれにあたり、part-A のうち C-00017 以外の行を part-C に写している。Vanlightly も、Delta Lake はファイルをその場で更新も上書きもせず、すべての変更をファイルの追加と、ログでの論理的な除去で表すとまとめている¹⁴。

この方式では、一行を変えるだけでも、その行を含む Parquet のファイル全体を書き直す必要がある¹⁵。Databricks には、元のファイルを残したまま消した行に印を付ける削除ベクトルという機能があり、有効にすると、行を消したときのログの記録が変わる¹⁵。新しい表では、ワークスペースの設定によって削除ベクトルが既定で有効になることがある¹⁶。

小さなファイルをまとめ直す OPTIMIZE も、同じ形の記録を残す。ログには、まとめる前のファイルの remove と、まとめたあとのファイルの add が並ぶ。このとき add の dataChange は false になり、データを並べ替えただけで中身は変わっていないことを示す⁹。

履歴とタイムトラベル：二つの保持期間

ログには保持期間の中の過去の版が残るので、DESCRIBE HISTORY で、だれがいつどの操作をしたかを調べられ、過去の版を指定して表を読むこともできる。これをタイムトラベルと呼ぶ⁹。モデルでいえば、SELECT * FROM sales.silver.orders VERSION AS OF 2 は、ログを版 2 まで当てて part-A と part-B を読む。消したはずの C-00017 の注文も、この問い合わせでは見える。

ただし、保持期間は二つある。ログの記録は既定で 30 日保たれ、データファイルは、表から外れたあとも既定で 7 日は消されない⁹。タイムトラベルができるのは、ログの記録と、その版が使うデータファイルの両方が残っている間だけである。そのため Databricks は、表の履歴を長期のバックアップとして使わず、両方の保持期間を延ばしていない限り、タイムトラベルは過去 7 日の範囲で使うよう勧めている⁹。新しい Databricks Runtime（Databricks のクラスターが動かす処理系の版）では、データファイルの保持期間より前の版を求めるタイムトラベルのクエリは止められる⁹。

VACUUM：表から外れたファイルを消す

VACUUM は、今の版の表から外れ、保持期間を過ぎたデータファイルをストレージから消す命令である¹⁷。保持期間は、表の設定 delta.deletedFileRetentionDuration で決まり、既定は 7 日である¹⁷。既定の動作では、ログに載っていないファイル、つまりモデルの part-D のように途中で落ちた書き込みが残したファイルも、保持期間を過ぎていれば消す¹⁷。_delta_log のように _ で始まる場所は対象にしない¹⁷。

remove で表から外れたファイルも、保持期間を過ぎれば VACUUM で消える。モデルの part-A のように、消した行を含むファイルもここに入る。そのため VACUUM は、ストレージの費用を減らすためだけでなく、消したはずのデータを本当に読めなくするためにも要る¹⁸。ただし、これには条件がある。削除ベクトルを使う表では、消した行が今のファイルに残るので、先に REORG TABLE ... APPLY (PURGE) でファイルを書き直す必要がある¹⁸。ディスクキャッシュを使うクラスターでは、再起動するまで、消したファイルのデータを読めることがある¹⁸。S3 のバケットでバージョニングを有効にしていると、VACUUM が消したファイルの写しも S3 の側に残る¹²。

保持期間を短くしすぎると、何日も走る処理がまだコミットしていないファイルまで消してしまう。そのため Databricks は 7 日以上を強く勧め、短い期間での実行を止める安全の検査を設けている¹⁸。オープンソース版の文書は、使用中のファイルが消されれば古い版を読んでいる処理が失敗し、まだコミットされていないファイルが消されれば表が壊れうるとも書いている¹⁹。Databricks では、予測的最適化を有効にした Unity Catalog のマネージドテーブルに対して、VACUUM が自動で実行される¹⁸。オープンソース版の Delta Lake では、VACUUM は自動では実行されない¹⁹。

一つの表を超えるトランザクション

2020 年の論文は、表ごとにログを持つので、トランザクションは一つの表の中でしか直列化できないことを、限界の一つとして挙げていた⁷。注文の表と在庫の表を同時に更新したくても、二つの _delta_log に一度に書く手段は無かった。

Databricks では、コミットの調整をファイルシステムからカタログへ移す仕組み（カタログコミット）²⁰が、2026 年 5 月に一般提供になった²¹。カタログコミットを有効にした表では、表の状態を決める唯一の基準はログではなく Unity Catalog になる²⁰。これを使う Unity Catalog のマネージドテーブルでは、複数の表にまたがるトランザクションが 2026 年 7 月に一般提供になった²²。Iceberg の表に書き込むトランザクションは、まだ限定的なプレビューの段階である²³。

プロトコルの版と、新しい機能

Delta Lake の形式は、機能を足しながら変わってきた。ログの protocol の記録は、その表を読むのに要る版と、書くのに要る版を持つ³。新しい版では、表が使う機能の名前（テーブル機能）が、読み取りに関わるものと書き込みに関わるものに分けて並ぶ³。

表のプロトコルにある機能に対応していないクライアントは、その表を書けない。読み取りに関わる機能であれば、読むこともできない²⁴。削除ベクトルのように、データファイルの読み方そのものを変える機能を有効にすると、これに対応しない古いクライアントは表を読めなくなる。Databricks の文書は、プロトコルの引き上げの多くは元に戻せず、既存の読み手や書き手を壊しうると警告している²⁴。

データとログが公開された形式のファイルであることは、どのクライアントでも表を読めることを意味する。ただしそれは、そのクライアントが表の使う機能に対応している限りでのことである。

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