.compression-codec`。テーブルの全体的なパフォーマンスを向上させるには、ZSTD 圧縮コーデックを使用することをお勧めします。
デフォルトでは、Iceberg バージョン 1.3 以前では GZIP 圧縮が使用されており、ZSTD と比較して読み取り/書き込みのパフォーマンスが遅くなります。
注: エンジンによっては、異なるデフォルト値を使用する場合があります。これは、[Athena または Amazon EMR バージョン 7.x で作成された Iceberg テーブル](https://docs.aws.amazon.com/athena/latest/ug/compression-support-iceberg.html)の場合です。
## ソート順序を設定する
Iceberg テーブルの読み取りパフォーマンスを向上させるには、クエリフィルターで頻繁に使用される 1 つ以上の列に基づいてテーブルをソートすることをお勧めします。ソートと Iceberg の列統計を組み合わせると、ファイルプルーニングが大幅に効率化され、読み取り操作が高速化されます。また、ソートすると、クエリフィルターでソート列を使用するクエリの Amazon S3 リクエストの数も減ります。
Spark でデータ定義言語 (DDL) ステートメントを実行することで、テーブルレベルで階層ソート順序を設定できます。使用可能なオプションについては、[Iceberg のドキュメント](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table--write-ordered-by)を参照してください。ソート順序を設定すると、ライターはこのソートを Iceberg テーブルの後続のデータ書き込みオペレーションに適用します。
たとえば、ほとんどのクエリが でフィルタリングされる日付 (`yyyy-mm-dd`) でパーティション分割されたテーブルでは`uuid`、DDL オプションを使用して、Spark が重複しない範囲のファイルを書き込む`Write Distributed By Partition Locally Ordered`ようにできます。
次の図は、テーブルをソートしたときに列統計の効率がどのように向上するかを示しています。この例では、ソートされたテーブルは 1 つのファイルのみを開く必要があり、Iceberg のパーティションとファイルを最大限に活用できます。ソートされていないテーブルでは、任意の `uuid`が任意のデータファイルに存在する可能性があるため、クエリはすべてのデータファイルを開く必要があります。
![\[Iceberg テーブルでのソート順序の設定\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/setting-sort-order.png)
ソート順序を変更しても、既存のデータファイルには影響しません。Iceberg 圧縮を使用して、ソート順を適用できます。
次のグラフに示すように、Iceberg ソートテーブルを使用すると、ワークロードのコストを削減できます。
![\[Iceberg テーブルと Parquet テーブルの比較コスト\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cost-graph.png)
これらのグラフは、Iceberg ソートテーブルと比較した Hive (Parquet) テーブルの TPC-H ベンチマークを実行した結果をまとめたものです。ただし、結果は他のデータセットやワークロードで異なる場合があります。
![\[Parquet テーブルと Iceberg テーブルの TPC-H ベンチマークの結果\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/s3-api-calls.png)
# 書き込みパフォーマンスの最適化
このセクションでは、エンジンに関係なく Iceberg テーブルの書き込みパフォーマンスを最適化するために調整できるテーブルプロパティについて説明します。
## テーブル分散モードを設定する
Iceberg には、Spark タスク間での書き込みデータの分散方法を定義する複数の書き込み分散モードが用意されています。使用可能なモードの概要については、Iceberg ドキュメントの「[Writing Distribution Modes](https://iceberg.apache.org/docs/latest/spark-writes/#writing-distribution-modes)」を参照してください。
特にストリーミングワークロードで書き込み速度を優先するユースケースの場合は、 `write.distribution-mode`を に設定します`none`。これにより、Iceberg は追加の Spark シャッフルをリクエストせず、Spark タスクで使用できるようになるとデータが書き込まれます。このモードは、Spark 構造化ストリーミングアプリケーションに特に適しています。
**注記**
書き込み分散モードを に設定すると、多数の小さなファイルが生成される`none`傾向があり、読み取りパフォーマンスが低下します。これらの小さなファイルをクエリパフォーマンスのために適切なサイズのファイルに統合するには、定期的に圧縮することをお勧めします。
## 適切な更新戦略を選択する
読み取りmerge-on-read** **戦略を使用して、最新のデータに対する読み取りオペレーションの遅延がユースケースで許容できる場合に、書き込みパフォーマンスを最適化します。
merge-on-readを使用すると、Iceberg は更新を書き込み、個別の小さなファイルとしてストレージを削除します。テーブルが読み取られると、リーダーはこれらの変更をベースファイルとマージして、データの最新のビューを返す必要があります。これにより、読み取りオペレーションのパフォーマンスが低下しますが、更新と削除の書き込みが高速化されます。通常、merge-on-readは、更新を含むストリーミングワークロードや、多くのテーブルパーティションに分散される更新が少ないジョブに最適です。
merge-on-read設定 (`write.update.mode`、、および `write.merge.mode`) は、テーブルレベルで設定することも`write.delete.mode`、アプリケーション側で個別に設定することもできます。
merge-on-readを使用するには、読み込みパフォーマンスが時間の経過とともに低下するのを防ぐために、定期的な圧縮を実行する必要があります。圧縮は、更新と削除を既存のデータファイルと照合して新しいデータファイルセットを作成するため、読み取り側で発生するパフォーマンスのペナルティを排除します。デフォルトでは、プロパティのデフォルトをより`delete-file-threshold`小さい値に変更しない限り、Iceberg の圧縮は削除ファイルをマージしません ([Iceberg ドキュメント](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files)を参照）。圧縮の詳細については、このガイドの後半にある[「Iceberg 圧縮](best-practices-compaction.md)」セクションを参照してください。
## 適切なファイル形式を選択する
Iceberg は、Parquet、ORC、および Avro 形式のデータの書き込みをサポートしています。Parquet はデフォルトの形式です。Parquet と ORC は、優れた読み取りパフォーマンスを提供する列指向形式ですが、一般的に書き込みが遅くなります。これは、読み取りパフォーマンスと書き込みパフォーマンスの一般的なトレードオフを表します。
ストリーミングワークロードなど、ユースケースで書き込み速度が重要な場合は、ライターのオプション`Avro`で `write-format`を に設定して Avro 形式で書き込むことを検討してください。Avro は行ベースの形式であるため、書き込み時間が短縮され、読み取りパフォーマンスが低下します。
読み取りパフォーマンスを向上させるには、通常の圧縮を実行して小さな Avro ファイルをマージし、より大きな Parquet ファイルに変換します。圧縮プロセスの結果は、`write.format.default`テーブル設定によって管理されます。Iceberg のデフォルト形式は Parquet であるため、Avro で書き込み、圧縮を実行すると、Iceberg は Avro ファイルを Parquet ファイルに変換します。例を示します。
```
spark.sql(f"""
CREATE TABLE IF NOT EXISTS glue_catalog.{DB_NAME}.{TABLE_NAME} (
Col_1 float,
<<<…other columns…>>
ts timestamp)
USING iceberg
PARTITIONED BY (days(ts))
OPTIONS (
'format-version'='2',
write.format.default'=parquet)
""")
query = df \
.writeStream \
.format("iceberg") \
.option("write-format", "avro") \
.outputMode("append") \
.trigger(processingTime='60 seconds') \
.option("path", f"glue_catalog.{DB_NAME}.{TABLE_NAME}") \
.option("checkpointLocation", f"s3://{BUCKET_NAME}/checkpoints/iceberg/")
.start()
```
# ストレージの最適化
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 を有効にする
[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)」を参照）。
## 履歴スナップショットのアーカイブまたは削除
Iceberg テーブルへのコミットされたトランザクション (挿入、更新、マージ、圧縮) ごとに、テーブルの新しいバージョンまたはスナップショットが作成されます。時間の経過とともに、Amazon S3 のバージョン数とメタデータファイル数が累積されます。
スナップショットの分離、テーブルのロールバック、タイムトラベルクエリなどの機能には、テーブルのスナップショットを保持する必要があります。ただし、ストレージコストは、保持するバージョンの数に応じて増加します。
次の表は、データ保持要件に基づいてコストを管理するために実装できる設計パターンを示しています。
| **設計パターン** | **解決策** | **ユースケース** |
| --- |--- |--- |
| **古いスナップショットを削除する** | Athena の [VACUUM ステートメント](https://docs.aws.amazon.com/athena/latest/ug/vacuum-statement.html)を使用して、古いスナップショットを削除します。このオペレーションでは、コンピューティングコストは発生しません。 または、Amazon EMR で Spark または AWS Glue を使用してスナップショットを削除することもできます。詳細については、Iceberg ドキュメントの [expire\$1snapshots](https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots) を参照してください。 | このアプローチでは、ストレージコストを削減するために不要になったスナップショットを削除します。データ保持要件に基づいて、保持するスナップショットの数または保持期間を設定できます。このオプションは、スナップショットのハード削除を実行します。期限切れのスナップショットにロールバックしたり、タイムトラベルしたりすることはできません。 |
| **特定のスナップショットの保持ポリシーを設定する** | タグを使用して特定のスナップショットをマークし、Iceberg で保持ポリシーを定義します。詳細については、Iceberg ドキュメントの[「履歴タグ](https://iceberg.apache.org/docs/latest/branching/#historical-tags)」を参照してください。 たとえば、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 ドキュメント](https://iceberg.apache.org/docs/latest/aws/#s3-tags)を参照してください）。例えば、次のようになります。 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 を使用してスナップショットを削除します。 [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\$1table プロシージャ](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/)」を参照してください。 | このパターンにより、すべてのテーブルバージョンとスナップショットを低コストで維持できます。アーカイブされたスナップショットをタイムトラベルまたはロールバックするには、まずそれらのバージョンを新しいテーブルとして復元する必要があります。これは通常、監査目的で許容されます。このアプローチを以前の設計パターンと組み合わせて、特定のスナップショットの保持ポリシーを設定できます。 |
## 孤立ファイルを削除する
状況によっては、トランザクションをコミットする前に 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) ドキュメントを参照してください。
# 圧縮を使用したテーブルのメンテナンス
Iceberg には、[テーブルにデータを書き込んだ後にテーブルのメンテナンス操作](https://iceberg.apache.org/docs/latest/maintenance/)を実行できるようにする機能が含まれています。一部のメンテナンスオペレーションではメタデータファイルの合理化に重点を置いていますが、他のメンテナンスオペレーションでは、クエリエンジンがユーザーリクエストに応答するために必要な情報を効率的に見つけられるように、データのファイルのクラスター化方法を強化しています。このセクションでは、圧縮関連の最適化に焦点を当てます。
## Iceberg 圧縮
Iceberg では、圧縮を使用して 4 つのタスクを実行できます。
+ 小さなファイルを、通常 100 MB を超えるサイズの大きなファイルに結合します。この手法は*ビンパッキング*と呼ばれます。
+ 削除ファイルをデータファイルとマージします。削除ファイルは、merge-on-readアプローチを使用する更新または削除によって生成されます。
+ (再) クエリパターンに従ってデータをソートします。データは、ソート順なしで、または書き込みと更新に適したソート順で書き込むことができます。
+ スペースフィル曲線を使用してデータをクラスター化し、個別のクエリパターン、特に z 順序ソートを最適化します。
では AWS、Amazon Athena を介して、または Amazon EMR または で Spark を使用して、Iceberg のテーブル圧縮およびメンテナンスオペレーションを実行できます AWS Glue。
[rewrite\$1data\$1files](https://iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files) プロシージャを使用して圧縮を実行する場合、いくつかのつまみを調整して圧縮動作を制御できます。次の図は、ビンパッキングのデフォルトの動作を示しています。ビンパッキング圧縮を理解することは、階層ソートと Z 順序ソートの実装を理解する上で重要です。これらはビンパッキングインターフェイスの拡張であり、同様の方法で動作するためです。主な違いは、データのソートまたはクラスター化に必要な追加のステップです。
![\[Iceberg テーブルのデフォルトのビンパッキング動作\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/compaction.png)
この例では、Iceberg テーブルは 4 つのパーティションで構成されています。各パーティションのサイズとファイルの数は異なります。Spark アプリケーションを起動して圧縮を実行すると、アプリケーションは合計 4 つのファイルグループを作成して処理します。ファイルグループは、単一の Spark ジョブによって処理されるファイルのコレクションを表す Iceberg 抽象化です。つまり、圧縮を実行する Spark アプリケーションは、データを処理するための 4 つの Spark ジョブを作成します。
## 圧縮動作の調整
次のキープロパティは、圧縮のためにデータファイルを選択する方法を制御します。
+ [MAX\$1FILE\$1GROUP\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_FILE_GROUP_SIZE_BYTES) は、デフォルトで単一のファイルグループ (Spark ジョブ) のデータ制限を 100 GB に設定します。このプロパティは、パーティションのないテーブルや数百ギガバイトにまたがるパーティションを持つテーブルにとって特に重要です。この制限を設定することで、クラスターでのリソースの枯渇を防ぎながら、オペレーションを分割して作業を計画し、進行させることができます。
注: 各ファイルグループは個別にソートされます。したがって、パーティションレベルのソートを実行する場合は、パーティションサイズに合わせてこの制限を調整する必要があります。
+ [MIN\$1FILE\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_BYTES) または [MIN\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_FILE_SIZE_DEFAULT_RATIO) は、デフォルトでテーブルレベルで設定されたターゲットファイルサイズの 75% に設定されます。たとえば、テーブルのターゲットサイズが 512 MB の場合、384 MB 未満のファイルは圧縮されるファイルのセットに含まれます。
+ [MAX\$1FILE\$1SIZE\$1BYTES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_BYTES) または [MAX\$1FILE\$1SIZE\$1DEFAULT\$1RATIO](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MAX_FILE_SIZE_DEFAULT_RATIO) のデフォルトは、ターゲットファイルサイズの 180% です。最小ファイルサイズを設定する 2 つのプロパティと同様に、これらのプロパティは圧縮ジョブの候補ファイルを識別するために使用されます。
+ [MIN\$1INPUT\$1FILES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#MIN_INPUT_FILES) は、テーブルパーティションサイズがターゲットファイルサイズより小さい場合に圧縮するファイルの最小数を指定します。このプロパティの値は、ファイル数 (デフォルトは 5) に基づいてファイルを圧縮する価値があるかどうかを判断するために使用されます。
+ [DELETE\$1FILE\$1THRESHOLD](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/BinPackStrategy.html#DELETE_FILE_THRESHOLD) は、圧縮に含まれる前のファイルの削除オペレーションの最小数を指定します。特に指定しない限り、圧縮は削除ファイルとデータファイルを組み合わせません。この機能を有効にするには、このプロパティを使用してしきい値を設定する必要があります。このしきい値は個々のデータファイルに固有のため、3 に設定すると、それを参照する削除ファイルが 3 つ以上ある場合にのみ、データファイルが書き直されます。
これらのプロパティは、前の図のファイルグループの形成に関するインサイトを提供します。
たとえば、ラベルが付けられたパーティションには、100 GB の最大サイズ制約を超えているため、2 つのファイルグループ`month=01`が含まれています。対照的に、`month=02`パーティションには 100 GB 未満の単一のファイルグループが含まれています。`month=03` パーティションは、5 つのファイルのデフォルトの最小入力ファイル要件を満たしていません。その結果、圧縮されません。最後に、`month=04`パーティションには目的のサイズの単一のファイルを形成するのに十分なデータが含まれていませんが、パーティションには 5 つ以上の小さなファイルが含まれているため、ファイルは圧縮されます。
Amazon EMR または で実行されている Spark に対してこれらのパラメータを設定できます AWS Glue。Amazon Athena では、プレフィックス で始まる[テーブルプロパティを使用して、同様のプロパティ](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties)を管理できます`optimize_`)。
## Amazon EMR または で Spark を使用して圧縮を実行する AWS Glue
このセクションでは、Iceberg の圧縮ユーティリティを実行するために Spark クラスターを適切にサイズ設定する方法について説明します。次の例では Amazon EMR Serverless を使用していますが、EC2 または EKS 上の Amazon EMR、または で同じ方法を使用できます AWS Glue。
ファイルグループと Spark ジョブの相関関係を活用して、クラスターリソースを計画できます。ファイルグループを順番に処理するには、ファイルグループあたりの最大サイズ 100 GB を考慮して、次の [Spark プロパティ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults)を設定できます。
+ `spark.dynamicAllocation.enabled` = `FALSE`
+ `spark.executor.memory` = `20 GB`
+ `spark.executor.instances` = `5`
圧縮を高速化する場合は、並列に圧縮されるファイルグループの数を増やすことで、水平方向にスケールできます。手動または動的スケーリングを使用して Amazon EMR をスケーリングすることもできます。
+ **手動スケーリング** (4 倍など)
+ `MAX_CONCURRENT_FILE_GROUP_REWRITES` = `4` (係数)
+ `spark.executor.instances` = `5` (例で使用されている値) x `4` (係数) = `20`
+ `spark.dynamicAllocation.enabled` = `FALSE`
+ **動的スケーリング**
+ `spark.dynamicAllocation.enabled` = `TRUE `(デフォルト、アクション不要)
+ [MAX\$1CONCURRENT\$1FILE\$1GROUP\$1REWRITES](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#MAX_CONCURRENT_FILE_GROUP_REWRITES) = `N `(この値をデフォルトで 100 `spark.dynamicAllocation.maxExecutors`の に揃えます。例のエグゼキュター設定に基づいて、 `N` を 20 に設定できます)
これらは、クラスターのサイズ設定に役立つガイドラインです。ただし、Spark ジョブのパフォーマンスをモニタリングして、ワークロードに最適な設定を見つける必要もあります。
## Amazon Athena で圧縮を実行する
Athena は、[OPTIMIZE ステートメント](https://docs.aws.amazon.com/athena/latest/ug/optimize-statement.html)を通じて、マネージド機能として Iceberg の圧縮ユーティリティの実装を提供します。このステートメントを使用して、インフラストラクチャを評価することなく圧縮を実行できます。
このステートメントは、ビンパッキングアルゴリズムを使用して小さなファイルを大きなファイルにグループ化し、削除ファイルを既存のデータファイルとマージします。階層ソートまたは z 順序ソートを使用してデータをクラスター化するには、Amazon EMR または で Spark を使用します AWS Glue。
テーブル作成時の `OPTIMIZE`ステートメントのデフォルト動作は、 ステートメントでテーブルプロパティを渡すか、 `CREATE TABLE`ステートメントを使用してテーブル作成後に変更できます`ALTER TABLE`。デフォルト値については、[Athena のドキュメント](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties)を参照してください。
## 圧縮を実行するための推奨事項
| **ユースケース** | **レコメンデーション** |
| --- |--- |
| **スケジュールに基づいてビンパッキング圧縮を実行する** | テーブルに含まれる小さなファイル数がわからない場合は、Athena の `OPTIMIZE`ステートメントを使用します。Athena の料金モデルはスキャンされたデータに基づいているため、圧縮するファイルがない場合、これらのオペレーションに関連するコストは発生しません。Athena テーブルでタイムアウトが発生しないようにするには、`OPTIMIZE`per-table-partitionを実行します。 大量の小さなファイルが圧縮されると予想される場合は、Amazon EMR または を動的スケーリング AWS Glue で使用します。 |
| **イベントに基づいてビンパッキング圧縮を実行する** | 大量の小さなファイルが圧縮されると予想される場合は、Amazon EMR または を動的スケーリング AWS Glue で使用します。 |
| **圧縮を実行してデータをソートする** | ソートは高価な操作であり AWS Glue、データをディスクにスピルする必要がある可能性があるため、Amazon EMR または を使用します。 |
| **圧縮を実行して z 順序ソートを使用してデータをクラスター化する** | Amazon EMR または を使用します。z 順序ソートは非常に高価な操作であり AWS Glue、データをディスクにスピルする必要がある可能性があるためです。 |
| **遅延受信データが原因で他のアプリケーションによって更新される可能性のあるパーティションで圧縮を実行する** | Amazon EMR または を使用します AWS Glue。Iceberg [PARTIAL\$1PROGRESS\$1ENABLED](https://iceberg.apache.org/javadoc/1.2.0/org/apache/iceberg/actions/RewriteDataFiles.html#PARTIAL_PROGRESS_ENABLED) プロパティを有効にします。このオプションを使用すると、Iceberg は圧縮出力を複数のコミットに分割します。衝突がある場合 (つまり、圧縮の実行中にデータファイルが更新された場合）、この設定は、影響を受けるファイルを含むコミットに制限することで、再試行のコストを削減します。それ以外の場合は、すべてのファイルを再圧縮する必要がある場合があります。 |
| **コールドパーティション (アクティブな書き込みを受信しなくなったデータパーティション) で圧縮を実行する** | Amazon EMR または を使用します AWS Glue。`rewrite_data_files` プロシージャで、アクティブに書き込まれたパーティションを除外する`where`述語を指定します。この戦略は、ライターと圧縮ジョブ間のデータ競合を防ぎ、Iceberg が自動的に解決できるメタデータ競合のみを残します。 |
# Amazon S3 での Iceberg ワークロードの使用
このセクションでは、Iceberg の Amazon S3 とのやり取りを最適化するために使用できる Iceberg プロパティについて説明します。
## ホットパーティショニングの防止 (HTTP 503 エラー)
Amazon S3 で実行される一部のデータレイクアプリケーションは、数百万または数十億のオブジェクトを処理し、ペタバイトのデータを処理します。これにより、大量のトラフィックを受信するプレフィックスが発生する可能性があります。これは通常、HTTP 503 (サービス利用不可) エラーによって検出されます。この問題を回避するには、次の Iceberg プロパティを使用します。
+ Iceberg が大きなファイルを書き込む`range`ように `hash`または `write.distribution-mode`に設定すると、Amazon S3 リクエストが少なくなります。これは推奨される設定であり、ほとんどのケースに対応する必要があります。
+ ワークロード内の大量のデータが原因で 503 エラーが続く場合は、Iceberg `true`で `write.object-storage.enabled`を に設定できます。これにより、オブジェクト名をハッシュし、ランダム化された複数の Amazon S3 プレフィックスに負荷を分散するように Iceberg に指示します。
これらのプロパティの詳細については、Iceberg ドキュメントの[「プロパティの書き込み](https://iceberg.apache.org/docs/latest/configuration/#write-properties)」を参照してください。
## Iceberg メンテナンスオペレーションを使用して未使用のデータをリリースする
Iceberg テーブルを管理するには、Iceberg コア API、Iceberg クライアント (Spark など）、または Amazon Athena などのマネージドサービスを使用できます。Amazon S3 から古いファイルまたは未使用のファイルを削除するには、Iceberg ネイティブ APIs のみを使用して[、スナップショットの削除](https://iceberg.apache.org/docs/latest/maintenance/#expire-snapshots)、[古いメタデータファイルの削除](https://iceberg.apache.org/docs/latest/maintenance/#remove-old-metadata-files)、[孤立ファイルの削除](https://iceberg.apache.org/docs/latest/maintenance/#delete-orphan-files)を行うことをお勧めします。
Boto3、Amazon S3 SDK、または AWS Command Line Interface (AWS CLI) を介して Amazon S3 APIs を使用するか、Iceberg 以外の他のメソッドを使用して Iceberg テーブルの Amazon S3 ファイルを上書きまたは削除すると、テーブルの破損やクエリの失敗が発生します。
## 間でデータをレプリケートする AWS リージョン
Iceberg テーブルを Amazon S3 に保存する場合、[クロスリージョンレプリケーション (CRR)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) や[マルチリージョンアクセスポイント (MRAP)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html) などの Amazon S3 の組み込み機能を使用して、複数の にデータをレプリケートできます AWS リージョン。MRAP は、アプリケーションが複数の にある S3 バケットにアクセスするためのグローバルエンドポイントを提供します AWS リージョン。Iceberg は相対パスをサポートしていませんが、MRAP を使用してバケットをアクセスポイントにマッピングすることで Amazon S3 オペレーションを実行できます。MRAP は Amazon S3 クロスリージョンレプリケーションプロセスともシームレスに統合されるため、最大 15 分の遅延が発生します。データファイルとメタデータファイルの両方をレプリケートする必要があります。
**重要**
現在、Iceberg と MRAP の統合は Apache Spark でのみ機能します。セカンダリにフェイルオーバーする必要がある場合は AWS リージョン、フェイルオーバーリージョンの Spark SQL 環境 (Amazon EMR など) にユーザークエリをリダイレクトする計画を立てる必要があります。
CRR および MRAP 機能は、次の図に示すように、Iceberg テーブル用のクロスリージョンレプリケーションソリューションを構築するのに役立ちます。
![\[Iceberg テーブルのクロスリージョンレプリケーション\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/images/cross-region-replication.png)
このクロスリージョンレプリケーションアーキテクチャを設定するには:
1. MRAP の場所を使用してテーブルを作成します。これにより、Iceberg メタデータファイルは物理バケットの場所ではなく MRAP の場所を指します。
1. Amazon S3 MRAP を使用して Iceberg ファイルをレプリケートします。** **MRAP は、15 分のサービスレベルアグリーメント (SLA) でデータレプリケーションをサポートします。Iceberg は、レプリケーション中に読み取りオペレーションに不整合が生じるのを防ぎます。
1. テーブルをセカンダリリージョンの AWS Glue Data Catalog で使用可能にします。2 つのオプションから選択できます。
+ AWS Glue Data Catalog レプリケーションを使用して Iceberg テーブルメタデータをレプリケートするためのパイプラインを設定します。このユーティリティは、GitHub [Glue Catalog および Lake Formation Permissions レプリケーション](https://github.com/aws-samples/lake-formation-pemissions-sync)リポジトリで使用できます。このイベント駆動型メカニズムは、イベントログに基づいてターゲットリージョンのテーブルをレプリケートします。
+ フェイルオーバーする必要がある場合は、セカンダリリージョンにテーブルを登録します。このオプションでは、前のユーティリティまたは Iceberg [register\$1table プロシージャ](https://iceberg.apache.org/docs/latest/spark-procedures/#register_table)を使用して、最新の`metadata.json`ファイルを参照できます。