データメッシュをAmazonDataZoneで構築できるのかをプレビュー公開前に考察してみた

ちゅらデータ株式会社のアドベントカレンダー25日目の記事で候（今年もメリークリスマス侍）
クリスマスには全く関係ない記事を書いてしまうことをどうか容赦いただきたいでござる
※なお、この記事は弊社と関係なく、個人の記事であることをご了承ください

結論

• AmazonDataZoneだけでは不十分だと思う
  • DataZoneはドメイン間でデータを共有する際のデータカタログとして便利そう。ただし、現状はそれだけでデータメッシュを十分に構築できるとは言えない認識（もちろん、AWS公式ドキュメントを確認してもこれだけでデータメッシュを実現できるとは一言も書いていない）。例として、データプロダクトをテストしデータの品質と完全性に関する保証に準拠していることを確認するCI/CDのような機能は、見当たらない

動機

• 今年の10月にちゅらデータのテックカンファレンスなる琉球王国のオフラインイベントに登壇し、「データメッシュ」の概要について簡潔にまとめた資料を発表
  • 『Chura DATA Tech Conference 2022』イベントスケジュール（※イベントは終了しました）
    • https://cdtc2022.studio.site/
  • 発表スライド

• そんな折、AWS re:Invent 2022にてAmazonDataZoneが公開され、より時代がデータメッシュに追いついてきた感覚を得てしまい、昂る

• しかし、FAQによると、プレビュー版は2023年初頭にしかリリースされないため、執筆時点(2022年12月25日)では検証できず、冷める

• アドベントカレンダーに記事を書く予定を入れていたので、備忘録を兼ねてデータメッシュとAmazonDataZoneを紐付けた記事を無理やり書く意思を持つ（サービス使う前にサービスについて書くのは間違っているリスクが高いのであまり良くないと思うけど）

という流れの元、記事を書いているので、記事の内容に誤りが含まれる可能性が高い という前提で自己責任のもと読んでください

整理

はじめに、前提となる知識を整理する

データメッシュの4原則

1. ドメイン所有の原則（Principal of Domain Ownership）
   • ドメイン（ビジネスユニット）ごとにデータプロダクト（データ共有に必要なコンポーネントの最小単位）を所有しその責任を持つ
2. プロダクトとしてのデータ原則（Principal of Data as a Product）
   • データプロダクトは、品質（ベースラインユーザビリティ特性）に責任を持つ
     • ベースラインユーザビリティ特性
       1. 発見可能性（Discoverable）
          • 利用可能なデータを簡単に発見できる
       2. アドレス指定可能性（Addressable）
          • 一意のアドレスを通じてデータプロダクトにアクセスできる
       3. 理解可能性（Understandable）
          • エンティティの種類、エンティティ間の関係、および隣接するデータプロダクトを理解できる
       4. 信頼性（Truthful）
          • データプロダクトが真実であり、ビジネスの事実を正しく表している
       5. ネイティブにアクセス可能（Natively Accessible）
          • さまざまなデータユーザーがネイティブアクセスモードでデータにアクセスして読み取ることができる（SQL,API,DataFrame,スプレットシート等）
       6. 相互運用可能性（Interoperable）
          • 複数のドメイン間でデータを相互に関連付け、結合、フィルター、集計などの方法でそれらをつなぎ合わせる
       7. 独立して価値のあるもの（Valuable）
          • データプロダクトがそれ自体で価値を提供する
       8. 安全性（Secure）
          • データプロダクトに安全かつ機密性を考慮した方法でアクセスできる
3. セルフサービス型データプラットフォームの原則（Principal of the Self-Serve Data Platform）
   • データプロダクトを構築、テスト、展開、保護、および維持できるようにするために必要なすべての機能を持つデータプラットフォームを構築する
     • ドメインにとらわれない機能横断的なインフラを整備する
     • データプラットフォームチームが担当する
4. フェデレーテッドコンピュータガバナンス原則（Principal of Federated Computational Governance）
   • データプロダクトが安全で信頼できるものであることを保証するガバナンス
     • 一連のグローバルルールを作成し、ルールに基づいてデータプロダクトを作成する
     • ドメインごとのデータプロダクトオーナーとデータプラットフォームチームのオーナーからなるフェデレーテッドチームが担当する

AmazonDataZoneの主要な機能

1. Search for data in the business data catalog
   • ビジネス用語で目的のデータセットを検索できる
2. Collaborate through data projects
   • データプロジェクトとしてチームで共同作業ができる
3. Get personalized views of data assets through the web-based portal
   • AWSマネジメントコンソールにサインインしなくてもデータポータルを使用できる
4. Use machine learning (ML) to enhance accuracy and productivity
   • MLを使用して、データ資産をカタログ化する際にビジネス用語を自動的に提案する
5. Data security and control
   • アクセス制御とアクセス許可を1か所でより安全に管理できる

データメッシュとAmazonDataZoneを対応させてみた

「ドメイン所有の原則」との対応

データメッシュの第1原則の「ドメイン所有の原則」に関しては、「AmazonDataZoneドメイン」なる機能が対応してそう。機能の詳細はまだドキュメントに起こされてないが、FAQによると、

Q: What are Amazon DataZone domains?
With domains, you can more securely organize resources aligned to business-driven domains, such as LOBs. You have the flexibility to reflect your organization’s hierarchy through this scalable structure. Domains are a scalable container for you, your team, and related Amazon DataZone entities, including data assets and analytics tools—like Amazon Athena and Amazon Redshift query editors. You can publish a data asset in the catalog with a particular domain that governs the data. You can then control access on their associated AWS accounts and resources that can access that domain.

とあるため、ビジネス主導のドメインに合わせてリソースをより安全に編成できるっぽい

「プロダクトとしてのデータ原則」との対応

データメッシュの第2原則の「プロダクトとしてのデータ原則」に関しては、データメッシュのベースラインユーザビリティ特性とAWSDataZone主要な機能の対応表を独断と偏見を持って作ってみた

• 表における記号の説明
  • ○：関連があると思われる項目
  • -：関連がないと思われる項目

データメッシュ\AWSDataZone	business data catalog	data projects	web-based portal	use ML to enhance accuracy and productivity	data security and control
発見可能性	○	-	○	○	-
アドレス指定可能性	-	○	○	-	-
理解可能性	○	○	○	○	-
信頼性	○	○	-	-	-
ネイティブにアクセス可能	-	-	○	-	○
相互運用可能性	○	○	○	○	○
独立して価値のあるもの	○	○	-	-	-
安全性	-	○	○	-	○

表にまとめてみると、実現するための機能は揃ってそうな印象を受ける

「セルフサービス型データプラットフォームの原則」との対応

データメッシュの第3原則の「セルフサービス型データプラットフォームの原則」に関しては、「データプロダクトを構築、テスト、展開、保護、および維持できるようにするために必要なすべての機能を持つデータプラットフォームを構築する」と定義した際には、テストの項目に関しての機能がDataZoneのドキュメントからは見当たらなかったため、不十分だと考える。
実際、DataMeshのオライリー本P175から引用すると、

Another way that the platform supports data governance computationally is to run auto- mated tests. Automated testing makes sure that the data product complies with its guaran- tees in terms of data quality and integrity. The platform sets up and runs CI/CD pipelines that data product developers utilize to add testing to their data products code. Automated tests intend to provide rapid feedback loops to the developers to detect and address errors as early and cheaply as possible.

とあり、データプロダクト開発者がデータプロダクトコードにテストを追加するために利用するCI/CDパイプラインをセットアップして実行するデータプラットフォームの構築を推奨している。
この点においてはDataZoneは十分で無く、別のツールに頼る必要があると考える

「フェデレーテッドコンピュータガバナンス原則」との対応

データメッシュの第4原則の「フェデレーテッドコンピュータガバナンス原則」に関しては、DataZoneの「Data security and control」により、アクセス制御とアクセス許可を1か所でより安全に管理できるとあるため、実現するための機能としては存在する認識である

まとめ

本記事は、まだプレビュー公開がされてないため、誤りが含まれている可能性が高いことを前提としつつ、データメッシュの4つの原則とAmazonDataZoneのドキュメントに公開されている機能に対応させて、構築できるのかについて考察した
実際の検証については、来年のたのしみの一つである

終わりに

ちゅらデータでは、クレイジーな仲間を募集しているでござる
データエンジニア、もしくはSE系からデータエンジニアになりたい方がいればぜひ、御仁の力量に応じたグレード（ジュニア/ミドル/シニア）にて、応募するでござる

参考資料