Apache Iceberg™ v3 ── エコシステム統合への大躍進

Apache Iceberg™ v3は、Apache Iceberg™コミュニティによって承認され、高度な新機能とデータ型を導入しています。Iceberg v3には、削除ベクトル、行リネージュ、半構造化データと地理空間用途向けの新しい型など、主要な改善が含まれています。これらの機能により、お客様は効率的にデータを処理・クエリできるようになります。さらに、これらの改善はDelta Lake、Apache Parquet、Apache Spark™間で一貫しているため、お客様はデータや行レベル削除ファイルを書き換えることなく、DeltaとApache Iceberg™間での相互運用が可能です。

このブログ記事では、Iceberg v3の最新の開発内容について説明します：

• 削除ベクトル
• 行リネージュ
• 半構造化データと地理空間型
• Delta Lake、Apache Parquet、Apache Spark間の相互運用性

削除ベクトル

Iceberg v3では、読み取りパフォーマンスを向上させるため、行レベル削除の新しい形式である削除ベクトルを導入しています。行レベル削除は、削除された行の保存と追跡方法を最適化することで書き込み増幅を大幅に削減し、ETLとインジェストの高速化につながります。Iceberg v2では、エンジンは書き込み時に削除ファイルを一緒にコンパクト化する必要がありませんでした。これは、お客様が非同期メンテナンスを使用することを意図していました。しかし、多くのお客様がメンテナンスサービスをスケジュールしなかったため、テーブルにメンテナンスされていない削除ファイルが多数存在することになりました。その結果、エンジンが読み取り時に多数の行レベル削除ファイルをマージしなければならず、読み取りパフォーマンスが低下していました。

Iceberg v3では、新しい削除ベクトル形式と削除ファイルに対する新しいコンパクト化要件を導入しています。この新形式により、Parquetファイルと削除を適用するために使用されるインメモリ表現間の変換が不要になります。さらに、エンジンは書き込み時にファイルごとに単一の削除ベクトルを維持する必要があります。この要件により、データファイルのパフォーマンスと統計が向上します。また、以前の削除と現在の削除を簡単に比較できるため、テーブルの行レベル変更をストリームとして処理することが簡素化されます。

行リネージュ

行リネージュ Iceberg v3のもう一つの主要機能は行リネージュで、これは増分処理を簡素化するために使用されます。行リネージュにより、エンジンはコミット間で行のバージョンを照合することで行レベルの変更を見つけることができます。

Iceberg v3では、行レベルのメタデータを使用した行リネージが導入されます。これには行IDと、その行が最後に変更または追加された際のシーケンス番号が含まれます。IDにより、バージョンを超えて同じ行を識別できます。シーケンス番号は、行が単にファイル間で移動されただけでなく、実際に最後に変更された時期を示します。これにより、エンジンは変更を選択的に処理でき、より高速で低コストなワークフローで下流の更新を簡素化できます。

行ID情報は、マテリアライズドビューなどの増分処理オブジェクトと組み合わせた場合に特に有効です。これらのオブジェクトは、前回の処理サイクル以降の新規データまたは変更されたデータのみを計算するよう最適化されています。

半構造化データと地理空間型

Iceberg v3は、半構造化データと地理空間データの新しいデータタイプも追加します。

半構造化データは、スキーマが変わるため、構造化されたテーブルの列に収まらないため、保存が難しいです。一つの回避策は、このデータから個々のフィールドを構造化された形式に抽出することです。しかし、これにより、スキーマの不一致により多くの列とNULL値が含まれる非常に広いテーブルが作成されます。別の選択肢として、JSONを文字列列に保存することも可能です。残念ながら、これにより読み取り性能が低下します。これは、エンジンがこれらの文字列からデータを解析する必要があるためです。半構造化データ型がないと、エンジンはフィルタを押し下げることができず、すべてのデータファイルのすべての行を読み取る必要があります。Iceberg v3では、半構造化データを効率的に表現するためにVARIANTが導入されました。VARIANTは、スキーマの柔軟性を維持しながらパフォーマンスを向上させるために、データの構造をエンコードします。

同様に、地理空間データ - 地球の表面上の場所、つまり道路、公園、市の境界などに関連する情報 - も効率的に作業し、クエリを効率的に行うのが難しいです。地理空間型がないため、顧客はバイナリ列を使用してジオデータの位置を保存する必要がありました。しかし、この表現は地理的な検索をサポートしていませんでした。なぜなら、バイナリ列は特定のエリア内のオブジェクトを見つけるためにフィルタリングすることができないからです。Iceberg v3は、この問題を新しいジオメトリと地理データ型を導入することで解決します。ジオメトリタイプは平面空間データ用で、地理タイプは地球の曲率を考慮したグローバルデータ用です。これらのタイプを使用すると、顧客は地理的な地域を表すバウンディングボックスを使用してデータを簡単に見つけ、地理空間オブジェクトを効率的に特定できます。

Delta Lake、Apache Parquet、Apache Spark^™との相互運用性

Iceberg v3の新機能とデータ型により、機能が拡張され、パフォーマンスが向上します。これらのApache Icebergの機能は、レイクハウス形式間の相互運用性を推進するという点でも重要です。

これまで、お客様は最も人気のある2つのレイクハウス形式、Delta LakeとApache Icebergのどちらかを選択せざるを得ませんでした。これは、ほとんどのプラットフォームが1つの形式しかサポートしていないためです。大規模なデータの書き換えはコストが高く現実的ではないため、この選択は長期的な決定となってしまいます。両形式は非常に似ており、どちらもParquetデータファイルの上にメタデータレイヤーを配置してテーブルセマンティクスを提供します。しかし、テーブル形式の小さな違いがお客様にとって問題となっていました。

Iceberg v3は、形式を超えてデータレイヤーを統合します。データ統合により、お客様はデータの書き換えやファイルの削除を行うことなく、DeltaとIcebergを相互運用できるようになります。これは、Iceberg v3の機能がDelta Lake、Apache Parquet、Apache Sparkで互換性のある実装を持っているためです：

• 削除ベクトルは、テーブル形式を超えて同じバイナリエンコーディングを使用
• Iceberg v3の行レベル系譜は、Delta Lakeの行トラッキングと互換性あり
• VARIANTとジオデータ型は、上流のApache ParquetとApache Spark™コミュニティで開発されており、Apache IcebergとDelta Lakeにも拡張される

オープンソースプロジェクト間で互換性のある機能を持つことで、Iceberg v3はお客様に形式の選択を強制することを回避します。代わりに、お客様は1つのデータコピー上で形式間を自由に相互運用できるようになります。

Iceberg v3についてもっと学ぶ

Iceberg v3は、業界全体をより高性能で機能豊富、そして相互運用性に優れた世界へと前進させます。私たちはIceberg v3をDatabricks Data Intelligence Platformに統合しており、他のベンダーもIceberg v3を採用することを期待しています。Databricksではオープンソースを重要な価値と位置づけており、削除ベクターなどの機能をIceberg v3に積極的に貢献しています。活発なオープンソースコミュニティを育成するため、Apache Icebergへの貢献を支援し、奨励しています。新しい貢献者の方には、まず「good first issue」から始めることをお勧めします。

私たちがIceberg v3の機能をマネージドテーブル製品にどのように統合する予定か、そしてオープンテーブルフォーマットの未来について詳しく知りたい方は、2025年6月9日〜12日開催のData and AI Summitにご登録ください。