Zenn
🧑‍🤝‍🧑

Apach Icebarg vs Delta lake

に公開
data
Snowflake
Databricks
iceberg
deltalake
tech

Apach Iceberg と Delta lake の違いとは

最近大規模データやLakehouseの話をしたときに必ず現れるApach IcebergとDelta lakeですが、今回はこれらの違いについて紐づいていきたいと思います。

先に結論：利用する上での違い

まず背景などすっ飛ばして、利用する際の違いだけに言及すると、以下の記事がとても参考になったため引用しておきます。
https://www.datacamp.com/blog/iceberg-vs-delta-lake
上記リンク先の Apache Iceberg vs Delta Lake: A Summary に記載があります。

Features Apache Iceberg Delta Lake
ACID transaction Yes Yes
Time travel Yes Yes
Data versioning Yes Yes
File format Parquet, ORC, Avro Parquet
Schema evolution Full Partial
Integration with other engines Apache Spark, Trino, Flink Primarily Apache Spark?※
Cloud Compatibility AWS, GCP, Azure AWS, GCP
Query Engines Spark, Trino, Flink Spark ?※
Programming Language SQL, Python, Java SQL, Python

そしてここにもう一つ大事な点を加えるのであれば、Delta lakeの方が Databricksを使うのであればメリットが多いということです。

Apach Iceberg と Delta lakeの共通項

ACID transactionを持っている

ACID transationは原子性/独立性/一貫性/永続性を担保する仕組みであり、つまりはデータベースの信頼性を確保するための仕組みです。
当たり前ですが目新しいものではなく、RDBMSの時代から長い歴史を持つものであり、検索すれば山の様に記事が出るので説明は割愛します。
https://www.databricks.com/glossary/acid-transactions

Time travel

Time travelは過去のテーブルの状態が保持されており、queryでその時の状態に遡れる機能です。
Delta lakeの一例としては下記のようなSQLである時点のデータに対してqueryするとこができます。
時間を指定することも可能です。

SELECT count(*) FROM my_table VERSION AS OF 5238

Data versioning

これはTime travelの説明と重複するのですが Dataを Version管理できます。
特に機械学習の分野においては、実験管理時にVersionを記載しておくだけで、どの時点のデータを利用したか分かり易いので、必要以上に訓練データを分割・保持する必要がなくとても便利です。

Schema evolution

大体はスキーマシンかと訳されることが多そうですが、以下のことが実現可能です。

  • 新しいデータを書き込みに行く際に新しい列が存在していると、自動でその列を追加する。
  • 逆に列が消えた場合は削除する。
  • 新しいデータを書き込みに行く際に、データに依存し列名を自動で変更する。
  • 新しいデータを書き込みに行く際に、データに依存し列順を自動で変更する。
  • 新しいデータを書き込みに行く際に、データに依存し自動で型を変更する。

普通のRDBMSを使ってきた自分としては恐怖を感じますが、機械学習や分析を経験した視点から見るととても柔軟かつ便利な機能です。
特に双方半構造化データを扱うことも想定に作られており、型や構造が変わる性質のある json形式のデータなどを扱いたい場合には、一々型変更をしている暇はありません。
機械学習においても特徴量エンジニアリングを行うタスクの場合、特徴量の変化に対して柔軟に形を変えてくれる機能はとても役に立ちます。

Cloud Compatibility = Open source

双方Open sourceであることから各クラウドに対して垣根なく利用することができます。
後ほどもう少し深く言及しますが、すでにDataricksはTabular社を買収し、IcebergとDelta lakeの統合に向けて活動を進めています。しかしその中には今後もOpen Sourceに貢献していくことが言及されていて、買収後も双方ベンダーロックのない世界を作りたいと考えていることが伺えます。
https://www.databricks.com/blog/databricks-tabular

This acquisition highlights our commitment to open formats and open source data in the cloud, helping ensure that companies are in control of their data and free from the lock-in created by proprietary vendor-owned formats.

現状大きく異なる点はどこか？

Query Engines?

上記の記事によるとDelta lake は Apach Spark による操作が可能であるが、それ以外は対応していません。
しかし Iceberg は Spark, Trino, Flink からの操作が可能です。

下記にある様に Delta lakeはすでにあらゆる Frameworkと統合することを目指しています。
https://delta.io/integrations/
なので、例えばFlinkにはすでに Delta lakeに書き込む APIがドキュメント化されていました。 https://github.com/delta-io/delta/tree/master/connectors/flink
なのでInterfaceとしてはいくつかのツールを使えるのですが内部的にはSpark Engineがメインでデータを書き換えていることを理解しておいた方が良さそうです。

Unity Catalogの互換性

Delta lake はそもそも Databricks によって開発されており、その Databricks が作る Unity Catalog との互換性が高いです。
Unity Catalog 使ってみるとわかるのですが、データガバナンス・統合の観点においてかなり強力な仕組みであり、 Databricks の今後の虎の子 (Open Source化されていますが ) になっていくと考えています。この Unity Catalogの機能を活用していきたいなら、Delta lakeが選択肢が選択して有効だと考えています。
しかし、ここに Databricks が必要かと言われると未検証です、両方 Open Sourceですが、Databricks環境意外でこれらに触れたことがないので、今後検証していこうと思います。

また上記の２点はApach icebergと Delta lakeの共同開発者同士の対談動画でも触れられており、Unity Catalogの強みや Icebergの ファイル形式/処理エンジンの横断性についても触れられていました。

今後の展望を見るために歴史について触れる

Apach Icebergの歴史

https://www.datacamp.com/tutorial/apache-iceberg
まず Apach Icebergは 2017年にNetflixから始まり、翌年にApache Software Foundationに移譲されています。
その後2023年まで Communityも拡大しより協力なパフォーマンスを実現できるようになったあたりで、2024年Databricksによる、Iceberg創設者の立ち上げた会社Tabular社の買収という形でよりDatabricksと統合される形になりました。

Delta lakeの歴史

Delta lakeは Databricksが Lake house architecutureを提唱してきた時代から存在しています。 その後については別々のFrameworkではあるものの、Unity Catalogはこの延長上に位置する存在だと考えており、より高度なデータガバナンスを提供しようとしています。

Apach icebergと Delta lakeの共同開発者同士の対談動画から見る今後の展開

上記リンク先は Databricksのコンテンツなので会社のメールアドレスによる登録が必要ですが、必要なことはそれだけなのでぜひ見てみてください。
この動画のコンテンツの中で気になったことを抜粋してみます。

  • お互いに同じ様な苦労と課題が共通していたこと
  • お互いにデータフォーマットなど気にせずそれぞれがそれぞれのデータ活用に取り組んで欲しいと願っていること
  • 今 Iceberg を使うべきか Delta lakeを使うべきかに対する会話
  • Unity Catalog は 強力なデータガバナンスの仕組みである
  • Iceberg は Delta lakeを利用できない環境における 変換機能となる（この収録時点では？）
  • Uniformが重要である： 共通のAPIで必要とされるときにデータを取り出すことが可能であり、環境やフォーマットに依存しない
  • Demo: Databricks Delta Tableを Snowflakeから読み取る

また、最後のデモについては下記の記事がきっと同じことをなさっていて、とても参考になったので　ぜひ見てみてください。
https://qiita.com/manabian/items/7b1866cb98ce2539697a

僕がこの対談動画の中で素晴らしいと感じ、また今後のフォーマット剪定のキーのもなると感じたのはこの言葉です。

お互いにデータフォーマットなど気にせずそれぞれがそれぞれのデータ活用に取り組んで欲しい

また今後向かう先もこれに近いことが起きていくと思っています。

Delta Lake 3.0 の UniFormに見る今後の動き

https://www.databricks.com/blog/announcing-delta-lake-30-new-universal-format-and-liquid-clustering
2023年6月にrelaseされたDelta Lake 3.0ではDelta Universal Format (UniForm)の記述がありました。
これは single data source、一つのparquetファイルをベースにして、それに対する Iceberg (あとは Hudiも可能) からの読み取りを可能にするメタデータファイルを作成することで、両方のフォーマットによる読み取りを可能にするということです。

結論、どっちがいいのか Apach Iceberg と Delta lake

結論はそのうち統合されるからどっちでも大丈夫。
ただし、2025/4/30時点においては使っているプラットフォーム・フレームワーク、そのバージョンに従って標準を使っておけば良さそう。
お互いにいい形で統合される方向に見えるのはとても素晴らしいですね。
今はDatabricksがメインなので Icebergに触れる機会はあまりないのですが、両方の経過を見守っていこうと思います。

refference

Discussion