ログラスの龍島(@hryushm)です。最近近所の公園の池に鴨が来るようになりました。今回はDuckLakeの話をします。
前回の記事ではIcebergのメタデータファイル読み込みによるPlanning遅延について考えました。
今回のテーマは「メタデータをどう管理するかの変遷」です。
Hiveの時代はDBで管理していたメタデータを、Icebergではファイルに逃がしました。しかし2025年6月、DuckDB Labsが発表した「DuckLake」は再びDBでの管理を提案しています。今回は、「DB→ファイル→DB」という技術の螺旋を辿りながら、IcebergとDuckLakeの違いを捉えていきます。
素朴な疑問
Planningが遅い原因はメタデータファイルの読み込みでした。ここで素朴な疑問が湧きます。
「この処理、DBの方が得意なのでは？」
インデックス、オプティマイザ、効率的な検索などはDBが長年磨いてきた領域です。なぜIcebergはあえてファイルで管理しているのでしょうか？そしてなぜDuckLakeは再びDBに戻ったのでしょうか？
この変遷を理解するために、メタデータ管理の歴史を紐解いてみます。ここで参考になるのが、@t_wada氏が語る「技術の螺旋」という概念です。技術の発展は単純な直線ではなく、螺旋状に進む。一見「元に戻った」ように見える技術選択も、実は一段高い位置にあることが多い。つまり新しい技術的基盤の上に立っている。という洞察です。
| 時代 | アプローチ |
|---|---|
| Hive時代 | DBで管理 |
| Iceberg時代 | ファイルで管理 |
| DuckLake時代 | 再びDBで管理 |
このメタデータ管理のアプローチの変遷を螺旋として捉えていってみましょう。
Hive時代の課題：Netflixが直面した限界
Icebergの生みの親であるNetflixがAWS re:Invent 2023で語った内容が参考になります。
Hive時代、Netflixは約60万のテーブルと2億5000万のパーティションを抱えていました。この規模で発生した問題は主に3つです。
- ACIDの不在: 標準でトランザクションがなく、独自の回避策が必要だった
- スキーマ変更の困難さ: ペタバイト規模のテーブルでスキーマを変えるには、全データの書き直しが必要だった
- Metastoreのスケール限界: MySQL RDSでは2億5000万パーティションを捌ききれず、Noisy Neighbor問題が頻発した
We tried different things like scaling out or sharding our Hive Metastore instances, but we again started hitting resource limits on MySQL.
（訳）スケールアウトやシャーディングなど様々なことを試しましたが、MySQLのリソース制限に再び突き当たりました。
Icebergの解決策：メタデータもファイルに
Icebergはこれらの課題に対して、メタデータもファイルで管理するというアプローチで解決を図りました。
Icebergはメタデータを階層的なファイル構造（Metadata File → Manifest List → Manifest File）として自己管理します。カタログ（DB）には「最新のMetadata Fileはどれか」というポインタだけを保持します。
これにより、ACIDトランザクション、スキーマ進化、タイムトラベルなどが実現されました。NetflixはIcebergへの移行で25%のコスト削減とクエリの大幅な高速化を達成しています。
トレードオフ
しかし、すべてをファイルに逃がした結果、スケーラビリティは得られたものの新たなトレードオフが生まれました。
- Planningのオーバーヘッド: メタデータファイルの読み込み自体にコストがかかる（前回記事の内容）
- 機能の制限: マルチテーブルトランザクションなど、ファイルベースでは複雑な実装が必要になる機能がある
そして、結局DBは必要でした。Icebergの構造は「データ→ファイル」「メタデータ→ファイル」「メタメタデータ（ポインタ）→DB」という入れ子構造になっています。どこまでファイルに逃がしても、最後の整合性の起点にはDBが必要となっていました。
DuckLakeの登場：DB回帰
ここで登場するのがDuckLakeです。
DuckDBを開発するDuckDB Labsは、MotherDuckと共にDuckLakeを発表しました。MotherDuckのJordan Tigani氏は"Big Data is Dead"というブログ記事で興味深い指摘をしています。
The most surprising thing that I learned was that most of the people using "Big Query" don't really have Big Data.
（訳）最も驚いたのは、BigQueryを使っている人のほとんどが、実際にはBig Dataを持っていないということでした。
多くの企業のデータウェアハウスは1TB未満であり、Netflixのような数百PB規模は例外です。そしてIcebergやDelta Lakeも結局カタログにDBを必要としています。ならばメタデータ管理もDBに任せればいいのではないか？という発想です。
DuckLake Manifestoでは、この発想が明確に語られています。
Once a database has entered the lakehouse stack anyway, it makes an insane amount of sense to also use it for managing the rest of the table metadata!
（訳）どうせカタログにDBが入っているなら、残りのメタデータ管理にもDBを使うのは非常に理にかなっています！
BigQuery（Spanner）やSnowflake（FoundationDB）も同じようなアプローチを採用しており、DuckLakeは、このアプローチをオープンフォーマットとして提供しようとしています。
DuckLakeのアーキテクチャ
DuckLakeのスキーマを見ると、Icebergの設計思想がSQLテーブルに落とし込まれていることがわかります。
出典: DuckLake Specification - Tables
-
ducklake_snapshot: Icebergのスナップショット管理に相当 -
ducklake_data_file: Manifest Fileが持っていたデータファイル情報 -
ducklake_column_stats,ducklake_file_column_stats: 統計情報（min/max等） -
ducklake_partition_column: パーティション定義
Icebergでは複数のAvro/JSONファイルに分散していた情報が、リレーショナルなテーブル構造として整理されています。カタログDBにはPostgreSQL、DuckDB、MySQL等の任意のACID対応DBを使用できます。
Manifestoでは、Icebergとの比較で以下の利点が挙げられています。
- Planningの高速化: Icebergでは複数のメタデータファイルを順次読み込む必要があり、複数のHTTPリクエストが発生する。DuckLakeでは単一のSQLクエリでPlanningが完結する
- 小さな変更への対応: Icebergでは小さな変更でも新しいスナップショットファイルが必要。DuckLakeでは小さな変更をDBに直接インライン化できるため、ファイル数の肥大化を防げる
- 同時書き込みのコンフリクト解決: DBのトランザクション機能を活用することで、多数の同時書き込みでも高速にコンフリクトを解決できる
まとめ
DuckLakeのアプローチは、一見Hive Metastore（DB）時代への「逆戻り」に見えます。しかし、同じ場所に戻ったのではなく、一段高い場所にあると言えます。
Hive時代の問題は、DBそのものではなく、メタデータ管理の設計にありました。ACIDもスキーマ進化もなく、テーブルの変更には複雑なスクリプトが必要でした。Icebergはこれらをファイルベースの設計で解決し、数百PB級のデータに対応できるスケーラビリティを手に入れました。しかしそのトレードオフとして、シンプルさを犠牲にしました。
DuckLakeは、Icebergで培われた設計知見（スナップショット管理、統計情報、パーティション進化）をDBに持ち込んでいます。スケーラビリティはIcebergが実現するNetflix級には及びませんが、Hiveの問題を解決しつつ、Icebergが犠牲にしたシンプルさを取り戻していると言えます。
- Netflixのように数百PB規模: Icebergの複雑さを受け入れてスケーラビリティを取る
- 数百TB規模まで: DuckLake的アプローチでシンプルさと速度を享受（Manifestoによれば、PostgreSQLバックエンドで数百TBのデータと数千のコンピュートノードをサポート可能）
DuckLakeはまだ発展途上であり、エコシステムも整っていません。しかし、Icebergではオーバースペックだった多くのユースケースに対して、シンプルで実用的な選択肢を提供してくれる可能性を感じます。今後の発展に注目したいです。
Discussion