# 考慮事項と制限事項
<a name="optimizer-notes"></a>

 このセクションでは、AWS Glue Data Catalog 内でテーブルオプティマイザーを使用する際に考慮すべき点について説明します。

## 耐久性と正確性
<a name="durability-correctness"></a>

**S3 テーブルロケーション:**

複数の AWS Glue Data Catalog テーブルが同じ Amazon S3 ロケーションを共有しており、オプティマイザが有効になっている場合、1 つのテーブルのスナップショット保持または孤立ファイル削除オプティマイザにより、別のテーブルによって現在も参照されているファイルが削除される可能性があります。オプティマイザが有効になっている各テーブルに、他のテーブル (異なるデータベースのテーブルを含む) と共有されていない一意の Amazon S3 ロケーションがあることを確認してください。

**S3 ライフサイクルの有効期限:**

Iceberg テーブルストレージロケーションに適用される Amazon S3 ライフサイクル有効期限ルールでは、アクティブなスナップショットによって現在も参照されているマニフェストファイルとデータファイルを削除できます。バケットにライフサイクル有効期限ルールがある場合は、Iceberg テーブルストレージパスが除外されることを確認してください。

## マネージドデータ圧縮でサポートされる形式と制限事項
<a name="compaction-notes"></a>

データ圧縮は、暗号化されたテーブルからのデータの読み取りなど、データの読み書きのためのさまざまなデータ型と圧縮形式をサポートしています。

**同時実行制御:**

 Apache Iceberg は楽観的同時実行制御をサポートしているため、複数のライターが同時にオペレーションを実行できます。競合はコミット時に検出され、解決されます。ストリーミングパイプラインを使用する場合は、テーブルプロパティと圧縮設定を使用して適切な再試行設定を行い、同時書き込みを効果的に処理します。詳細なガイダンスについては、[Iceberg テーブルでの同時書き込みの管理](https://aws.amazon.com/blogs/big-data/manage-concurrent-write-conflicts-in-apache-iceberg-on-the-aws-glue-data-catalog/)に関する AWS ビッグデータブログを参照してください。

**圧縮の再試行:**

 圧縮オペレーションが 4 回連続して失敗すると、不要なコンピューティングリソースの消費を防ぐため、AWS Glue カタログテーブルの最適化によってオプティマイザが自動的に一時停止されます。まずログを調べ、圧縮が繰り返し失敗する理由を見つけてみてください。圧縮の最適化を再開するには、AWS Glue コンソールまたは API を使用してオプティマイザを再度有効にします。

 **データ圧縮は以下をサポートします。**
+ **暗号化** - データ圧縮では、デフォルトの Amazon S3 暗号化 (SSE-S3) とサーバー側 KMS 暗号化 (SSE-KMS) のみがサポートされます。
+ **圧縮戦略** – ビンパック、ソート、Z オーダーソート
+ 基礎となるデータを保存する Amazon S3 バケットが別のアカウントにある場合、データカタログが存在するアカウントから圧縮を実行できます。これを実行するには、圧縮ロールが Amazon S3 バケットにアクセスできる必要があります。

 **データ圧縮は現在、次をサポートしていません。**
+ **クロスアカウントテーブルでの圧縮** - クロスアカウントテーブルでは圧縮を実行できません。
+ **クロスリージョンテーブルでの圧縮** - クロスリージョンテーブルでは圧縮を実行できません。
+ **リソースのリンクでの圧縮の有効化**
+ **Amazon S3 Express One Zone ストレージクラスのテーブル ** – Amazon S3 Express One Zone Iceberg テーブルでは圧縮を実行できません。
+ **Z オーダー圧縮戦略では、次のデータ型がサポートされていません:**
  + 10 進数
  + TimestampWithoutZone

## スナップショット保持と孤立ファイル削除オプティマイザに関する考慮事項
<a name="retention-notes"></a>

スナップショット保持と孤立ファイル削除のオプティマイザーには、次の考慮事項が適用されます。
+ スナップショットの保持と孤立ファイルの削除プロセスでは、実行ごとに最大 1,000,000 個のファイルを削除できます。期限切れのスナップショットを削除するときに、削除の対象となるファイルの数が 1,000,000 を超えると、そのしきい値を超える残りのファイルは、孤立ファイルとしてテーブルストレージに引き続き存在します。
+ スナップショットは、保持するスナップショットの最小数と指定された保持期間という両方の基準が満たされた場合にのみ、スナップショット保持オプティマイザによって保持されます。
+ スナップショット保持オプティマイザは、Apache Iceberg から期限切れのスナップショットメタデータを削除し、期限切れのスナップショットのタイムトラベルクエリを防ぎ、オプションで関連するデータファイルを削除します。
+  オーファンファイル削除オプティマイザは、作成時間がオプティマイザ実行時からオーファンファイル削除保持期間より前である場合、Iceberg メタデータによって参照されなくなった孤立したデータとメタデータファイルを削除します。
+ Apache Iceberg は、特定のスナップショット状態へのポインターという名前のブランチとタグを使用してバージョン管理を容易にします。各ブランチとタグは、それぞれのレベルで定義された保持ポリシーによって管理される、独自の独立したライフサイクルに従います。AWS Glue Data Catalog オプティマイザは、これらのライフサイクルポリシーを考慮し、指定された保持ルールを確実に遵守します。ブランチおよびタグレベルの保持ポリシーは、オプティマイザ設定よりも優先されます。

   詳細については、Apache Iceberg のドキュメントの「[分岐とタグ付け](https://iceberg.apache.org/docs/nightly/branching/)」を参照してください。
+ スナップショット保持と孤立ファイル削除オプティマイザは、設定されたパラメータに従ってクリーンアップの対象となるファイルを削除します。適切なバケットに S3 バージョニングポリシーとライフサイクルポリシーを実装することで、ファイル削除の制御を強化します。

   バージョニングの設定とライフサイクルルールの作成に関する詳細な手順については、「[https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)」を参照してください。
+  孤立ファイルについて適切な判断を行うには、指定されたテーブルの場所とサブパスが他のテーブルやデータソースと重複したり、他のテーブルやデータソースのデータを含んでいないことを確認してください。パスが重複すると、ファイルの意図しない削除によって回復不可能なデータ損失が発生する可能性があります。

## OversizedAllocationException 例外のデバッグ
<a name="debug-exception"></a>

`OversizedAllocationException` 例外を解決するには：
+ ベクトル化されたリーダーのバッチサイズを減らして確認します。デフォルトバッチサイズは 5000 です。これは `read.parquet.vectorization.batch-size` で制御されます。
  + 複数のバリエーションがあってもこれが機能しない場合は、ベクトル化をオフにします。これは `read.parquet.vectorization.enabled` で制御されます。