背景

過去（投稿日 2022年12月25日）にプレビュー公開前の情報のみでAmazonDataZoneを用いてDataMeshを実現できるか考察する記事を書いた

過去執筆時点から2年3ヶ月程経過した現在において、AmazonDataZoneを用いてどのようなことができるのか、DataMeshを実現できるのか、という所感を備忘録としてまとめる

本編

AmazonDataZoneとは、料金体系、ハンズオン、DataMeshとの関連について述べる

AmazonDataZoneとは

Amazon DataZone は、AWS、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。Amazon DataZone を使用すると、組織のデータアセットを監督する管理者やデータスチュワードは、きめ細かい制御を使用してデータへのアクセスを管理および統制できます。これらの制御は、適切なレベルの権限とコンテキストでアクセスできるように設計されています。Amazon DataZone を使用すると、エンジニア、データサイエンティスト、プロダクトマネージャー、アナリスト、ビジネスユーザーが組織全体のデータに簡単にアクセスできるようになり、データに基づくインサイトを発見、使用、コラボレーションして導き出すことができます。

参考

料金体系

現在(2025/3/22)の料金体系

概要
- 現在は毎月一定の制限（Amazon DataZone ドメインを作成するアカウントごとに、20 MB のメタデータストレージ、4,000 件の API リクエスト、0.2 件のコンピューティングユニット）まで無料で提供される

料金ディメンション	料金	無料使用
リクエスト	100,000 件のリクエストあたり 10 USD	1 請求月に 1 アカウントあたり 4,000 件の無料リクエスト
メタデータのストレージ	1 GB あたり 0.4 USD	1 請求月に 1 アカウントあたり 20 MB の無料ストレージ
コンピューティング	コンピューティングユニットあたり 1.776 USD	1 請求月に 1 アカウントあたり 0.2 の無料コンピューティングユニット
レコメンデーション（入力トークン）	1,000 入力トークンあたり 0.015 USD	無料使用なし
レコメンデーション（出力トークン）	1,000 出力トークンあたり 0.075 USD	無料使用なし

参考資料

過去(2024/11/1以前)の料金体系

概要
- ユーザーベースで課金されており、1ユーザーあたり9ドル支払う必要があった
  - （感想）ユーザーベース課金だとコスト面でも導入ハードルが高そう
参考資料

ハンズオン

Amazon DataZone ハンズオン(ベーシック)に従いハンズオンを実施

参考資料

作成するリソースの構成図は以下の通り

コンシューマープロジェクト作成し、公開されているデータアセットをサブスクライブ申請を行います。そしてプロデューサープロジェクトで、サブスクライブの申請を承認します。承認されたら、コンシューマープロジェクトからデータを利用して分析を行います

なお、ハンズオンを実施してみたところ、UIの違いが多少あったため以下に差分を記述する

1.Amazon DataZone ドメインとデータポータルを作成する
    2.ドメインの作成
    - [Amazon DataZone を続けて使用します]をクリック
        - Amazon SageMaker Unified Studioを今回は利用しない
    - [Quick Setup]->[Quick setup for DataZone]に名称が変更されている

2.プロデューサー プロジェクトを作成する
変更なし

3.プロジェクト環境を作成する
変更なし

4.Amazon DataZone で公開するデータを作成する
- オプション：手作業でのデータカタログ作成を選択(作成するリソースをできるだけ手作業で作成し把握するため)
    -  3-7
        -  Catalogsで[Dafault catalog]を入力するとDatabasesに[salesenvironment_pub_db]が出てくる
5.メタデータを設定する
    -  1-3 
        -  アセット名は「Order Confirmation Status Verification」で表示された(アセット名は AI により自動で反映される)

6.Amazon DataZone でデータアセットを公開する
    -  1-3 
        -  現時点でDLしたデータのカラムは[c_order_id]ではなく[c_customer_id]

7.コンシューマー プロジェクトを作成する
    -  2-4 
        -  [サブスクライブする]ではなく[リクエストする]

わかりやすく解説するために、例えば以下のようなユースケースを妄想してみた。

ユースケース

マーケティング部担当A「セールス部が使っているデータで新しいキャンペーンに使えそうなデータないかな。使えそうなデータがあれば欲しいなぁ。「注文」で引っ掛かるテーブルを検索してみるか（設定で検索可能になる）」

マーケティング部担当A「注文情報のスキーマ見ると使えそうな感じがするな（設定でスキーマの閲覧が可能になる）」

マーケティング部担当A「よし、リクエストしよう」

セールス部担当B「リクエスト来てる。この前話してた新キャンペーンのターゲット分析に使うためのデータが欲しいと言ってたやつね」

セールス部担当B「このテーブルはマーケティング部に対して全部共有していいデータゆえにフルアクセスを許可するでござる（行フィルターまたは列フィルターを使用することも可能）」

〜終〜

といった形でスムーズな連携が可能となる。

DataMeshとの関連

「データメッシュ向けのAWSサービス」を元にできることを簡潔に述べる

参考資料

データプロデューサーは、Amazon DataZone データポータルによって提供されるビジネスカタログにデータ製品を公開します。データポータルは、中央ガバナンスアカウントでホストされます。

->データを保有しているドメインはAmazonDataZoneにビジネスカタログを登録する。

2.データコンシューマー (ユーザー) は、AWS 認証情報またはシングルサインオン認証情報を使用してデータポータルにログインします。カタログを参照し、キーワードを使用して興味のあるデータ製品を検索できます。検索結果をフィルターできます。

->データを使うユーザ(データコンシューマー)はAmazonDataZoneが提供するデータポータル経由でデータを検索する。

3.コンシューマーチームに属するデータユーザーは、興味のあるデータ製品を見つけたら、データへのアクセスをリクエストできます。Amazon DataZone には、データ所有者がリクエストを確認して承認するために使用するアクセス管理ワークフローが組み込まれています。

->欲しいデータがあればリクエストを送る。データを提供するユーザは、アクセス管理フローを利用して承認する。

4.データコンシューマーチームは、データを活用して、人工知能と機械学習 (AI/ML)、分析とレポート、抽出、変換、ロード (ETL) のユースケースを強化できます。

->許可されたデータを利用して分析に利用できる。

上記の例を見てもわかるように、異なるドメイン間でデータ共有のガバナンスを利かせつつスムーズな連携によってビジネスライクなメタデータ管理ができるデータカタログ機能を中心としたデータ管理サービスとして、データメッシュの一部を実現するサービスの候補となることは間違いなさそう。

ただし、データカタログとガバナンスに関する管理機能が充実しているものの、CI/CDパイプラインをセットアップして実行するデータプラットフォームの構築などはいまだに機能としては存在せず、DataZone1つでDataMeshを実現はできない（そもそもすべてを網羅しようとしたプロダクトではないはずなのでこれはこれで良い気がする）。

実際にプロダクトに触ってみた所感としては、データメッシュの4原則に対応したプロダクトになっているかという観点において、筆者が書いた2年前の記事で主張した事柄に関して概ね予想通りだったと言えそう。

まとめ

本記事では、AWSが提供するサービスAmazonDataZoneについて、概要、料金体系、ハンズオン、DataMeshとの関連をまとめた。

異なるドメイン間でデータ共有のガバナンスを利かせつつスムーズな連携によってビジネスライクなメタデータ管理ができるカタログサービスとしては便利そうである。ドメイン単位の承認フローをちゃんと組めば導入できそうな気がする。また、カラムに対して論理名、物理名を分けて管理できたり、行単位、列単位での特定レコードに対するアクセス制御だったり、ラベルをつけて公開可能なデータだけを絞るといったことも可能な点はデータカタログ機能を持つ他サービス同様、便利な機能だと感じた。

ただし、特定のユーザにのみ特定のデータを検索可能にするなどの細かい設定をGUIベースでは実現が難しそう（承認時に行や列に対するフィルター制御は可能）だったりするため、こういったGUIに富んだマネジメントサービスの場合は要件に応じてどこまで細かい制御ができるかをしっかりと調査した上で導入した方が良いと感じた。