翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 圧縮を使用したテーブルのメンテナンス
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 が自動的に解決できるメタデータ競合のみを残します。 |