はじめに
本記事は、ラスベガスで行われているAWS re:Invent 2025の参加レポートです。
現地の12/04(木)に行われた、Amazon S3 TablesとAmazon SageMakerを使用したデータレイクの運用に関するChalk Talkセッション (STG413) に参加したレポートです。
ポイント
このセッションのポイントです。
- フルマネージドなIcebergストア: S3 Tablesは「テーブルバケット」という概念を導入し、Icebergテーブルの運用管理(コンパクション、スナップショット管理、不要ファイル削除)をAWSにオフロードできます。
- 柔軟な統合: Apache Iceberg REST Catalog (IRC) 互換のエンドポイントを提供し、AthenaやRedshiftなどのAWSサービスだけでなく、SnowflakeやSparkなどのサードパーティツールからも利用可能です。
- SageMaker Unified Studioとの連携: データエンジニアやデータサイエンティストが、統合された環境でシームレスにデータを探索・クエリ・活用できるフローが強化されています。
- コストとパフォーマンスの最適化: データの特性(Bronze/Silver/Gold)に応じて、適切なコンパクション戦略(Bin Packing, Sort, Z-order)を選択することで、コストとパフォーマンスを両立できます。
セッションについて
タイトル
Building an operational data lake using S3 Tables and SageMaker [REPEAT] (STG413-R1)
概要
Amazon S3 Tablesは、Apache Icebergテーブル向けに最適化された新しいS3の機能です。
このセッションでは、S3 Tablesを使用して運用データレイクを構築する方法について解説されました。
従来のデータレイク構築における課題(パフォーマンス、セキュリティ、ガバナンス、コスト最適化)に対し、S3 Tablesがどのようにソリューションを提供するかを紹介します。
具体的には、S3 Tablesの基礎、自動メンテナンス機能(コンパクション、スナップショット管理)、セキュリティモデル、そしてAmazon SageMaker Unified Studioを含むAWS分析サービスとの統合パターンについて説明されました。
また、メダリオンアーキテクチャ(Bronze/Silver/Gold)をS3 Tablesでどのように実装・最適化するかについても、具体的な構成例とともに紹介されました。
スピーカー
- Vara Bonthu, Principal Open Source Specialist SA, Amazon Web Services
- Manabu McCloskey, Senior Open Source Engineer, AWS
スケジュール
- 日時: Thursday, Dec 4 | 2:00 PM - 3:00 PM PST
- 場所: Mandalay Bay | Level 3 South | South Seas A
セッションタグ
- セッションタイプ: Chalk talk
- Level: 400 – Expert
- Features: Interactive
Amazon S3 Tables foundations
セッションの冒頭では、S3 Tablesの基礎について説明がありました。
フルマネージドなApache Icebergテーブル
これまでS3上にデータレイクを構築する場合、Icebergのメタデータレイヤーや個々のオブジェクト(Parquetファイルなど)をユーザー自身で管理する必要がありました。
S3 Tablesでは、「テーブルバケット (Table Bucket)」 という新しいAWSリソースが提供され、テーブルレベルでの管理が可能になります。
これにより、個々のオブジェクトではなく、テーブル単位でIAMポリシーやリソースポリシーを適用できるようになります。
また、S3 TablesはS3上に構築されているため、11ナイン(99.999999999%)の耐久性と4ナイン(99.99%)の可用性(標準クラスの場合)が提供されます。
Intelligent-Tieringクラスを使用する場合は3ナイン(99.9%)の可用性となります。
最近の機能発表では、S3 Tablesに対するIntelligent-Tiering(ストレージクラス)1とレプリケーション2のサポートも追加され、汎用S3との機能パリティが強化されています。
自動メンテナンス機能
S3 Tablesの最大の特徴は、Icebergデータレイクの健全性を保つためのメンテナンス作業をポリシーベースで自動化できる点です。
これらの設定は put-table-maintenance-configuration APIを使用して、テーブルバケットレベルで一括管理することが可能です。
1. スナップショット管理 (Snapshot management)
Icebergは更新のたびにスナップショットを作成し、タイムトラベル機能などを提供しますが、
無限に増え続けるスナップショットは管理コストの増大を招きます。
S3 Tablesでは、「最大10個のスナップショット、24時間以内のもの」といった保持ポリシーを設定することで、
自動的に古いスナップショットを整理できます。
2. 未参照ファイルの削除 (Unreferenced file removal)
テーブルの更新や削除、失敗した書き込みによって発生する「参照されなくなったファイル(ゴミ)」を自動的に特定し、削除します。
これにより、不要なストレージコストの発生を防ぎます。
3. コンパクション (Compaction)
ストリーミングデータなどで発生しがちな「大量の小さなファイル」問題を解決するため、
自動的に小さなファイルをマージして最適化します。
以下の3つのコンパクションアルゴリズムがサポートされています。
- Bin Packing: ソート順序を考慮せず、ファイルを単にグループ化してサイズを最適化します。
- Sort Compaction: データに特定のソート順序(日付、IDなど)がある場合に有効で、クエリ時のスキャン効率を向上させます。
- Z-order Compaction: 多次元的なデータ(例:タイムスタンプと位置情報など)に対して有効で、高度なクエリパフォーマンス最適化を提供します。
なお、コンパクションの料金は、実際に作業が行われた場合(最適化された場合)にのみ発生するとのことです。
Security & access patterns
S3 Tablesにおけるセキュリティとアクセスの考え方についても解説がありました。
階層的なアクセス制御
S3 Tablesは階層構造を持っています。
- テーブルバケット (Table Bucket)
-
ネームスペース (Namespace): テーブルの論理的なグループ(例:
sales,marketing) - テーブル (Table)
アクセス制御には、IAMポリシーやリソースポリシーを使用して GetTable や PutTable などのAPI操作を制御できます。
きめ細かなアクセス制御 (Fine-grained access)
行レベルや列レベルのアクセス制御が必要な場合(例:PIIデータの保護など)は、AWS Glue Data Catalog および AWS Lake Formation と統合します。
テーブル作成時に「AWS分析サービスと統合する」を選択することで、S3 TablesをGlue Data Catalogに登録し、Lake Formationを通じてSQLライクな権限管理が可能になります。
暗号化と監査
暗号化はテーブルバケットまたはテーブルレベルで設定可能で、SSE-S3またはSSE-KMSをサポートしています。
また、CloudWatchによるメトリクス監視や、CloudTrailによるAPIアクティビティの監査も可能です。
Service integrations & Architecture
データへのアクセス方法として、大きく3つのパターンが紹介されました。
- S3 Tables Iceberg REST Catalog (IRC) 直接アクセス: SparkやTrinoなど、Iceberg互換のクライアントから直接接続します。
- AWS分析サービスとの統合: Glue Data Catalogを経由して、Amazon Athena, Amazon Redshift, Amazon EMRなどから利用します。
- SageMaker Unified Studio: 統合データ開発プラットフォームとして、データソースの探索からクエリ、モデル構築までをシームレスに行えます。
メダリオンアーキテクチャの実装例
Bronze/Silver/Goldの各レイヤーにおけるS3 Tablesの活用と最適化戦略について、具体的な指針が示されました。
一般的なパターンは、「各レイヤーに1つ以上のテーブルバケットを採用すること」と紹介がありました。
※ネームスペースやテーブル別でも可能だが、クリーンな制御と効率的な最適化ができるため
Bronze層 (Ingestion)
-
処理形式: ストリーミング/取り込み
-
クエリパターン: 利用者は少なく、クエリパターンは不確定
-
ユースケース例: Eコマースサイトのクリックストリームログ収集
-
特徴: Kinesis Data FirehoseやKafkaからのストリーミングデータの着地場所。
変換やフィルタリングを行わず、高速な取り込み(Fast Ingestion)を優先します。
大量の小さなファイルが発生しやすい特性があります。 -
コンパクション戦略: Bin Packing
-
ターゲットファイルサイズ: 64MB〜128MB(小さめ)
-
スナップショット保持: 短期間(例:5日間)
-
ストレージクラス: Intelligent-Tieringの利用が推奨される場合がある。
Silver層 (Refinement)
-
処理形式: ストリーミング or バッチ/精製
-
クエリパターン: User IDやTimestampなどでのフィルタリングが多い
-
ユースケース例: Glue ETLやdbtを使用したデータ変換・フィルタリング後のデータ
-
特徴: データのクレンジングや変換を行った層。
特定の列(User IDやTimestampなど)でのフィルタリングクエリが増えます。 -
コンパクション戦略: Sort Compaction(よく使われるフィルタ列でソート)
-
ターゲットファイルサイズ: 512MB(デフォルト)
-
ストレージクラス: Intelligent-Tieringの利用が推奨される場合がある。
Gold層 (Aggregation/Business Logic)
-
処理形式: バッチ/分析
-
クエリパターン: 多次元(Timestamp, Geolocation, Product ID...)
-
ユースケース例: ビジネスインサイトのための集計済みデータ(ビューやマテリアライズドビュー)
-
特徴: アナリストやデータサイエンティストがDuckDB, Gremio, QuickSight, Snowflake, SageMaker Unified Studioなどで複雑なクエリを実行します。
-
コンパクション戦略: Z-order Compaction(多次元的なクエリに対応)
-
スナップショット保持: 長期間(例:7〜14日)
-
レプリケーション: クエリのレイテンシを低減するため、クエリが実行されるリージョンへデータをレプリケーション(Read-only replica)する構成が一般的です。
Q&A / Discussion
セッション中の質疑応答やディスカッションで取り上げられた主なトピックを紹介します。
Q: 行レベルや列レベルでの暗号化は可能か?
A: S3 Tablesの暗号化はテーブル(またはテーブルバケット)単位で適用されます。行や列レベルでのきめ細かなアクセス制御(フィルタリングなど)が必要な場合は、Glue Data Catalogと統合し、Lake Formationを使用する必要があります。
Q: DatabricksからS3 Tables Iceberg REST Catalog (IRC)を利用できるか?
A: 現時点ではネイティブサポートされていません。Snowflakeなどはサポートされていますが、Databricks側でのエンドポイント対応が必要です。
Q: Kinesisからの直接ストリーミングは可能か?
A: Amazon Kinesis Data Firehoseを使用することで、S3 Tablesへ直接データをストリーミング可能です。
スキーマ変更(Schema Evolution)にも対応しており、失敗したレコードはDLQ(Dead Letter Queue)で処理可能です。
また、Iceberg v3では「Variant data type」がサポートされ、非構造化・半構造化データの取り扱いも容易になっています。
Q: コンパクションを実行するとスナップショットが増えるのか?
A: はい。コンパクションは書き込み操作となるため、新しいスナップショットが生成されます。
スナップショット保持ポリシーと合わせてコストを管理する必要があります。
Q: Intelligent-Tieringを使用している場合、メンテナンス作業でコストは発生するか?
A: コンパクションなどのメンテナンス作業によって、Intelligent-Tieringのデータが「取り出し(Retrieve)」扱いになったり、ティアが上がったりすることはありません。
これにより、アクセス頻度の低いデータのストレージコストを効率的に削減できます。
まとめ
S3 Tablesは、運用データレイクの構築において「差別化につながらない重労働(Undifferentiated Heavy Lifting)」であるテーブルメンテナンスをAWSに任せるための強力なサービスです。
Key Takeaways:
- テーブルバケット/テーブル設計: ネームスペースやテーブル構造は、データベーススキーマや権限管理(Lake Formation/IAM)に直結するため、早期に設計を行うことが重要です。
- コンパクションの最適化: ワークロードパターン(Bronze/Silver/Gold)に合わせて、適切なコンパクション戦略とファイルサイズを設定することで、コストとパフォーマンスを最適化できます。
- ガバナンスに応じたアクセス方法の選択: 簡易なアクセスならIAMポリシー、きめ細かな制御が必要ならGlue/Lake Formation統合を選択します。
- Q Developer CLIの活用: テーブル用のMCPサーバーを利用することで、自然言語での相談が可能になっています。
S3 Tablesを活用することで、データエンジニアはインフラ管理から解放され、よりビジネス価値の高いデータ活用に注力できるようになります。
[re:Invent 2025] 参加レポート一覧はこちら (随時更新)
参考URL
-
Amazon S3 Tables で Intelligent-Tiering ストレージクラスの提供が開始
https://aws.amazon.com/jp/about-aws/whats-new/2025/12/s3-tables-intelligent-tiering-storage-class/ ↩ -
Amazon S3 Tables が Apache Iceberg テーブルの自動レプリケーションのサポートを開始
https://aws.amazon.com/jp/about-aws/whats-new/2025/12/s3-tables-automatic-replication-apache-iceberg-tables/ ↩