Amazon Athenaから利用時のGlueのIcebergテーブルのメンテナンスについて

2025/2/26にクラスメソッドデータ事業本部の部署内メンバー向けに発表したナレッジの共有資料になります。
Developers IOでのブログ公開用途も含めて作成しているので、Speaker Deckでも公開します。

1. 2025/2/26 鈴木那由太 Amazon Athenaから利用時の AWS GlueのIcebergテーブルの メンテナンスについて
2. AWS GlueのIcebergテーブル 2 Athenaからクエリできる、Iceberg形式のテーブルをデータカタログに作成できます。
3. Amazon Athenaから利用時のIcebergテーブルのメリット・注意点 3 メリット • S3をストレージに、データの変更・削除できる。 • タイムトラベルで過去断面のデータを確認できる。 • トランザクションでデータ変更の競合を防ぐことができる。 • データをほかのエンジンから参照できる。 注意点 • 定期的なファイルのメンテナンスが必要になる。 • ファイルの書き込み・読み取りの回数が増える。 （UPDATEはDELETE+INSERTの動きをするなど）
4. Amazon AthenaのIcebergのデータ更新戦略 4 • Amazon Athenaでは現状Merge-On-Readのみサポートしている。 • 読み取り性能はCopy-on-Writeより低くなる可能性はあるが、比較的低コストでの更新操作を実現している。 ※Working with Apache Iceberg tables by using Amazon Athena SQLより2 02 5 /2 /1 4に引 用 AthenaのIcebergのDMLサポート MoRのイメージ データファイル１ データファイル2 データファイル3 データファイル4 データファイル１ データファイル2 データ ファイル3 データファイル4 削除 ファイル3 削除前 削除後
5. メンテナンスコマンド 5 MoRのため、ファイル書き込みによってデータファイルが作成されていく。 そのままだとどんどん増えるため、不要ファイルを削除したり、細かいファイルをまとめる必要がある。 Amazon Athenaでは以下の２つのコマンドをサポートしている。 • VACUUM • 期限切れのスナップショットと孤立ファイルの削除を実行するコマンド • OPTIMIZE • テーブルに対する操作を繰り返すうちにできるデータファイルをまとめるためのコマンド VACUUMを実行しないと不要なファイルは削除されない。 OPTIMIZEを実行しないとファイルのコンパクションがされない。
6. メンテナンスコマンドに関係するテーブルプロパティ 6 テーブルプロパティ 説明 デフォルト値 vacuum_max_snapshot_age_seconds 古いスナップショットを削除するまでの時間 432,000 秒 (5 日間) vacuum_min_snapshots_to_keep 保持期間に含まれていないスナップショットを残す数 1 vacuum_max_metadata_files_to_keep 保持する古いメタデータファイルの数 100 テーブルプロパティ 説明 デフォルト値 optimize_rewrite_data_file_threshold これを超えたら最適化を実行するというデータファイル数のしきい値 5 optimize_rewrite_delete_file_threshold これを超えたら最適化を実行するという削除ファイル数のしきい値 2 https://docs.aws.amazon.com/ja_jp/athena/latest/ug/querying-iceberg-creating-tables.html#querying-iceberg-table-properties VACUUM OPTIMIZE メンテナンスコマンド実行時の挙動は以下のテーブルプロパティで制御できるため把握しておく。
7. S3上にできるデータ 7 https://iceberg.apache.org/spec/#overview
8. データレイヤー 8 データファイル 削除ファイル データファイル・削除ファイルの中身は以下のようなものとなっている。
9. メタデータレイヤー 9 • metadata fileにはスキーマ情報や各スナップショットごとにどのmanifest listを見ればよいかなどが 記載されている。作成されたデータファイル数・削除ファイル数なども書かれている。 • manifest listには各スナップショットで参照するmanifest fileが書かれており、manifest fileには具体的な データファイルの場所が書かれている。 https://iceberg.apache.org/spec/#overview metadata file manifest file manifest list
10. テーブルメタデータ 10 • テーブルメタデータを確認することで各スナップショットでレコードがどう推移したのか確認できる。 ◦ 直接メタデータレイヤーのファイルを確認してもよい。
11. UPDATEの注意点 11 • INSERT INTOとDELETEを組み合わせた動きをすることに注意する。 • SQLのロジックと捉えると「そうなんだな」くらいの話だが、S3上のオブジェクトの変化と 捉えると話が変わってくる。 • 全く同じデータでも、DELETEした際に削除ファイルが、INSERTした際に新しいデータファイルができる。 • 特にUPSERT時に課題となる。 S3 Standard S3 Standard UPDATE データファイル 削除ファイル データファイル データファイル
12. メンテナンス不足で発生しうる高額課金の例 12 • 日単位など比較的細かめのパーティション分割を設定している。 • MERGEするデータに広範囲のパーティションが含まれている。 • 定期的にUPDATEやMERGEなど更新操作を行っており、メンテナンスコマンドを 実行していない。 • 各パーティションに定期的に削除ファイル・データファイルが追加される。 • Athenaでの検索時に大量のファイル読み取りが行われる可能性がある。
13. メンテナンス不足で発生しうる高額課金の例 13 原因調査 • メタデータファイルの内容の確認 • S3上のファイル数の推移の確認 ◦ S3 Storage lensでバケットまたはパスごとのオブジェクト数の推移を確認する ◦ AWS CLIなどでファイル数を調べて確認する ◦ Cloud WatchメトリクスのNumberOfObjectsメトリクス（バケット単位のみ）を確認する 恒久対応 • メンテナンスコマンドの定期実行 • Glue Data Catalogのテーブル最適化機能の利用
14. Glue Data Catalogのテーブル最適化機能の利用 14 Glue Data Catalogから設定できる。 元々は圧縮のみだったが、不要ファイルの削除などもサポートした。