[アップデート]S3メタデータテーブルはジャーナルテーブルに改名し、新たにライブインベントリテーブルが誕生、既存オブジェクトとメタデータを一覧化できるようになりました
はじめに
こんにちは、データ事業本部の渡部です。
2025/07/16の本日で、S3メタデータのアップデートが公開されていました。
従来のS3メタデータテーブルは「ジャーナルテーブル」と改名し、新たにS3メタデータ管理をするテーブルとして「ライブインベントリテーブル」が誕生したとのことです。
従来のメタデータテーブルは、S3メタデータを有効後のオブジェクトのメタデータの変更履歴のみ収集できたのですが、ライブインベントリテーブルは既存のオブジェクトのメタデータもバックフィルで(巻き戻って)一覧として収集できるようです。
早速試してみようと思います!
変更点まとめ
- S3メタデータは「ジャーナルテーブル」と「ライブイベントリテーブル」の2つの構成になりました。
- 従来のメタデータテーブルはジャーナルテーブルとなり、バケット内のオブジェクトの変更履歴をほぼリアルタイムで管理します。
- 新しく誕生したライブインベントリテーブルは、バケット内のオブジェクトとそのメタデータ一覧を通常1時間以内で変更反映、管理します(名前のとおり S3インベントリのLIVEなテーブル という認識です)。
- 上記メタデータテーブルの管理はAWSマネージドのテーブルバケットになりました。
- ジャーナルテーブルのレコードの有効期限を設定できるようになりました。
- ジャーナルテーブルにかかる料金が33%オフになりました。
生まれ変わったS3メタデータを試す
前準備としてS3汎用バケットとテーブルバケットを作成します。
汎用バケットには画像を配置し、テーブルバケットはメタデータテーブルを管理します。
なお後ほど気づいたのですが、テーブルバケットの用意は不要でした。
aws s3 mb s3://cm-watanabe-metadata-20250716 \
--region us-east-1 \
# ※テーブルバケット作成は不要
aws s3tables create-table-bucket \
--name cm-watanabe-table-bucket-20250716 \
--region us-east-1 \
ファイル配置します。
clanyan3.jpgのみユーザー定義メタデータを付与してません。
aws s3 cp ./clanyan1.jpg s3://cm-watanabe-metadata-20250716 \
--metadata '{"location":"hibiya"}' \
aws s3 cp ./clanyan2.jpg s3://cm-watanabe-metadata-20250716 \
--metadata '{"location":"osaka"}' \
aws s3 cp ./clanyan3.jpg s3://cm-watanabe-metadata-20250716 \
S3バケットは作成され、画像も配置されています。
早速メタデータ設定を作成していきましょう。
メタデータ
タブ > メタデータ設定を作成
の順でクリックします。
こちらが新しいメタデータ設定の作成画面です。
ジャーナルテーブル
とライブインベントリテーブル
と表示されていますね。
ジャーナルテーブル
は従来のメタデータテーブルですが、新機能としてレコードの有効期限
が設定可能になっています。
これまで変更履歴が積み上がっていくようになっていたのが、7~2147483647(2³¹ - 1)と任意の日数で履歴行の削除がサポートされました。
そしてこの時になって気づいたのですが、メタデータテーブル用の送信先が マネージドテーブルバケット となっていました。
従来はテーブルバケットを用意していたのですが、今回のアップデートでAWSマネージドとなったようです!
テーブルバケットを用意しなくてもいいので嬉しいですね。S3メタデータのテーブルはすべて同一のS3TablesCatalogに含まれる ということだと思います。
ライブインベントリテーブル
も有効にして、メタデータ設定を作成します。
ジャーナルテーブルは数分、ライブインベントリテーブルはバックフィル(メタデータの収集)に時間がかかって20分で設定が完了しました。
Athenaで確認しようと思ってAthenaでテーブルのクエリを実行
をクリックするとテンプレートが選べました。
まずはジャーナルテーブル
に対してクエリをします。
しかし・・・エラーになりました。
"Insufficient permissions to execute the query. Principal does not have any privilege on specified resource"
私は最近訓練されてきており、この手のS3 Tablesが絡んだエラーはまずLake Formationが関係していそうだと予測できたので、Lake FormationのData Permissionsでクエリを実行するプリンシパルに対して、ジャーナルテーブル・ライブインベントリテーブルへのSUPER権限を与えました。
再度Athenaでクエリを実行すると、成功しました(画像撮り忘れ)。
結果は0件ですが、ジャーナルテーブルは変更履歴を持つテーブルで従来のS3メタデータテーブルと機能は変わらないので、問題はありません。
ジャーナルテーブルのテーブルスキーマは以下をご参考ください。
オブジェクトに対する変更履歴がわかるスキーマ構造となっていますね。
追加でオブジェクトを配置すると、ジャーナルテーブルにrecord_type = CREATEでオブジェクト作成した履歴が記録されました。
aws s3 cp ./clanyan4.jpg s3://cm-watanabe-metadata-20250716 \
--metadata '{"location":"okinawa"}' \
続いてライブインベントリテーブルを確認します。
ジャーナルテーブルと同じようにクエリをすると、メタデータ設定有効前のメタデータが出力されました!
ライブインベントリテーブルのテーブルスキーマは以下をご参考ください。
バケット内のオブジェクトとメタデータの一覧がわかるようなスキーマ構造ですね。
例えばですが、以下のクエリで任意のユーザー定義のメタデータが付与されていないオブジェクトの特定も可能です。
SELECT * FROM "inventory" WHERE user_metadata['location'] is null;
なおIcebergテーブルなので、タイムトラベルもできるかなと思ったのですが、現状できませんでした。
さいごに
いかがでしたでしょうか。
新たに生まれ変わったS3メタデータで、より非構造データの検索性が担保できるようになるのではないでしょうか。
S3メタデータで単純にタグがついていないオブジェクトの検知に使用したり、
これは私の妄想ですが、同日に発表されたS3 Vectorsのベクトル情報とメタデータのファイルパスを結合させることによって、自然言語で問い合わせをしてファイルの特定・ダウンロードまでいけないかと想像しています。
2025/07/16は様々なアップデートがあり、面白いですね。
以上、どなたかのご参考になれば幸いです。
こちらも読みたい