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のもう1つの主要な機能は、増分処理を簡素化するために使用される行リネージです。行リネージを使用すると、エンジンはコミット間でバージョンの行を照合することにより、行レベルの変更を見つけます。

Iceberg v3では、行レベルのメタデータ（行IDと行が最後に変更または追加されたときのシーケンス番号）を使用して行リネージが導入されています。IDは、バージョン間で同じ行を識別します。シーケンス番号は、行が最後に変更された時期を注釈します（ファイル間で再配置されただけではありません）。これにより、エンジンは変更を選択的に処理できるようになり、より高速で安価なワークフローでダウンストリームの更新を簡素化できます。

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

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

Iceberg v3では、半構造化データと地理空間データ用の新しいデータ型も追加されています。

半構造化データは、構造化されたテーブル列に適合しないさまざまなスキーマを持っているため、保存が困難です。1つの回避策は、このデータから個々のフィールドを構造化された形式に抽出することです。ただし、これにより、スキーマの一貫性がないために、多くの列とNULL値を持つ非常に幅の広いテーブルが作成されます。もう1つの代替方法は、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の機能をマネージドテーブルオファリングに統合する方法、およびオープンテーブル形式の将来について学ぶには、6月9〜12日、2025年に開催されるData and AI Summitに登録してください。

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