ストレージの最適化

次の図に示すように、Iceberg テーブルのデータを更新または削除すると、データのコピー数が増加します。圧縮の実行にも同じことが当てはまります。Amazon S3 のデータコピーの数が増えます。これは、Iceberg がすべてのテーブルの基盤となるファイルをイミュータブルとして扱うためです。

このセクションのベストプラクティスに従って、ストレージコストを管理します。

S3 Intelligent-Tiering を有効にする

Amazon S3 Intelligent-Tiering ストレージクラスを使用すると、アクセスパターンが変更されたときに、最もコスト効率の高いアクセス階層にデータを自動的に移動できます。このオプションは運用上のオーバーヘッドやパフォーマンスへの影響はありません。 

注: Iceberg テーブルで S3 Intelligent-Tiering のオプション階層 (アーカイブアクセスやディープアーカイブアクセスなど) を使用しないでください。データをアーカイブするには、次のセクションのガイドラインを参照してください。

Amazon S3 ライフサイクルルールを使用して、S3 Standard-IA や Amazon S3 S3 ストレージクラスにオブジェクトを移動するための独自のルールを設定することもできます (Amazon S3 ドキュメントの「サポートされている移行と関連する制約」を参照）。 S3

履歴スナップショットのアーカイブまたは削除

Iceberg テーブルへのコミットされたトランザクション (挿入、更新、マージ、圧縮) ごとに、テーブルの新しいバージョンまたはスナップショットが作成されます。時間の経過とともに、Amazon S3 のバージョン数とメタデータファイル数が累積されます。

スナップショットの分離、テーブルのロールバック、タイムトラベルクエリなどの機能には、テーブルのスナップショットを保持する必要があります。ただし、ストレージコストは、保持するバージョンの数に応じて増加します。

次の表は、データ保持要件に基づいてコストを管理するために実装できる設計パターンを示しています。

設計パターン	解決策	ユースケース
古いスナップショットを削除する	Athena の VACUUM ステートメントを使用して、古いスナップショットを削除します。このオペレーションでは、コンピューティングコストは発生しません。 または、Amazon EMR で Spark または を使用してスナップショット AWS Glue を削除することもできます。詳細については、Iceberg ドキュメントの「endover_snapshots」を参照してください。	この方法では、ストレージコストを削減するために不要になったスナップショットが削除されます。データ保持要件に基づいて、保持するスナップショットの数または期間を設定できます。 このオプションは、スナップショットのハード削除を実行します。失効したスナップショットにロールバックしたり、タイムトラベルしたりすることはできません。
特定のスナップショットの保持ポリシーを設定する	タグを使用して特定のスナップショットをマークし、Iceberg で保持ポリシーを定義します。詳細については、Iceberg ドキュメントの「履歴タグ」を参照してください。 例えば、Amazon EMR の Spark で次の SQL ステートメントを使用して、1 年間、1 か月あたり 1 つのスナップショットを保持できます。 ALTER TABLE glue_catalog.db.table CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS Amazon EMR または で Spark AWS Glue を使用して、タグ付けされていない残りの中間スナップショットを削除します。	このパターンは、過去の特定の時点でテーブルの状態を表示する必要があるビジネス要件または法的要件への準拠に役立ちます。特定のタグ付けされたスナップショットに保持ポリシーを配置することで、作成された他の (タグ付けされていない) スナップショットを削除できます。これにより、作成されたすべてのスナップショットを保持することなく、データ保持要件を満たすことができます。
古いスナップショットのアーカイブ	Amazon S3 タグを使用して、Spark でオブジェクトをマークします。(Amazon S3 タグは Iceberg タグとは異なります。詳細については、「Iceberg ドキュメント」を参照してください。） 例: spark.sql.catalog.my_catalog.s3.delete-enabled=false and \ spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive Amazon EMR または で Spark AWS Glue を使用して、スナップショット を削除します。この例の設定を使用すると、この手順では、Amazon S3 から削除するのではなく、オブジェクトにタグを付けて Iceberg テーブルメタデータからデタッチします。 S3 ライフサイクルルールを使用して、 としてタグ付けされたオブジェクトto_archiveを S3 Glacier ストレージクラスの 1 つに移行します。 アーカイブされたデータをクエリするには： アーカイブされたオブジェクト を復元します。 Iceberg の register_table プロシージャを使用して、スナップショットをカタログのテーブルとして登録します。 詳細な手順については、 AWS ブログ記事Amazon S3 データレイク上に構築された Apache Iceberg テーブルの運用効率の向上」を参照してください。	このパターンでは、すべてのテーブルバージョンとスナップショットを低コストで維持できます。 最初にそれらのバージョンを新しいテーブルとして復元しない限り、アーカイブされたスナップショットにタイムトラベルまたはロールバックすることはできません。これは通常、監査目的で許容されます。 このアプローチを以前の設計パターンと組み合わせて、特定のスナップショットの保持ポリシーを設定できます。

孤立したファイルを削除する

状況によっては、トランザクションをコミットする前に Iceberg アプリケーションが失敗することがあります。これにより、データファイルは Amazon S3 に残ります。コミットがないため、これらのファイルはどのテーブルにも関連付けられないため、非同期的にクリーンアップする必要がある場合があります。

これらの削除を処理するには、Amazon Athena の VACUUM ステートメントを使用できます。このステートメントは、スナップショットを削除し、孤立したファイルも削除します。Athena はこのオペレーションのコンピューティングコストを請求しないため、これは非常にコスト効率的です。また、 VACUUMステートメントを使用する場合、追加のオペレーションをスケジュールする必要はありません。

または、Amazon EMR で Spark または を使用してremove_orphan_filesプロシージャ AWS Glue を実行できます。このオペレーションにはコンピューティングコストがかかり、個別にスケジュールする必要があります。詳細については、Iceberg ドキュメント を参照してください。