先日読んだ Snowflake の記事に Iceberg 連携の話があったので、自分の学習も兼ねてデータレイクに使われる新しいデータフォーマットについていくつか記事を紹介します：
先日の記事： bynatures.hatenadiary.jp
"AWSにおける Hudi/Iceberg/Delta Lake の使いどころと違いについて"
AWS のソリューションアーキテクト、Chie Hayashida さんによる各種データフォーマット比較です。
CSV, JSON, AVRO, Parquet, ORC などのファイルフォーマットや様々なユースケースを紹介しながら、新たなデータレイクフォーマットの必要性と、Apache Hudi, Iceberg, Delta Lake の3つのフォーマットを紹介しています。資料の最後には、これらのフォーマットをいつ使うべきかもまとめられていたり、AWS のどのサービスで利用可能かもまとめられており、貴重な資料です。
"Delta vs Iceberg vs hudi : Reassessing Performance"
Delta Lake, Iceberg, Hudi のパフォーマンス比較記事。データウェアハウス用のベンチマーク指標 TPC-DS を用いて検証をしています。
大きく分けてデータロード、クエリ実行時間の2パートに分かれていますが、Hudi のデータロード（ベンチマーク用の 3.0 TB Parquet ファイルを読み込む時間）が Delta Lake, Iceberg に比べて遅くなっている点が目立ちます。クエリ実行は Delta Lake が早く、クエリ実行時間が短いものは Hudi が早かったケースが多いようです。
ロード、クエリ実行時間共に Delta Lake フォーマットの性能の良さが目立つ検証内容でした。Delta Lake は Databricks 社にとっても重要な技術であり、今後も注力して改善や機能追加が行われるのではないかと思います。
"Comparison of Data Lake Table Formats (Apache Iceberg, Apache Hudi and Delta Lake)"
Dremio 社の技術ブログで、Iceberg, Hudi, Delta Lake の3フォーマットの紹介／比較を行っています。3つのフォーマットを ACID特性、パーティション変更、スキーマ変更、タイムトラベル、管理体制、どんなツールで利用可能かなどが詳細に比較されています。ざっと調べた限り、このブログが一番細かく比較されていて、定期的に情報も更新されているようです。
パーティションの変更は唯一 Iceberge がもつ機能で、既存のテーブルに対して、タイムスタンプ ts による年ごとのパーティションが区切られている場合、月ごとのパーティションを追加するのは Iceberg が提供する SQL を実行するだけで行えます。パーティションを切る場合、多くは時刻や日付によって行われるでしょうし、この粒度をテーブル作成後に変更できるのはとても便利そうです。
管理体制については Delta Lake がほぼ Databricks 社によって更新されていることが目につきます。Delta Lake はオープンソース版と Databricks 社が独自に開発を続けるバージョン（フォーク）の2つがありますが、Iceberg は Netflix, Apple, AWS などを中心に様々な企業が開発に加わっており、これと比べると開発の盛り上がりは欠けている印象を受けました。しかし Delta Lake フォーマットは Databricks 社製品としても重要な製品であるため、今後も Databricks 社によって開発は続けられるだろうと思います。
このブログを投稿した Dremio という会社は、セルフサービス SQL 分析を実現するオープン・データレイクハウスを提供しています。様々なデータソースを統合し（レイクハウス）、統合されたデータに対して SQL を中心としたインタフェースでデータ分析ができるサービスのようです。…と書きましたが、機能が豊富で正直よく分かっていません。ドキュメントを見る限りはデータ自体は移動せず、クラウドサービスやオンプレミスのデータソースをまとめ上げる複数データレイク上でのクエリエンジン＋αのように見えます（詳しい方がいたら教えてください）。上記ブログは Dremio が上記テーブルフォーマットのどれが利用可能か（Iceberg と Delta Lakeに対応）を紹介することが目的のようです。
