Amazon Athenaから利用する際のAWS GlueのIcebergテーブルについて、メンテナンスコマンドの必要性をまとめてみた
2025.03.03データ事業本部の鈴木です。
Icebergテーブルが非常に人気でこれから取り入れていきたい方がたくさんいらっしゃると思います。
メンバーからもよくIcebergテーブルを利用する際のポイントなど聞かれるのですが、S3上に作成されるIcebergのデータを実際にみて仕様と照らし合わせたり、運用を想定して利用してみて、どのようにS3上のファイルが変わるかじっくりみないとブラックボックスで使ってしまいがちです。
基本的には気軽に使って頂くのがよいと思うのですが、S3上にファイルが作成される性質上、メンテナンスコマンドに関しては共有しておいた方が安心だろうと思い、社内でナレッジの共有資料を作成・発表したため、こちらにも掲載します。
資料のご紹介
以下の資料となります。
ポイント
メンテナンスコマンドについて
VACCUMEとOPTIMIZEのコマンドを使って、不要なファイルの削除や小さいファイルをまとめる操作を定期的に行うことで、S3のコストパフォーマンスをよくできることを紹介しました。
例えばIcebergテーブルに対してAthenaで検索を実行した場合、S3からファイルを取得するAPIの課金が発生します。このとき、テーブルが参照するファイル数が多ければ多いほど課金も大きくなるため、小さくしておくに越したことはありません。
現時点でサポートされているメンテナンスコマンドに関するテーブルプロパティについてもまとめました。
MoRのデータ戦略について
Amazon AthenaではMoR（Merge-on-Read）のみサポートしているため、操作が行われるたびにデータファイル・削除ファイル含めて新しく作成されます。
特にUPDATEはDELETE + INSERTの動きをするため注意が必要です。データベース上で削除フラグがたつようなイメージですが、GlueのIcebergテーブルの場合はデータがS3上に作成されるため、削除ファイル作成 + データファイル作成と読み替えてイメージする必要があります。
テーブルのデータの構成について
メンテナンスコマンド実行のタイミングの調査やトラブル発生時の原因調査のため、Icebergテーブルの実体となる各種ファイルやメタデータの確認方法についても紹介しました。
実際にファイルの中身を確認し、Icebergの仕様書に記載の説明と見比べてもらうと面白いかなと思いますが、ファイルの中身まで解説してくださっている資料もあるため、確認して頂くと理解が早いと思います。
なお、Amazon Athenaからも一部メタデータをクエリできる機能があるため、以下のブログで紹介しています。
メンテナンス不足で問題となる例
テーブルで持っているファイル数が多くなる場合にはこまめに最適化しましょうということを紹介しました。
GlueのIcebergテーブルの場合、データの実体は汎用バケット上のファイルになることが重要で、メンテナンスコマンドを実行しないままファイル数が急激に増えていくような運用をしていると、読み取り時に段々と課金が大きくなっていく可能性があります。
メンテナンスコマンドの頻度は明示的に指定はされておらず、パフォーマンス低下しないように行う必要がありますが、このパフォーマンスは実行速度だけではなく、コストパフォーマンスも含まれていることを覚えておきましょう。
メンテナンスコマンドの定期実行はオーケストレーター側で単に定期実行するのでもよく、Glueのテーブル最適化の機能を使うこともできます。
最後に
AWS GlueのIcebergテーブルのメンテナンスコマンドに関するまとめでした。これからお使いになる方の参考になりましたら幸いです。
