AWSは、Amazon S3 TablesサービスがApache Iceberg V3仕様に含まれるすべてのデータ型をサポートし、V3で新しいテーブルを作成したり、V2を基盤とする既存のテーブルをアップグレードしたりできるようになったと発表しました。この更新には、削除ベクトル（Deletion Vectors）、行系列（Row Lineage）、variant、nanosecond timestamp、geometry、geography、unknownのデータ型が含まれます。
これらの機能は、データレイク上で大規模なテーブルを管理する分析チームを対象としています。半構造化データ、地理座標、超高精度のタイムスタンプを文字列や整数として表現する代わりに、Icebergテーブル内でネイティブ型として保存でき、Amazon S3上では引き続きParquetファイルを使用できます。
実際には何が変わるのか？
削除ベクトルは、Iceberg V2で使用されていた位置指定削除ファイルを、圧縮されたバイナリ表現に置き換えます。AWSが示す例によると、20億行を含むテーブルから5万件のレコードを削除する場合、数千個の小さなファイルではなく1つの削除ベクトルファイルを生成できるため、ファイルの負荷と、その後の圧縮にかかる時間を削減できます。
行系列では、_row_idと_last_updated_sequence_numberの2つのフィールドが自動的に追加されます。後続の処理パイプラインは、毎回テーブル全体を検査する代わりに、シーケンス番号を使用して、以前のチェックポイント以降に変更された行を抽出できます。
variant型は半構造化データを列形式で保存するため、クエリエンジンは必要なフィールドを直接読み取り、統計情報を活用して入出力処理を削減できます。これにより、クエリのたびにJSONテキストを解析する必要がなくなります。また、Iceberg V3は地理空間データとナノ秒精度のタイムスタンプに対応するネイティブ型も提供します。
Iceberg V2からのアップグレード
既存のテーブルは、format-versionプロパティを3に変更することで、データを書き換えずにアトミックにアップグレードできます。V3への対応が環境内で完了するまで、V2リーダーはアップグレードされたテーブル上で引き続き動作します。一方、S3 Tablesは次回の圧縮サイクル中に古い削除ファイルを削除し、後続の最初のデータ変更時に行系列データの初期化を開始します。
ただし、このアップグレードは一方向です。Apache Iceberg仕様はV3からV2へのロールバックをサポートしていません。そのため、テーブルにアクセスするすべてのエンジンが新しいバージョンをサポートしていることを、事前に確認する必要があります。
互換性と制約
新しいデータ型を使用するには、Apache Spark 4.0以降を基盤とするエンジンが必要です。たとえば、AWS Glue 6.0以降、またはAmazon EMRバージョン8.1以降が該当します。また、これらの型はParquetを使用するテーブルに限定され、ORCやAvroでは利用できません。
variant、geometry、geographyの各列やナノ秒精度のタイムスタンプは、圧縮用のテーブル順序には使用できません。ただし、これらを含むテーブルでも、他の型の列に基づいて順序が設定されている場合は、引き続き圧縮可能です。S3 Tablesは圧縮とメンテナンスを自動的に管理し、Amazon S3コンソール、AWS CLI、またはIceberg REST Catalogインターフェースをサポートする任意のエンジンからのテーブル作成にも対応します。
この更新が重要な理由
この更新により、データチームは、大規模な削除、不規則なデータ、段階的な更新を扱う際に、カスタム変換への依存を減らす道筋を得られます。ただし、実際の利点は組織内のクエリエンジンと書き込みエンジンの準備状況に左右されます。アップグレードによってすべてのツールとの互換性が直ちに実現するわけではなく、新しい型の使用にはストレージ形式の制約があり、Sparkおよび関連サービスの特定のバージョンが必要です。
Apache Iceberg V3のサポートは、S3 TablesをサポートするすべてのAWSリージョンで利用可能になりました。今回の更新に固有の追加料金はなく、通常のS3 Tables料金が引き続き適用されます。