はじめに
こんにちは、アプリケーションサービス本部の三宅です！
Amazon S3 Tables の大きな魅力の一つが、自動でメンテナンスを行ってくれる点です。 しかし、メンテナンスといわれても、何をメンテナンスするのかよくわかっていませんでした。
例えば、S3 Tables の特徴として、次のような説明があります。
S3 Tables には Iceberg ワークロード固有の最適化が含まれており、汎用 S3 バケットに保存されている Iceberg テーブルと比較して、1 秒あたり最大 10 倍のトランザクションを配信できます。
表形式データの大規模ストレージ – Amazon S3 Tables – AWS
このような性能向上の裏側にあるのが、S3 Tables による自動メンテナンスです。 今回は、この「メンテナンス」について深堀りしていきます！
S3 Tables のメンテナンスとは
Amazon S3 Tables では、テーブルの状態を最適に保つためにバックグラウンドでメンテナンス処理が自動実行されます。
S3 Tables が自動で行うメンテナンス内容
- ファイルサイズの最適化
- 小さなデータファイルの統合
- スナップショットの自動削除
- 不要になったファイルのクリーンアップ
これらを人手で運用する必要がない、という点が S3 Tables の大きな強みです。
1. ファイルサイズ最適化（コンパクション戦略）
S3 Tables では、ファイルの圧縮方法として、いくつかの戦略を選択できます。
テーブルのメンテナンス - Amazon Simple Storage Service
auto（デフォルト）
- ソート順序が定義されていない場合は binpack 圧縮
- ソート順序が定義されている場合は sort 圧縮
binpack
binpack は、「小さなデータファイルをまとめて、適切なサイズのファイルに統合してくれる仕組み」です。
Amazon Athena でデータをクエリする場合、実は「理想的なファイルサイズ」が存在します。
Athena は、複数あるファイルに対して並列でクエリ処理してくれます。
データをそのまま書き込んでいくと、ファイルが細かく分割されすぎることがあり、クエリ性能が低下します。
binpack は、Athena の最もクエリが効率化されるファイルサイズに自動で分割してくれます。
sort
sort は、「指定したカラムの値が近いデータ同士を、同じファイルにまとめ直す仕組み」です。
binpack ではデータがランダムに配置されていましたが、sort コンパクションでは「値の並び」が考慮されて物理配置が最適化されます。
z-order
z-order は、「複数カラムを考慮してデータを整理し、ファイルをまとめ直す仕組み」です。
例えば、customer_id と product_id のような複数のカラムを考慮したい場合は、z-order を使います。
以下のような、複合条件でのクエリ性能の向上が期待できます。
SELECT * FROM orders WHERE customer_id = 'C123' AND product_id = 'P456';
binpack、sort、z-order どれを使えばいいか？
基本的には、binpack（デフォルト）を使うのがおすすめです。 binpack は、特定のクエリパターンを意識しなくても、ファイルサイズを適切に保ち、安定したクエリ性能を得られます。
特定のカラムでの絞り込みが多い場合（例：customer_id）には sort、複数のカラムを組み合わせた条件でクエリするケースが多い場合（例：customer_id、product_id）には z-order を選択すると効果が期待できます。
ただし、sort や z-order は binpack よりもコンパクションコストが高くなる点には注意が必要です。
2. スナップショットの自動削除
S3 Tables は、INSERT、UPDATE、DELETE といった操作のたびに、新しいスナップショットが作成されます。 スナップショットとは、ある時点のテーブル全体の状態を表したメタデータのことです。
テーブルのバージョン履歴のようなもので、そのスナップショットを参照することで、任意の時点にロールバックすることも可能です。
S3 Tables では、保存期間を過ぎたスナップショットを自動的に削除することで、メタデータの過剰な増加を防ぎます。
3. 不要になったファイルのクリーンアップ
Iceberg では、更新や削除を行うと、そのデータファイルがその場では消されるわけではありません。 もし更新や削除のたびにデータファイルを即座に削除してしまうと、過去のスナップショットへロールバックできなくなってしまいます。
そのため Iceberg では、どのスナップショットからも参照されていないファイルを「不要なファイル」と判断し、クリーンアップします。
料金について
S3 Tables の自動コンパクションは、次の 2 つの要素の合計で課金されます。
- 処理したファイル数：ファイル 1,000 個あたり USD 0.00185
- 処理したデータ量：
- binpack（デフォルト）→ 1GB あたり USD 0.005
- sort / z-order → 1GB あたり USD 0.01
汎用 S3 の Iceberg テーブルの最適化
汎用 S3 の Iceberg テーブルで同様のメンテナンスを行うには、AWS Glue の Optimizing Iceberg tables を使います。
まとめ
今回は、S3 Tables のメンテナンス機能について解説しました。
S3 Tables は、メンテナンスを自動で行ってくれるので便利ですね！
メンテナンスの実行スケジュールは指定できないみたいで、完全に AWS 任せになりそうです。
参考文献
https://pages.awscloud.com/rs/112-TZM-766/images/20250514_IcebergMeetup_S3tables.pdf
