翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ストレージの最適化
<a name="best-practices-storage"></a>

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

![Iceberg テーブルのデータを更新または削除した結果](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/optimizing-storage.png)


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

## S3 Intelligent-Tiering を有効にする
<a name="storage-s3-intelligent-tiering"></a>

[Amazon S3 Intelligent-Tiering ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html)ストレージクラスを使用して、アクセスパターンが変化したときに最も費用対効果の高いアクセス階層にデータを自動的に移動します。このオプションは、運用上のオーバーヘッドやパフォーマンスへの影響はありません。 

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

[Amazon S3 ライフサイクルルール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を使用して、S3 Standard-IA や Amazon S3 S3 ストレージクラスにオブジェクトを移動するための独自のルールを設定することもできます (Amazon S3 ドキュメントの[「サポートされている移行と関連する制約](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html#lifecycle-general-considerations-transition-sc)」を参照）。

## 履歴スナップショットのアーカイブまたは削除
<a name="storage-snapshots"></a>

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

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

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


| **設計パターン** | **解決策** | **ユースケース** | 
| --- |--- |--- |
| **古いスナップショットを削除する** |   Athena の [VACUUM ステートメント](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html)を使用して、古いスナップショットを削除します。このオペレーションでは、コンピューティングコストは発生しません。    または、Amazon EMR で Spark または AWS Glue を使用してスナップショットを削除することもできます。詳細については、Iceberg ドキュメントの [expire\_snapshots](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) を参照してください。   | このアプローチでは、ストレージコストを削減するために不要になったスナップショットを削除します。データ保持要件に基づいて、保持するスナップショットの数または保持期間を設定できます。<br />このオプションは、スナップショットのハード削除を実行します。期限切れのスナップショットにロールバックしたり、タイムトラベルしたりすることはできません。 | 
| **特定のスナップショットの保持ポリシーを設定する** |   タグを使用して特定のスナップショットをマークし、Iceberg で保持ポリシーを定義します。詳細については、Iceberg ドキュメントの[「履歴タグ](https://iceberg.apache.org/docs/latest/branching/#historical-tags)」を参照してください。 <br />たとえば、Amazon EMR の Spark で次の SQL ステートメントを使用して、1 年間、1 か月あたり 1 つのスナップショットを保持できます。 <pre>ALTER TABLE glue_catalog.db.table <br />CREATE TAG 'EOM-01' AS OF VERSION 30 RETAIN 365 DAYS</pre>   Amazon EMR の Spark または AWS Glue を使用して、タグ付けされていない残りの中間スナップショットを削除します。   | このパターンは、過去の特定の時点でテーブルの状態を表示する必要があるビジネス要件または法的要件への準拠に役立ちます。特定のタグ付けされたスナップショットに保持ポリシーを配置することで、作成された他の (タグ付けされていない) スナップショットを削除できます。これにより、作成されたすべてのスナップショットを保持することなく、データ保持要件を満たすことができます。 | 
| **古いスナップショットのアーカイブ** |   Amazon S3 タグを使用して、Spark でオブジェクトをマークします。(Amazon S3 タグは Iceberg タグとは異なります。詳細については、[Iceberg ドキュメント](https://iceberg.apache.org/docs/latest/aws/#s3-tags)を参照してください）。例えば、次のようになります。 <pre>spark.sql.catalog.my_catalog.s3.delete-enabled=false and \<br />spark.sql.catalog.my_catalog.s3.delete.tags.my_key=to_archive</pre>   Amazon EMR で Spark または AWS Glue を使用してスナップショットを削除します。 [https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots)この例の設定を使用すると、この手順では、Amazon S3 から削除するのではなく、オブジェクトにタグを付け、Iceberg テーブルメタデータからデタッチします。   S3 ライフサイクルルールを使用して、 としてタグ付けされたオブジェクト`to_archive`を [S3 Glacier ストレージクラスの](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 1 つに移行します。   アーカイブされたデータをクエリするには:   [アーカイブされたオブジェクトを復元します](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects.html) (オブジェクトが Amazon Glacier Instant Retrieval ストレージクラスに移行された場合、このステップは必要ありません）。   Iceberg の [register\_table プロシージャ](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table)を使用して、スナップショットをカタログのテーブルとして登録します。    詳細な手順については、 AWS ブログ記事[「Amazon S3 データレイク上に構築された Apache Iceberg テーブルの運用効率の向上](https://aws.amazon.com/blogs/big-data/improve-operational-efficiencies-of-apache-iceberg-tables-built-on-amazon-s3-data-lakes/)」を参照してください。<br />  | このパターンにより、すべてのテーブルバージョンとスナップショットを低コストで維持できます。<br />アーカイブされたスナップショットをタイムトラベルまたはロールバックするには、まずそれらのバージョンを新しいテーブルとして復元する必要があります。これは通常、監査目的で許容されます。<br />このアプローチを以前の設計パターンと組み合わせて、特定のスナップショットの保持ポリシーを設定できます。 | 

## 孤立ファイルを削除する
<a name="storage-orphan-files"></a>

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

これらの削除を処理するには、Amazon Athena で [VACUUM ステートメント](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html)を使用できます。このステートメントはスナップショットを削除し、孤立したファイルも削除します。Athena はこのオペレーションのコンピューティングコストを請求しないため、これは非常にコスト効率的です。また、 `VACUUM`ステートメントを使用する場合、追加のオペレーションをスケジュールする必要はありません。

または、Amazon EMR または で Spark AWS Glue を使用して`remove_orphan_files`プロシージャを実行できます。このオペレーションにはコンピューティングコストがかかり、個別にスケジュールする必要があります。詳細については、[Iceberg](https://iceberg.apache.org/docs/latest/spark-procedures/#remove_orphan_files) ドキュメントを参照してください。