カミナシ エンジニアブログ

株式会社カミナシのエンジニアが色々書くブログです

【AWS re:Invent 2025】S3 Tablesでメダリオンアーキテクチャのデータ基盤をつくろう!

はじめに

カミナシの認証認可チームのmanaty(@manaty226)です。今年もラスベガスにて12月1日から12月5日まで開催されているre:Inventに参加しています。この記事では、最終日に参加した以下のワークショップセッションについて記載します。

  • Modern batch analytics: Building advanced transactional datalakes with S3 Tables

メダリオンアーキテクチャにもとづくS3 Tablesデータ基盤

本セッションでは、S3 Tablesを使ってメダリオンアーキテクチャと呼ばれる、データを3層のストレージで管理するデータ基盤を作成するワークショップです。メダリオンアーキテクチャでは、未加工のデータを保存するブロンズ層、データのクレンジングや複数の未加工情報の結合などを行ったきれいなデータを扱うシルバー層、報告用ダッシュボードのような具体的なユースケースに合わせたゴールド層の3層のアーキテクチャのようです。

昔はデータレイク、データウェアハウス、データマートのような言い方をしていた記憶があるのですが、いつの間にか変わったんですね。レイクハウスにおける論理的な分離設計という意味なのかもしれません。

複数の種類のデータを統合していく

さて、ワークショップではまずブロンズ層にデータを投入していきます。データはParquet形式とCSV形式の2つのデータがありますので、それぞれをGlueで別々のS3 Tablesに格納していきます。ブロンズ層のS3 Tablesに格納されたcustomer情報のテーブルをプレビュー機能で確認してみると下図のような結果になります。

ブロンズ層とシルバー層までの流れ

ブロンズ層のデータプレビュー

その次に、再度別のGlueジョブを起動して、2つのデータを結合したシルバー層のデータを作成して、ブロンズ層-シルバー層の構成図における図中最右のS3 Tablesに格納します。このデータをS3 Tablesのプレビュー機能で確認すると、先ほどと違い最右カラムにcompanyという情報が追加されていることがわかります。これで、ブロンズ層のデータを結合したシルバー層のデータができあがりました。

シルバー層では結合されてcompanyカラムが見える

S3 TablesのデータをAthenaからもクエリしてみます。ワークショップで殆ど全員が詰まったのがこのステップで、LakeFormationで権限付与しなければなりません。インストラクターの指示に従い、ユーザーロールにsuper権限を付与してクエリしました。

その後、SageMaker Unified Studioを使ってゴールド層のS Tables データベースを新規作成します。ゴールド層のデータベースにSageMaker Unified StudioからCREATE TABLEクエリを実行してテーブルを作成しようとしたのですが、ここでもなぜか権限エラーで作成できず…ワークショップ参加者のほぼすべての方が前述した権限エラーで助けを求めて手を上げており、インストラクターの方が自分に気づく気配がなかったので試しにAthenaでクエリを実行してみたところテーブルが作成されました。Athenaとはまた異なる権限設定が必要なのかもしれません。ワークショップの中では原因を突き止めきれませんでした。

Amazon SagaMaker Unified Studio

権限周りはLakeFormation Permissionが利用されているためとっつき辛く難しく感じることもありましたが、テーブルごとに権限を分離することもできるためデータを社内で利活用する際には最小権限でデータガバナンスを効かせられて便利と感じました。

このあと本来はAmazon QuickSuitからS3 Tablesのデータを読んでグラフとして表示するステップもあったのですが、こちらも何らかの権限エラーでデータにアクセスできず、S3 Tablesの権限周りの難しさをひしひしと感じるワークショップになりました…

S3 Tablesの最適化

S3 Tablesには、運用や性能の観点で設定を最適化できるパラメータがあります。例えば、細かく投入された複数の小さなデータを一つにまとめるコンパクションや、過去の時点のデータを管理するスナップショット、参照されないデータを自動的に削除する機能などが存在します。こうしたデータ管理の設定値は、メダリオンアーキテクチャの各層の役割によって変更します。

コンパクション戦略において、ブロンズ層では元データの追跡可能性や監査のため、コンパクションを行わないほうが好ましい場合があります。一方で、シルバー層ではビンパック、ゴールド層ではZ-orderといったコンパクションを実行しパフォーマンスを向上させるようです。スナップショットにおいては、ブロンズでは保持期間を短く(24時間)設定しつつシルバー層で長く(7日間)取り、ゴールド層では中程度(3日間)をワークショップで設定しました。これは、頻繁に更新されるブロンズ層のコストを最適化しつつ、シルバー層で長めにスナップショットを取って履歴の再生成を可能とし、ゴールド層でコストと実用のトレードオフをとるというような考え方のようです。非参照データ削除についてもコストと実用や性能のバランスを考えながら設定していくとのことですが、こういったS3 Tablesの最適化戦略については運用しながらユースケースにあった最適値を見つけていく必要があるなと感じました。

こうしたテーブル運用に関する設定パラメータは、以下のAWS CLIコマンドで取得して確認することができました。

aws s3tables get-table-maintenance-configuration   --table-bucket-arn $BRONZE_ARN   --namespace $BRONZE_NAMESPACE   --name $BRONZE_TABLE

おわりに

今回はre:Invent最終日に受講したS3 Tablesのワークショップについて書きました。S3 Tablesのセッションは最終日セッションにも関わらず満席でサービスに対する注目の高さを感じました。一方で、S3 Tablesにアクセスするための権限設定はロールなどのアイデンティティベースポリシーに加えてS3 Tables自身のリソースポリシーとLakeFormationのパーミッションが関わってくるため、どの設定が誤っているのか、そもそもどういった権限構成になっているのかもよくわからないのが難しいところと感じました。

re:Inventもついに終わりました。最終日まで本当に沢山の学びがあるセッションばかりで、来年もまた参加したいと強く思いつつ、帰路につく中でこのブログを書いています。

カミナシではゴヨウ、ドラセナ、テーブルシティといったカードが好きなソフトウェアエンジニアを募集しています。興味がある方はカジュアル面談からよろしくお願いします。

去年も行ったThe Crack Shackのお気に入りハンバーガー