背景・目的
こちらに続けてData Meshについて調べて、整理した結果になります。
まとめ
- データメッシュには4つの原則がある
- domain-oriented decentralized data ownership and architecture
- data as a product
- self-serve data infrastructure as a platform
- federated computational governance
概要
Data Mesh Principles and Logical Architectureを元に整理しています。
The great divide of data
-
運用と分析でデータの種類は大きく分かれる。
- 運用データは、マイクロサービスで提供されるビジネス機能の背後にあるDBにあり、トランザクションの性質を持ち、ビジネスを実行するアプリケーションニーズに対応する。
- 分析データは時間の経過とともにビジネスの事実の時間的及び集約されたビュー。多くの場合、遡及的、または将来の視点の洞察を提供するためにモデル化される
- MLモデルをトレーニングするか、分析レポートをフィードする
-
テクノロジー、アーキ、組織設計の現在の状態は、運用データと分析データプレーンの相違を反映している。
出典:Data Mesh Principles and Logical Architecture -
分析データプレーンは、データレイクとDWHの2つの主要なアーキとテクノロジースタックに分かれる。
- データサイエンスのアクセスパターンをサポートするデータレイク
- 分析、BIレポートのアクセスパターンをサポートするDWH
Core principles and logical architecture of data mesh
- データメッシュの目的は、分析データと過去の事実から価値を大規模に取得するための基盤を作成する。
- 以下の目的を達成するために、データメッシュの実装が具体化する4つの基本原則がある
- データランドスケープの絶え間ない変化に適用されるスケール
- データソースとコンシューマの両方の急増
- ユースケースが必要とする変換と処理の多様性
- 変化への対応速度
- 4つの原則は、以下の通り
- domain-oriented decentralized data ownership and architecture
- data as a product
- self-serve data infrastructure as a platform
- federated computational governance
Domain Ownership
- データメッシュは継続的な変化とスケーラビリティをサポートするため、分散化とデータに最も近い人々への責任の分散化に基づいている。
- データエコスシステムの分散
- 所有権の分解
- 所有権の分解には、ビジネスドメインの境界につけられたコンテキストが候補になる
Logical architecture: domain-oriented data and compute
- 分解を促進するために、分析データをドメインごとに配置するアーキをモデル化する必要がある。
- ドメインのインターフェイスには、運用機能だけではなくドメインが提供する分析データへのアクセスを用意する。
- 各ドメインは1つまたは複数の運用APIと1つまたは複数の分析データエンドポイントを公開する。
- 各ドメインは、他のドメインの運用、分析データエンドポイントに依存する可能性がある。
Data as a product
- 既存の分析データアーキテクチャの課題の1つは、質の高いデータを発見、理解、信頼し、最終的に利用するためのコストが高いこと。
- ドメインとして提供される分析データは製品として扱われる必要があり、そのデータのコンシューマーは顧客として扱われる必要がある。
- 各ドメインは、ドメインのデータプロダクトの構築、維持、提供を担当するデータプロダクト開発者の役割が含まれる。
Logical architecture:data product the architectural quantum
- データ プロダクトは、その機能に必要な3つの構造コンポーネントをカプセル化するメッシュ上のノードであり、ドメインの分析データへのアクセスをプロダクトとして提供する。
- コード
- データパイプラインのコード
- データへのアクセス、セマンティクス、シンタックススキーマ、オブザーバビリティメトリクス、およびその他のメタデータを提供するAPIのコード
- アクセス制御ポリシー、コンプライアンスなどの特性のコード
- データとメタデータ
- インフラ
- データプロダクトのコードの構築、展開、実行、ビックデータとメタデータへのストレージとアクセスを可能にする
- コード
Self-serve data platform
- データプロダクトを構築、展開、実行、監視、アクセスのためには大量のインフラをプロビジョニングする必要がある。
- このインフラのプロビジョニングに必要なスキルは専門性があり、各ドメインで保持するのは困難。
- そのため、ドメインの自律性を可能にするプラットフォームとしてのセルフサービスインフラストラクチャの新しい原則が必要。
- セルフサービスインフラストラクチャには、現在のコストを削減する機能と、データプロダクトの構築に必要な専門家を含める必要がある。
Logical architecture: a multi-plane data platform
- セルフサービスプラットフォームの構築には、モデルで呼ばれる複数のカテゴリ、またはプレーンに分類される
- セルフサービスプラットフォームには、異なるプロファイルのユーザに対応する複数のプレーンを含めることができる。
- Data infrastructure provisioning plane
- データ製品のコンポーネントと製品のメッシュを実行するために必要な、基盤となるインフラストラクチャのプロビジョニングをサポートする
- 以下が含まれる
- 分散ファイル ストレージ
- ストレージ アカウント
- アクセス制御管理システムのプロビジョニング
- データ プロダクトの内部コードを実行するためのオーケストレーション
- データ プロダクトのグラフでの分散クエリエンジンのプロビジョニングなど
- データ製品の開発者がこのインターフェイスを直接使用する。
- Data product developer experience plane
- データプロダクト開発者が使用するメインインターフェイス
- 開発者のワークフローをサポートするために必要な煩雑さの多くを抽象化する
- provisioning planeよりも高いレベルの抽象化を提供
- シンプルな宣言型のインターフェイスを使用し、データプロダクトのライフサイクルを管理する
- Data mesh supervision plane
Federated computational governance
-
多くのユースケースでは、高いレベルのデータセット、洞察、価値を得るために、それらを相互運用する必要がある。
- 相互に関連付け
- Unionを作成
- 結合
- グラフを実行
-
対応するには、以下を含むガバナンスモデルが必要
- 分散化
- ドメインの自己主権
- グローバル標準化による相互運用性
- 動的トポロジ
- プラットフォームによる決定の自動実行
-
データ メッシュにおけるガバナンスの優先順位は、分析データ管理システムの従来のガバナンスとは異なる。
-
どちらも最終的にはデータから価値を得ることに着手するが、以下の違いがある。
- 従来のデータ ガバナンスは、意思決定を一元化し、変更のサポートを最小限に抑えてデータのグローバルな正規表現を確立することで、それを達成しようとする
- データメッシュのフェデレーテッドコンピューティングガバナンスは、変更と複数の解釈コンテキストを受け入れる。
Logical architecture: computational policies embedded in the mesh
- フェデレーション ガバナンス モデルが機能するためには以下が必要。
- 支援的な組織構造
- インセンティブモデル
- アーキテクチャ
- ローカル ドメインの自律性を尊重しながら、相互運用性に関するグローバルな決定と基準に到達し、グローバル ポリシーを効果的に実施するために必要.
- 以下にデータガバナンスの集中型（データレイク、DWH）モデルとデータメッシュの対比を記載する。
| Pre data mesh governance aspect | Data mesh governance aspect |
|---|---|
| Centralized team | Federated team |
| Responsible for data quality | Responsible for defining how to model what constitutes quality |
| Responsible for data security | Responsible for defining aspects of data security i.e. data sensitivity levels for the platform to build in and monitor automatically |
| Responsible for complying with regulation | Responsible for defining the regulation requirements for the platform to build in and monitor automatically |
| Centralized custodianship of data | Federated custodianship of data by domains |
| Responsible for global canonical data modeling | Responsible for modeling polysemes - data elements that cross the boundaries of multiple domains |
| Team is independent from domains | Team is made of domains representatives |
| Aiming for a well defined static structure of data | Aiming for enabling effective mesh operation embracing a continuously changing and a dynamic topology of the mesh |
| Centralized technology used by monolithic lake/warehouse | Self-serve platform technologies used by each domain |
| Measure success based on number or volume of governed data (tables) | Measure success based on the network effect - the connections representing the consumption of data on the mesh |
| Manual process with human intervention | Automated processes implemented by the platform |
| Prevent error | Detect error and recover through platform’s automated processing |
Principles Summary and the high level logical architecture
- Domain-oriented decentralized data ownership and architecture
- データ ソースの数、ユース ケースの数、およびデータへのアクセス モデルの多様性が増加するにつれて、データを作成および消費するエコシステムをスケールアウトできるようにするため。 メッシュ上の自律ノードを増やす。
- Data as a product
- データ ユーザーが高品質のデータを簡単に発見、理解して安全に使用できるように、快適な体験を提供。
- Self-serve data infrastructure as a platform
- ドメインチームがプラットフォームの抽象化を使用して自律的にデータ プロダクトを作成および使用できるようにすることで、安全で相互運用可能なデータ プロダクトの構築、実行、および維持の複雑さを隠蔽する
- Federated computational governance
- データ ユーザーが独立したデータ プロダクトの集約と関連付けから価値を得ることができるように、メッシュはグローバルな相互運用性基準に従ってエコシステムとして動作する。
出典：Data Mesh Principles and Logical Architecture>Figure 13: Logical architecture of data mesh approach
- データ ユーザーが独立したデータ プロダクトの集約と関連付けから価値を得ることができるように、メッシュはグローバルな相互運用性基準に従ってエコシステムとして動作する。
考察
概念は理解できたが、具体的にどのように実装するかイメージがつかないので引き続き調査したい。
参考