圧縮を使用したテーブルのメンテナンス

Iceberg には、テーブルにデータを書き込んだ後にテーブルのメンテナンス操作を実行できるようにする機能が含まれています。一部のメンテナンスオペレーションではメタデータファイルの合理化に重点を置いていますが、他のメンテナンスオペレーションでは、クエリエンジンがユーザーリクエストに応答するために必要な情報を効率的に見つけられるように、データのファイルへのクラスター化方法を強化しています。このセクションでは、圧縮関連の最適化に焦点を当てます。

Iceberg 圧縮

Iceberg では、圧縮を使用して次の 4 つのタスクを実行できます。

• 小さなファイルを、通常 100 MB を超えるサイズの大きなファイルに結合します。この手法は、ビンパッキング と呼ばれます。

• 削除ファイルをデータファイルとマージします。削除ファイルは、 merge-on-read アプローチを使用する更新または削除によって生成されます。

• （再) クエリパターンに従ってデータをソートします。データは、ソート順なしで、または書き込みや更新に適したソート順で書き込むことができます。

• スペース塗りつぶし曲線を使用してデータをクラスター化し、個別のクエリパターン、特に z 順序ソートを最適化します。

では AWS、Amazon Athena を介して、または Amazon EMR または で Spark を使用して、Iceberg のテーブル圧縮およびメンテナンスオペレーションを実行できます AWS Glue。

rewrite_data_files プロシージャを使用して圧縮を実行すると、いくつかのつまみを調整して圧縮動作を制御できます。次の図は、ビンパッキングのデフォルトの動作を示しています。ビンパッキング圧縮を理解することは、階層ソートと Z 順序ソートの実装を理解する上で重要です。これらはビンパッキングインターフェイスの拡張であり、同様の方法で動作するためです。主な違いは、データのソートまたはクラスター化に必要な追加のステップです。

この例では、Iceberg テーブルは 4 つのパーティションで構成されています。各パーティションのサイズとファイル数は異なります。Spark アプリケーションを起動して圧縮を実行すると、アプリケーションは合計 4 つのファイルグループを作成して処理します。ファイルグループは、単一の Spark ジョブによって処理されるファイルのコレクションを表す Iceberg 抽象化です。つまり、圧縮を実行する Spark アプリケーションは、データを処理するための 4 つの Spark ジョブを作成します。

圧縮動作の調整

次のキープロパティは、圧縮のためにデータファイルを選択する方法を制御します。

• MAX_FILE_GROUP_SIZE_BYTES は、デフォルトで 1 つのファイルグループ (Spark ジョブ) のデータ制限を 100 GB に設定します。このプロパティは、パーティションのないテーブルや、数百ギガバイトにまたがるパーティションを持つテーブルにとって特に重要です。この制限を設定することで、クラスターでのリソースの枯渇を防ぎながら、作業を計画し、進行するためのオペレーションを分割できます。

  注: 各ファイルグループは個別にソートされます。したがって、パーティションレベルのソートを実行する場合は、パーティションサイズに合わせてこの制限を調整する必要があります。

• MIN_FILE_SIZE_BYTES または MIN_FILE_SIZE_DEFAULT_RATIO は、デフォルトでテーブルレベルで設定されたターゲットファイルサイズの 75% に設定されます。例えば、テーブルのターゲットサイズが 512 MB の場合、384 MB 未満のファイルは圧縮されるファイルのセットに含まれます。

• MAX_FILE_SIZE_BYTES または MAX_FILE_SIZE_DEFAULT_RATIO のデフォルトは、ターゲットファイルサイズの 180% です。最小ファイルサイズを設定する 2 つのプロパティと同様に、これらのプロパティは圧縮ジョブの候補ファイルを識別するために使用されます。

• MIN_INPUT_FILES は、テーブルパーティションサイズがターゲットファイルサイズよりも小さい場合に圧縮するファイルの最小数を指定します。このプロパティの値は、ファイル数 (デフォルトは 5) に基づいてファイルを圧縮する価値があるかどうかを決定するために使用されます。

• 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 では、プレフィックス で始まるテーブルプロパティを使用して、同様のプロパティを管理できますoptimize_）。

Amazon EMR または で Spark を使用して圧縮を実行する AWS Glue

このセクションでは、Iceberg の圧縮ユーティリティを実行するために Spark クラスターを適切にサイズ設定する方法について説明します。次の例では Amazon EMR Serverless を使用していますが、Amazon EC2 または Amazon EKS の Amazon EMR、または でも同じ方法を使用できます AWS Glue。

ファイルグループと Spark ジョブ間の相関関係を利用して、クラスターリソースを計画できます。ファイルグループを順番に処理するには、ファイルグループあたりの最大サイズを 100 GB にすることを考慮して、次の Spark プロパティ を設定できます。

• 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_CONCURRENT_FILE_GROUP_REWRITES = N （この値をデフォルトで 100 spark.dynamicAllocation.maxExecutorsの に調整します。この例のエグゼキュター設定に基づいて、 を 20 Nに設定できます）

  これらは、クラスターのサイズ設定に役立つガイドラインです。ただし、Spark ジョブのパフォーマンスをモニタリングして、ワークロードに最適な設定を見つける必要もあります。

Amazon Athena による圧縮の実行

Athena は、OPTIMIZE ステートメント を通じて Iceberg の圧縮ユーティリティをマネージド機能として実装します。このステートメントを使用して、インフラストラクチャを評価することなく圧縮を実行できます。

このステートメントは、ビンパッキングアルゴリズムを使用して小さなファイルを大きなファイルにグループ化し、削除ファイルを既存のデータファイルとマージします。階層ソートまたは z 順序ソートを使用してデータをクラスター化するには、Amazon EMR または で Spark を使用します AWS Glue。

テーブル作成時の OPTIMIZEステートメントのデフォルト動作は、 ステートメントにテーブルプロパティを渡すか、 CREATE TABLE ステートメントを使用してテーブル作成後に変更できますALTER TABLE。デフォルト値については、Athena のドキュメント「」を参照してください。

圧縮を実行するための推奨事項

ユースケース	レコメンデーション
スケジュールに基づいてビンパッキング圧縮を実行する	テーブルに含まれる小さなファイル数がわからない場合は、Athena の OPTIMIZEステートメントを使用します。Athena の料金モデルはスキャンされたデータに基づいているため、圧縮するファイルがない場合、これらのオペレーションに関連するコストは発生しません。Athena テーブルでタイムアウトが発生しないようにするには、 を per-table-partition ベースOPTIMIZEとして実行します。 大量の小さなファイルが圧縮される可能性がある場合は、Amazon EMR または を動的スケーリング AWS Glue で使用します。
イベントに基づいてビンパッキング圧縮を実行する	大量の小さなファイルが圧縮される可能性がある場合は、Amazon EMR または を動的スケーリング AWS Glue で使用します。
圧縮を実行してデータをソートする	ソートはコストがかかり AWS Glue、データをディスクにスピルする必要がある可能性があるため、Amazon EMR または を使用します。
z 順序ソートを使用して圧縮を実行してデータをクラスター化する	Amazon EMR または を使用します。z 順序ソートは非常にコストがかかり AWS Glue、データをディスクにスピルする必要がある可能性があるためです。
遅延受信データが原因で他のアプリケーションによって更新される可能性があるパーティションで圧縮を実行する	Amazon EMR または を使用します AWS Glue。Iceberg PARTIAL_PROGRESS_ENABLED プロパティを有効にします。このオプションを使用すると、Iceberg は圧縮出力を複数のコミットに分割します。衝突がある場合 (つまり、圧縮の実行中にデータファイルが更新された場合）、この設定は、影響を受けるファイルを含むコミットに制限することで再試行のコストを削減します。それ以外の場合は、すべてのファイルを再圧縮する必要がある場合があります。