データ基盤

オープンテーブルフォーマットとは：版をログで差し替える仕組み

2026/10/7 シリーズ「データ基盤はなぜ作り直されてきたか」 第6回 / 全7回

🤖 AIが執筆しています

ディレクトリをテーブルとみなすと、一覧は遅く、変更は途中で見える

Databricks の Armbrust らは 2020 年の Delta Lake の論文で、オブジェクトストレージにファイルを置いただけのテーブルの問題を挙げた¹。複数のファイルの更新は不可分ではないので、読む人は書き換えの途中を見る。更新の処理が途中で止まると、テーブルは壊れた状態で残る。さらに、S3 の一覧の取得は一回で最大 1,000 件しか返さず、一回に数十から数百ミリ秒かかるので、数百万のファイルを順に一覧するには数分かかる。論文の時点では S3 の一覧の結果が遅れて反映されることもあったが、S3 は 2020 年 12 月に、書いた直後から一覧に反映される形に改められた²。

Netflix が Apache ソフトウェア財団に出した Iceberg の提案書も、同じ弱点を前提にしている³。提案書は、オブジェクトストレージには結果の反映の遅れ、ディレクトリの一覧の遅さ、名前の変更ができないこと、フォルダの階層が無いことがあると書く。Netflix の時系列の計測データのテーブルは、1 か月分が 2,688 のパーティションに分かれた 270 万個のファイルでできていた。このテーブルを Hive のテーブルとして問い合わせると、実行の計画を立てるだけで 9.6 分かかった（Netflix の初期の測定）。

利用企業の記録もある。Airbnb は 2022 年の記事で、Hive のテーブルのパーティションが増えるにつれ、パーティションの情報を管理するデータベースの負荷が問題になったと書いた⁴。同じ記事は、エンジンごとにスキーマ変更の扱いが違ったので、スキーマを変えるとほぼ毎回、データの品質の問題が起きるか、費用のかかる書き直しが必要になったとも書いている。

テーブルの版を一つのメタデータで切り替えると、変更は全部か無かになる

オープンテーブルフォーマットとは、Parquet のような誰でも読める形式のデータのファイルはそのままにして、どのファイルがテーブルのどの版に属するかを管理用の記録（ログやメタデータ）に書き、その記録を不可分に差し替えることでテーブルを更新する決まりのことである。代表的なものに Delta Lake・Apache Iceberg・Apache Hudi がある。

Delta Lake の考え方は、どのファイルがそのテーブルに属するかを、オブジェクトストレージの中に置いたトランザクションログ（変更の記録を順に積んだもの）で管理することである¹。ログは番号を振ったファイルの並びで、変更を確定させるには、次の番号のログのファイルを「まだ誰も書いていなければ」書く。この書き込みが成功した時点で、変更は全部まとめて確定する。現在の Delta の仕様も、ログのファイル一つ一つがテーブルの不可分な変更の単位だと定めている⁵。データのファイルもログも書き換えないので、前の版のテーブルを読むタイムトラベルもできる。ただし論文の時点の S3 には「まだ無ければ書く」という操作が無く、Databricks は自社のサービスで、同じ番号のログを一人だけが書けるようにする別の仕組みを使っていた。S3 は 2024 年 8 月に、この操作に当たる条件付きの書き込みを加えた⁶。

Delta Lake の論文は、この形の効果を測っている¹。3,300 万行の小さなテーブルを 1,000 から 100 万のパーティションに分け、16 台の機械で全行を合計する問い合わせを流した。別の会社が提供する Hive は 1 万のパーティションのテーブルでファイルを見つけるのに 1 時間を超え、Delta Lake は 100 万のパーティションでも 108 秒だった。比べたエンジンは製品ごとに違い、テーブルの形式だけの差ではない。ただし同じ Databricks のエンジンでも、ログを使わない Parquet のテーブルは 10 万のパーティションで 450 秒かかった。

Apache Iceberg も、ディレクトリではなく個々のファイルを記録で管理する⁷。テーブルの状態は管理用のファイル（メタデータファイル）に書かれ、ある時点のテーブルの版（スナップショット）がどのファイルからなるかを記録する。変更のたびに新しいメタデータファイルを作り、テーブルが指す先を古いものから新しいものへ一回で差し替える。差し替えの前に別の変更が確定していれば、書き手は最新の版をもとに作り直す。Iceberg の仕様は、列を名前ではなく番号で追うと定めている。そのため、列の名前や順序を変えても（スキーマ進化）、それ以前に書いたファイルは正しく読める。先の Netflix の提案書によれば、Iceberg のテーブルでは、計画はパーティションによる絞り込みだけで 10 秒（問い合わせ全体は 13 分）、ファイルごとの最小値と最大値による絞り込みも使うと 25 秒（同 42 秒）だった³。これらは Netflix 自身の初期の測定である。

Apache Hudi は、Uber が 2017 年に発表した⁸。Hudi も、変更の確定を時系列の記録（タイムライン）に書き、行の更新をファイルの集まりに反映させる。Uber は 2018 年の記事で、Hudi を使って、テーブル全体を取り込み直す方式から変わった分だけを取り込む方式に移り、データが使えるようになるまでの遅れを 24 時間から 1 時間未満に縮めたと書いた⁹。これは HDFS 上の自社報告で、同じ時期に Marmaray という取り込みの仕組みも入れている。

Databricks の研究者は 2021 年の論文で、オブジェクトストレージの上にこうした記録の層を置き、データベースの機能を持たせたシステムをレイクハウスと呼んだ¹⁰。論文は、商用のデータウェアハウスがデータを独自の形式に閉じ込めると批判し、レイクハウスでは誰でも読める形式のファイルを直接読めると主張する。著者は全員 Databricks に属し、自社の方向を説明する立場にある。

更新の費用を、書き手と読み手のどちらが払うかを選ぶ

ファイルを書き換えずに行を更新する方法は、二つに分かれる。Hudi の文書は、これを Copy-on-Write と Merge-on-Read と呼ぶ¹¹。Copy-on-Write は、更新のたびに対象の行を含むファイルを丸ごと書き直すので、読むときの手間は増えないが、少しの行を変えるだけでも書き込みが重くなる。Merge-on-Read は、変更を小さな記録のファイルに書いておき、読むときに元のファイルと合わせるので、書き込みは速いが、読むたびに合わせる手間がかかる。後で記録を元のファイルに取り込む作業（コンパクション）をしないと、読む手間は増え続ける。Delta Lake も、消した行を別の記録で示し、読むときに飛ばす仕組みを仕様に加えている⁵。

Jain らは 2023 年の論文で、三つの形式を同じ条件で比べた¹²。Hudi では、Merge-on-Read のテーブルへの行の更新は Copy-on-Write より 1.3 倍速かったが、更新後の問い合わせは 3.2 倍遅かった。一方、Iceberg 0.14 の Merge-on-Read は更新が 1.4 倍速く、この実験では更新後の問い合わせの速さはほぼ変わらなかった。ただし同じ論文の別の実験では、Iceberg 1.1.0 の Merge-on-Read も更新後の読み込みが大きく遅くなり、約 1 万行の変更で Copy-on-Write より遅くなった。この論文の著者には Databricks の研究者が含まれる。測定は各形式の 2022 年時点の既定の設定によるが、最初の実験の Iceberg だけは接続の上限を増やして測った。その実験では新しい 1.1.0 の Merge-on-Read がタイムアウトを繰り返したので、0.14 で代えている。

それでも、ファイルの整理と、メタデータの在りかを握るカタログは残る

記録を差し替える設計は、ファイルの整理を不要にしない。Iceberg の文書は、古い版の記録は消すまで溜まり続けるので定期的に期限切れにすることと、小さなファイルが多いと管理用の情報が増え、ファイルを開く費用で問い合わせが遅くなることを書いている¹³。Microsoft の研究者は 2024 年の論文で、TPC-DS（分析の性能を比べる業界標準の測定）の問い合わせと更新を、Spark の上で、間に整理の作業を挟まずに二回続けて流した¹⁴。二回目の所要時間は一回目より、Delta Lake で 92%（2.7 時間から 5.2 時間）、Iceberg で 45% から 73% 長くなった。Hudi は 5% から 6% しか延びなかったが、一回目から Copy-on-Write で 6.2 時間、Merge-on-Read で 23 時間かかっていた。著者らは、性能のよい形式でも時間とともに大きく遅くなりうると書いている。同じ論文は、性能と費用はエンジンや整理の進め方にも大きく左右されるとも述べる。この測定は、公式の監査を受けていない。

書き込みの回数にも上限がある。Delta Lake の論文は、オブジェクトストレージへの書き込みには数十から数百ミリ秒かかるので、一つのテーブルへの変更は一秒あたり数回しか確定できないと書いたが、当時の利用にはほぼ十分で、ログへの書き込みを仲介する仕組みで速くできるとも書いた¹。2023 年の Jain らの論文は、同時に多くの書き込みを高い頻度でこなせるかを、未解決の問いとして挙げている¹²。変更を不可分にできるのは、一つのテーブルの中だけである¹。

もう一つの課題は、テーブルが指す先を差し替える場所である。Iceberg の仕様は、ファイルシステムだけで差し替える方式をオブジェクトストレージでは安全でないとして廃止の予定にし、残る方式として、データベースなどに置いたポインタを確かめながら書き換える形を示している⁷。つまり、テーブルの最新の版を決めるのは、ファイルの外にあるカタログである。Delta の仕様にも、カタログを変更の成否の判定役にする方式が加わった⁵。

2024 年 6 月、このカタログをめぐって二つの会社が続けて動いた。Snowflake は Iceberg 用のカタログ Polaris を発表して 90 日以内のソースコードの公開を予告し、エンジンとカタログの間の制約が、オープンな標準の価値を損なう囲い込みを生んでいると書いた¹⁵。Databricks は自社のカタログ Unity Catalog のソースコードを公開し、Iceberg のカタログの API にも対応させた¹⁶。同じ月に Databricks は、Iceberg の作者らが作った会社 Tabular の買収を発表し、Delta Lake と Iceberg はどちらも Parquet を土台に似た設計を持ちながら、別々に開発されたことで互換性を失ったと書いた。同じ記事は、三つの形式のあいだの互換性を持たせる Delta Lake UniForm を対策に挙げ、Iceberg の元のチームを迎えてその範囲を大きく広げるとした¹⁷。Unity Catalog は公開の時点で Linux Foundation の傘下の LF AI & Data に置かれ¹⁶、Polaris は 2024 年 8 月に Apache ソフトウェア財団のインキュベータに入って、2026 年 2 月に正式なプロジェクトになった¹⁸。カタログのソースコードが財団の下に置かれても、オープンなファイルの形式の上でテーブルの最新の版をどの会社のカタログで決めるかは、各社の争点として残った。

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