オープンテーブルフォーマットの解説：Iceberg vs. Delta vs. Hudi

オープンテーブルフォーマットは、オブジェクトストレージ内のデータファイルの上層に位置するメタデータレイヤーであり、データレイクに保存されたデータにACIDトランザクション、スキーマの進化、タイムトラベル機能を追加します。現在、本番環境で使用されている主なオープンテーブルフォーマットはApache Iceberg、Delta Lake、Apache Hudiの3つであり、それぞれがParquetまたはORCファイルのコレクションを、データベースのように動作するテーブルに変換します。これにより、読み取り側（リーダー）は一貫した結果を得ることができ、書き込み側（ライター）は行を安全に更新および削除でき、すべての変更が追跡されるため、過去のバージョンもクエリ可能な状態に維持されます。

この概要では、主要なオープンテーブルフォーマットの仕組み、ACIDトランザクションのサポートとスキーマの進化における比較、そしてデータレイクハウスアーキテクチャとの関係について説明します。カタログ協調型トランザクション、行リネージ、統合メタデータといったストレージレイヤーのイノベーションを引き合いに出しながら、Delta LakeとApache Icebergがどのように融合しつつあるかを示します。

データレイクとは？なぜオープンテーブルフォーマットが重要なのか？

データレイクは、低コストのオブジェクトストレージ（Amazon S3、Azure Data Lake Storage、Google Cloud Storageなど）上に構築された中央リポジトリであり、構造化データ、半構造化データ、非構造化データを生のネイティブな形式で保持します。オブジェクトストレージは安価にスケールし、ストレージとコンピュートを分離できるため、任意のクエリエンジンが同じデータを読み取ることができます。企業がデータレイクを採用したのはこのためです。しかし、オブジェクトストレージは一貫性を保証するようには設計されていません。テーブル、スキーマ、トランザクションといったネイティブな概念は存在しないのです。

データレイクハウスは、その生のストレージにテーブルのような構造、ガバナンス、パフォーマンスを重ね合わせることで、データレイクの低コスト性とデータウェアハウスの信頼性を両立させます。この2つの架け橋となるのがオープンテーブルフォーマットです。データを独自のウェアハウスにコピーすることなく、オブジェクトストレージ内のバラバラなファイルを、管理されたクエリ可能なテーブルに変換します。

オープンテーブルフォーマットが登場する前は、従来のデータレイクで分析を実行すると、継続的な問題が発生していました。同時に書き込みを行うと書き込み途中でデータが破損する可能性があり、更新や削除を行うにはパーティション全体を書き換える必要がありました。また、どのファイルがテーブルの現在の正しい状態を表しているかを確実に知る方法もありませんでした。オープンテーブルフォーマットは、オブジェクトストレージ内のデータファイルのメタデータを管理し、どのファイルがテーブルに属しているかを正確に追跡します。この標準化により、データレイクはついにレコードレベルの更新といったデータベースのような機能をサポートできるようになりました。

知っておくべきオープンテーブルフォーマットとファイルフォーマット

Apache Iceberg

Apache Icebergは、もともとNetflixで開発され、現在はApacheソフトウェア財団のプロジェクトとなっており、巨大で更新頻度の低いテーブルを高速にクエリし、安全に進化させることができるように設計されています。Apache Icebergは、効率的なメタデータ管理のためにツリー構造を使用しています。マニフェストファイルとマニフェストリストがテーブル内のすべてのデータファイルを追跡するため、クエリエンジンはスキャンを開始する前に関連のないデータをプルーニング（除外）できます。Icebergテーブルは、基盤となるファイルを書き換えることなく、スキーマの進化とパーティションの進化をサポートします。

Delta Lake

Databricksによって開発され、オープンソースとしてリリースされたDelta Lakeは、ライトアヘッドトランザクションログを通じて、Apache SparkワークロードにACIDトランザクションをもたらしました。Delta LakeはDatabricksから誕生し、Sparkとネイティブに統合されていますが、現在は独立したコネクタを介して幅広いエンジンをサポートしています。Delta Lakeテーブルは、すべての書き込みを順序付けられたアトミックなログエントリとして記録するため、新しいデータが書き込まれている最中であっても、読み取り側に一貫したビューを提供します。

Apache Hudi

Apache Hudi（Hadoop Upserts Deletes and Incrementalsの略）は、高速かつ頻繁なレコードレベルの更新を中心に構築されています。Apache Hudiは、特定のレコードを保持する正確なファイルを特定するインデックスを維持することで、頻繁な更新とストリーミングデータ向けに最適化されており、フルテーブルスキャンを行うことなく効率的なレコードレベルの更新を可能にします。この設計により、Hudiは変更データキャプチャ（CDC）パイプラインやニアリアルタイムのインジェストによく選ばれています。

ParquetとORC

ParquetとORCは列指向ファイルフォーマットであり、テーブルフォーマットではありません。これらは個々のデータファイルがどのように構成されるかを定義するものであり、ファイルがどのように管理されたテーブルになるかを定義するものではありません。Iceberg、Delta Lake、HudiはいずれもParquetファイル（IcebergとHudiはORCもサポート）に基づいて構築されており、Parquetが保存するファイルレベルの統計情報を使用して、クエリエンジンがデータを読み取る前にデータをプルーニングします。ファイルフォーマットとテーブルフォーマットというこの区別を理解することで、各レイヤーの役割分担に関する企業の混乱の大部分が解消されます。

Iceberg、Delta Lake、Hudiのクイック比較

現在、3つの主要なオープンテーブルフォーマットは、異なる点よりも共通する機能の方が多いですが、以下の表は、設計の歴史が今なお色濃く残っている部分を示しています。

Apache Icebergの内部：テーブルとメタデータ

Icebergのメタデータツリー

Icebergテーブルは、単一のファイルではなくメタデータツリーによって定義されます。メタデータファイルはマニフェストリストを指し、マニフェストリストはスナップショットを構成する実際のデータファイルをリストしたマニフェストファイルを指します。この階層構造により、クエリエンジンはファイルを1つも開くことなく、保存されている列の統計情報を使用して関連のないマニフェストやデータファイルをプルーニングできるため、数百万のファイルを持つテーブルに対するクエリパフォーマンスが向上します。

スナップショットとタイムトラベル

Icebergテーブルへの書き込みごとに、新しいスナップショット（その時点でどのデータファイルが存在していたかを示す不変のレコード）が作成され、メタデータツリーは過去のスナップショットの履歴を保持します。これによりタイムトラベルが可能になります。エンジンは特定のスナップショットIDまたはタイムスタンプ時点のテーブルをクエリできるため、監査、再現可能なMLトレーニングセット、誤った書き込み後の最後の安定した状態へのロールバックなどがサポートされます。

パーティションの進化

Icebergは、パーティションの進化を通じてテーブルの物理的なパーティショニングをクエリパターンから切り離します。これにより、既存のファイルを書き換えたり、古いスキーマに対するクエリを破損したりすることなく、新しいデータのパーティショニング方法を変更できます。ヒドゥンパーティショニング（隠されたパーティショニング）により、アナリストはパーティションプルーニングを適用するために物理的なパーティション列を直接参照する必要がなくなります。

Icebergテーブルの内部とメンテナンス

書き込みのたびに独自のマニフェストリストを持つ新しいスナップショットが作成されるため、頻繁に書き込みが行われるIcebergテーブルを管理せずに放置すると、数千個の小さなマニフェストファイルやデータファイルが蓄積される可能性があります。クエリエンジンは依然として関連する各マニフェストファイルを開いて評価する必要があるため、マニフェストの無秩序な増加（スプロール）は、メタデータツリーがもたらすはずだったクエリパフォーマンスの向上効果を損なってしまいます。

標準的な解決策は、スケジュールされたコンパクションです。これは、小さなデータファイルをより少数の大きなファイルに書き換え、マニフェストを統合するメンテナンスジョブであり、インジェスト量に応じて夜間または時間単位で実行されます。コンパクションを定期的なスナップショットの有効期限切れ（保持期間を過ぎたメタデータの削除）と組み合わせることで、タイムトラベルで遡れる期間を制限することなく、ストレージとメタデータのサイズを管理可能な範囲に抑えることができます。

Delta LakeとACIDトランザクション

Delta Lakeのトランザクションログ

Delta Lakeテーブルは、すべての追加、削除、メタデータの変更を記録するJSONエントリのシーケンスである、順序付けられた追加専用のトランザクションログを、読み取りを高速化するためにログを要約する定期的なチェックポイントファイルとともに保存します。歴史的には、ファイルシステム自体がコミットコーディネーターとして機能していたため、ファイルレベルのアクセス権を持つクライアントであれば、管理カタログを経由せずにDeltaテーブルに直接書き込むことができました。

Delta LakeにおけるACIDトランザクションの動作

ACIDトランザクションは、すべての書き込み側に現在のログバージョンを確認させ、新しいエントリを生成し、その間に競合する変更が発生しなかった場合にのみコミットすることを要求することで、同時書き込み時のデータの一貫性を保証します。競合が検出された場合、書き込み側は再試行します。ACID準拠により、読み取り側が部分的に書き込まれた状態のDelta Lakeテーブルを見ることはなくなるため、データの破損が防止されます。また、ACIDトランザクションにより、重複するパーティション間での競合を発生させることなく、複雑なデータ操作を実行できます。

Sparkネイティブからマルチエンジンサポートへ

Delta Lakeの本来のコミットモデルはファイルシステムへのアクセスに依存していたため、Apache Spark以外のサードパーティ製エンジンは、管理カタログではなく静的なファイルパスを介してテーブルにアクセスする必要がありました。その結果、それらのアクセスは管理されず、スキーマの関係性が密かに損なわれる可能性がありました。Databricksは、Unity Catalogなどのカタログをコミットコーディネーターとして機能させるオープン標準である「カタログコミット」によってこの問題に対処しました。これにより、すべての読み取り、書き込み、検出の要求が中央で一元的に認可されます。カタログコミットは現在一般提供（GA）されており、Delta LakeをIcebergが当初から採用していたカタログ指向のアプローチに適合させ、複数テーブルのトランザクションを可能にしています。

ファイルフォーマットの基本：Parquetがデータスキップを可能にする仕組み

Parquetファイルは、表形式のデータを行ではなく列ごとに整理し、同じ列の値をローグループ（row group）と呼ばれる連続したブロックにグループ化します。列指向ストレージ（Columnar storage）により、クエリエンジンはクエリが参照する列のみを読み取り、残りをスキップできます。これが、スキャンの多いワークロードにおいてParquetが行指向フォーマットよりも優れたパフォーマンスを発揮する主な理由です。

すべてのローグループには、ファイルのメタデータフッターに書き込まれた、列ごとの最小値と最大値、null数、値の分布などの統計情報が含まれています。これらの統計情報により、エンジンはデータを解凍することなく、ローグループがクエリのフィルターに一致する可能性があるかどうかを判断できます。

オープンテーブルフォーマットは、この原則をさらに一歩進めています。IcebergのマニフェストファイルとDelta Lakeのトランザクションログは、どちらもメタデータレイヤーでParquetレベルの統計情報をキャッシュするため、エンジンはオブジェクトストレージからデータファイルをリストアップする前に、データファイル全体をスキップできます。この2段階のデータスキップは、大規模なテーブルにおけるクエリパフォーマンスの向上に大きく貢献しています。Databricksは、Variantデータ型（現在はParquet、Delta Lake、Icebergの一部）によってこのモデルを拡張しました。これにより、半構造化ペイロードが生のJSONではなく型付きバイナリ形式で保存されるため、エンジンは負荷の高いパース処理を行うことなく、ネストされたフィールドを抽出できます。

データのバージョニング、タイムトラベル、およびインクリメンタル処理

データのバージョニングとは、データをその場で上書きするのではなく、過去のすべてのテーブル状態の記録を保持するオープンテーブルフォーマットの機能です。タイムトラベルは、バージョン番号、スナップショットID、またはタイムスタンプによって、それらの過去のバージョンのいずれかを読み取ります。すべての書き込みが、個別に対処可能な新しいスナップショットまたはログエントリをすでに作成しているため、オープンテーブルフォーマットは設計上、データセットのタイムトラベルとバージョニングを可能にします。

インクリメンタル処理は、データセット全体を再スキャンするのではなく、テーブルが最後に処理されてから変更された行のみを読み取ります。これは、パイプラインがソーステーブルに適用された挿入、更新、削除のみを処理するChange Data Capture（CDC）の背景にあるパターンです。Delta Lakeに導入され、Iceberg v3を通じてIcebergにもたらされた行リネージ（row lineage）と削除ベクター（deletion vectors）により、これがより低コストになりました。行リネージはテーブルが最後にスキャンされてからどの行が変更されたかを追跡し、削除ベクターはデータファイルを書き換える代わりに対象の削除された行をコンパクトなビットマップとして表現します。

すべての履歴バージョンを無期限に保持することはコストがかかるため、オープンテーブルフォーマットは、バージョニングを保持ポリシー、および保持期間内に参照されなくなったデータを削除するvacuumまたはスナップショットの有効期限切れ操作と組み合わせます。vacuumを過度に頻繁に実行すると、古いバージョンをまだ参照しているタイムトラベルクエリが機能しなくなる可能性があるため、保持期間は、それを必要とする可能性のある最も実行時間の長いクエリに合わせて設定されます。

本番テーブルの合理的なケイデンス（頻度）は、取り込みに合わせた間隔（ストリーミングデータ取り込みの場合は通常5〜15分ごと）でのインクリメンタル処理と、クエリのピーク時間外に毎日実行されるvacuumおよびスナップショットの有効期限切れ処理を組み合わせることです。

メタデータ管理とパフォーマンスの最適化

オープンテーブルフォーマットは、レイヤー化されたメタデータ管理を通じてクエリパフォーマンスを向上させます。マニフェストファイルまたはログエントリは個々のデータファイルを記述し、スナップショットまたはログバージョンはある時点でのテーブル状態を記述し、カタログは現在どのバージョンが信頼できる情報源であるかを追跡します。Unity Catalogは、今日の企業導入全体で17エクサバイトを超えるオープンテーブルフォーマットのデータを管理しています。これは、最新のレイクハウスカタログが現在どれほど膨大なメタデータを管理しているかを示しています。

テーブルが大きくなると、マニフェストファイルやトランザクションログのチェックポイント自体がクエリプランニングを遅らせる可能性があるため、メンテナンスには、マニフェストをより少数の大きなファイルに書き換えることや、チェックポイントの間隔を書き込み頻度に合わせて調整することが含まれるべきです。Databricksとオープンソースコミュニティは、Delta LakeとIcebergにまたがる統合メタデータ構造を開発しており、第3四半期にプレビューが予定されています。これは、Delta Lakeの高速書き込みログとIcebergの高速読み取りマニフェストツリーを組み合わせたものです。

メタデータキャッシュ（最近アクセスされたマニフェスト、チェックポイント、またはカタログの応答をメモリに保持すること）は、リクエストごとにメタデータツリー全体をスキャンすることを避けることで、繰り返されるクエリのレイテンシーを削減します。これは、同じ大規模なテーブルに対して多数の小さなクエリを発行するBIワークロードにとって最も重要です。

ACIDトランザクションと同時実行制御

Apache Iceberg、Delta Lake、Apache Hudiはすべて、単一テーブルへの書き込みに対してシリアライザブルまたはスナップショット分離レベルを保証するため、同時に読み取りを行うユーザーは常に完全で一貫したバージョンを参照でき、部分的な書き込みを参照することはありません。異なるのは調整方法です。Icebergは常にカタログを信頼できる情報源（source of truth）として使用し、Hudiは独自のタイムラインサービスを使用し、Delta Lakeはカタログコミットによってカタログ調整モデルに統合される前はファイルシステムのアトミック性に依存していました。

3つのフォーマットはすべて、楽観的同時実行制御（optimistic concurrency control）を使用しています。書き込み前にテーブルをロックするのではなく、ライターが現在のバージョンを読み取り、変更を準備し、その間に他のライターが競合する変更をコミットしていない場合にのみコミットします。競合が検出された場合、トランザクションは安全に失敗し、新しいバージョンに対して再試行するか、アボート（中断）されるため、テーブルが一貫性のない状態のままになることはありません。

書き込みの競合を減らす最も効果的な方法は、同時書き込みを行うライター間の重複を減らすことです。異なるパイプラインが異なるパーティションに書き込むように取り込みジョブをパーティショニングし、小さな書き込みをまとめてより少数の大きなコミットにし、マージ操作の範囲を影響を受けるパーティションのみに限定します。カタログコミットもここで役立ちます。複数テーブルのトランザクションにより、関連する更新を複数のプロセスからの個別の書き込みとして競合させることなく、まとめてコミットできるためです。

データレイクに適したテーブルフォーマットの選択

Apache Icebergは、マルチエンジンでの読み取りアクセスが最も重要となる環境（Trino、Snowflake、Flink、Sparkから同じテーブルを並行してクエリする組織など）に最適です。Delta Lakeは、複数テーブルのトランザクションときめ細かなガバナンスを必要とする、Spark中心のパイプラインに最適です。Apache Hudiは、CDCレプリケーションなどの高頻度なレコードレベルのアップサート（upsert）ワークロードに最適であり、その専用のインデックス作成機能は一般的なマージ操作よりも優れたパフォーマンスを発揮します。

エンジンの互換性は、単なる機能リストではなく、すでに本番環境にあるクエリエンジンに照らして評価する必要があります。技術的に優れていても、チームの主要なエンジン向けの成熟したコネクタがないフォーマットは、リスクを軽減するどころか、むしろリスクを増やすことになります。JavaとRustのオープンソースライブラリであるDelta Kernelは、プロトコルを再実装することなくエンジンにDelta Lakeサポートを追加する一般的な方法となっています。これはすでにDuckDBやClickHouseの統合を支えており、これら2つの実装は共通のRustコアに収束しつつあります。

フォーマットを標準化する前に、代表的で、ある程度複雑な本番テーブルに対して概念実証（PoC）を実行してください。同時負荷下での書き込みレイテンシーを測定し、対象のエンジンが遅いコネクタ経由ではなくネイティブにそのフォーマットを読み取れることを確認し、スキーマエボリューション（スキーマ進化）とタイムトラベルが期待通りに動作することを検証します。

相互運用性、カタログ、およびベンダーに関する考慮事項

カタログの選択肢とクロスフォーマットの相互運用性

カタログは、どのテーブルが存在し、そのデータがどこにあり、どのスナップショットが信頼できるかを追跡する記録システムです。選択肢には、オリジナルのHive Metastore、AWS Glue Data Catalog、そしてDelta LakeとApache Icebergテーブルを1つのアクセス制御ポリシーの下でまとめて管理するUnity Catalogなどがあります。Delta Lake UniFormはさらに進んでおり、Delta Lakeデータの単一のコピーをストレージを複製することなくIcebergテーブルとしてネイティブに読み取れるようにします。これにより、チームが標準化を遅らせる原因となるフォーマットのロックインに関する懸念が解消されます。

ベンダーロックインのリスクとその軽減方法

ベンダーロックインのリスクを軽減する最も明確な方法は、複数の独立したエンジン実装を持つフォーマットを選択し、ファイルアクセスだけでなくカタログアクセスも、チームが将来必要とする可能性のあるプラットフォーム間でポータブルであることを確認することです。IcebergとDelta Lakeはオープンソースであるため、いずれかにデータを保存すること自体が組織を特定の処理エンジンにロックインすることはありませんが、その上に構築されるガバナンスレイヤーのポータビリティは異なる場合があります。

運用、モニタリング、およびベストプラクティス

テーブルのメンテナンスは、アドホックなタスクではなく、ランブック（手順書）として体系化する必要があります。どのテーブルにコンパクション（最適化）が必要か、どのファイルサイズをしきい値とするかを定義し、ジョブがどれだけ過去のデータをクエリするかに基づいてvacuumとスナップショット有効期限切れの保持期間を設定し、両方をクエリのピーク時間外にスケジュールします。

テーブルの健全性のモニタリングでは、テーブルごとのファイル数と平均ファイルサイズ、コミット失敗率、コンパクションスケジュールに対する最も古いデータファイルの経過時間を追跡し、小さなファイルの数や競合率が急増したときにアラートを通知する必要があります。これらのメトリクスは、メタデータの肥大化や書き込みの競合が、クエリの遅延として表面化する前にそれらを検知します。

オープンテーブルフォーマットは既存のクエリを壊すことなくスキーマエボリューション（スキーマ進化）をサポートするため、スキーマ変更は本番テーブルに直接適用されることがよくあります。しかし、その手軽さゆえにテストが省略されがちです。チームは、代表的なダウンストリームクエリに対して変更を検証し、以前のスナップショットへのロールバックを定期的にリハーサルしておく必要があります。これにより、不適切な変更からの復旧が、プレッシャーの下でのぶっつけ本番ではなく、慣れ親しんだ手順になります。

結論：オープンテーブルフォーマットのトレードオフと次のステップ

Apache Iceberg、Delta Lake、Apache Hudiは、安価なオブジェクトストレージに保存されたデータにACIDトランザクション、スキーマエボリューション、タイムトラベルをもたらすという、同じ核心的な課題を解決します。これらは、それぞれの出自（Icebergはマルチエンジン分析、Delta LakeはSparkネイティブパイプライン、Hudiは高頻度なアップサート）によって形成されたメタデータ設計を通じて実現されています。Parquetはこれら3つすべての基盤となる共通のファイルフォーマットであり、削除ベクター、行リネージ、Variant、カタログ調整コミットなどの最近のイノベーションは、個別に孤立するのではなく、フォーマット間で収束しつつあります。

ほとんどのチームにとって、現実的な次のステップは、範囲を絞った概念実証（PoC）です。既存のエンジンスタックに適合するフォーマットを選択し、実際の商用環境のデータ量でテストし、それを管理するカタログが将来的に第2のフォーマットにも拡張できることを確認します。Databricksのオープンでフォーマットに依存しないレイクハウスストレージを使用すると、データを一度保存するだけで、データを重複させたり特定のフォーマットにロックインされたりすることなく、Delta LakeまたはApache Icebergとしてネイティブにクエリを実行し、1つのカタログの下で一元管理できます。

オープンテーブルフォーマットに関するよくある質問

オープンテーブルフォーマットとは何ですか？

オープンテーブルフォーマットとは、オブジェクトストレージ内のデータファイルの上に位置するオープンソースのメタデータレイヤーであり、データレイクにデータベースのような機能（ACIDトランザクション、スキーマエボリューション、タイムトラベルなど）を追加するものです。現在実用化されている主なオープンテーブルフォーマットには、Apache Iceberg、Delta Lake、Apache Hudiの3つがあり、それぞれがParquetやORCファイルの集まりを、サポートされている任意のエンジンが安全に読み書きできるテーブルに変換します。

テーブルフォーマットとファイルフォーマットの違いは何ですか？

ParquetやORCなどのファイルフォーマットは、個々のデータファイルがディスク上でどのように圧縮され、整理されるかを定義します。一方、Apache IcebergやDelta Lakeなどのテーブルフォーマットは、それらの複数のファイルがどのように組み合わさって、一貫性のあるクエリ可能な1つのテーブルを構成するかを定義します。オープンテーブルフォーマットはファイルフォーマットの上に構築され、ファイルフォーマット単体では提供されないメタデータレイヤー（マニフェスト、トランザクションログ、カタログなど）を追加します。

Delta LakeとApache Icebergのテーブルは連携できますか？

はい、可能です。Delta Lake UniFormを使用すると、ストレージを重複させることなく、Delta Lakeテーブルデータの単一のコピーをApache Icebergテーブルとしてネイティブに読み取ることができます。また、Unity Catalogなどのカタログを使用すると、1つのアクセス制御ポリシーの下で両方のフォーマットを並行して管理できます。この相互運用性により、組織はすべてのエンジンに同じテーブルフォーマットを強制することなく、共通のガバナンスを標準化できます。

どのオープンテーブルフォーマットを選ぶべきですか？

最適なオープンテーブルフォーマットは、すでに稼働しているクエリエンジンやワークロードによって異なります。Apache IcebergはTrinoやSnowflakeなどのツールにまたがるマルチエンジン分析に適しており、Delta Lakeはマルチテーブルトランザクションを必要とするSpark中心のパイプラインに適しています。そしてApache Hudiは、CDCレプリケーションなどの高頻度なレコードレベルのアップサート（upsert）ワークロードに適しています。実際の商用データを使用した概念実証を行うことで、最適な選択肢を確認できます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事