ある企業のデータエンジニアは、Amazon S3 に Apache Iceberg テーブル形式でデータレイクを構築し、AWS Glue Data Catalog でテーブルを管理しています。先日、AWS Glue ETL ジョブの不具合により、重要なファクトテーブルのデータが誤って上書きされてしまいました。S3 バージョニングは有効ですが、Iceberg テーブルの論理的な整合性も保ちながら復旧したいと考えています。最も適切なデータ復旧方法はどれですか？
Apache Iceberg はスナップショットベースのバージョン管理を提供しており、CALL system.rollback_to_snapshot() や FOR SYSTEM_TIME AS OF を使ったタイムトラベルクエリで、テーブルを論理的に特定の過去状態へロールバックできます。メタデータ（マニフェストファイル、スナップショットファイル）ごと整合性を保って復旧できる点が強みです。 選択肢AのS3 バージョニングを使用して、上書き前のオブジェクトバージョンに手動でロールバックする方法は個々のオブジェクトファイルを復元できますが、Iceberg メタデータとの整合性は保証されないため、テーブルが壊れるリスクがあります。 選択肢CのAWS Backup を使用してS3 バケット全体を以前の復元ポイントに戻す方法はバケット全体を戻すと、他テーブルのデータにも影響が及ぶため、最小限のロールバックには不向きです。 選択肢DのAWS Glue ジョブブックマーク機能を使用して、上書き前の処理状態に戻す方法はGlue ジョブブックマークは増分ロードの処理状態を管理する機能であり、テーブルデータのロールバックには使用できません。