データメッシュ

データメッシュとは、分析データを非中央集権的なやり方で共有、アクセス、管理するためのソシオテクニカルなアプローチ

ソシオテクニカルなアプローチ

訳注：技術システムと社会システムとの間に相互作用があることを前提とし、それらの調和的な最適化を目指すアプローチ

コンウェイの法則などを踏まえたワードで、使えそう

データウェアハウスやデータレイクとは異なり、ドメインによる分割の仕組みである

各ドメインにデータ所有権があり、データ分析者をクライアントとしてP2Pでデータをやりとりするイメージ

詳細はZhamak Dehghani の著書Data Mesh (O’Reilly)でカバーされている

データメッシュでは、データプロダクト量子（Data Product Quantun：DPQ）というサービスからは独立したノードを立てる

DPQはドメイン内に存在し、サービスの持つデータをドメイン外へ提供する役割

サービスを提供するチームがこれも提供する

運用の単位としてはサービスと独立するが、サービスとの論理的な結合度は高い

サービスとDPQは厳密なコントラクトで繋げて、サービスからデータを取得する。そしてデータをフィルタリング、整形することでデータの品質を保証し、ドメインの外部へAPIで提供する。

外部には緩いコントラクトで提供することで利用者側の進化可能性を高めるようにする

サービスとの論理的な結合度は高いが、それはコントラクトが厳密だからであり、サービスの具体的な実装詳細に依存してはならない

DPQは基本的には非同期かつ結果整合性で通信する

DPQがサービスへパフォーマンス上の影響を与えないようにするため

要件次第で同期通信を使うこともあるらしい

DPQには振る舞いを実装することもある

他の量子が消費するデータ量、タイミング、品質、透明性を決める処理を作ったりしていい

DPQには幾つかの種類がある

Source aligned (ネイティブ) DPQ

サービスに代わってデータを外部へ提供する単純なDPQ

書籍内の揺らぎだとソースDPQとも。これが一番いい呼び名な気がする。

集約DPQ

複数のサービスと同期or非同期の通信をしてデータを集約するDPQ

Source aligned DPQからデータを取り出すこともある

というか、基本的にはソースDPQを必ずサービスごとに立てて、必要に応じてそのソースDPQを集約するDPQを立てるのがいい気がする

目的特化DPQ

特定の要件に特化したDPQで、分析レポート、BI、機械学習などを提供する

とりあえずデータを提供して、各種分析はドメイン外に立てたユーザのノードでやればいいような気がするが...?

table:データメッシュパターンのトレードオフ

メリットデメリット

マイクロサービスアーキテクチャに最適 DPQとのコントラクト調整を必要とする

現代的なアーキテクチャの原則とエンジニアリングに従っている非同期通信と結果整合性を必要とする

分析データと業務データの間に優れた分離をもたらす

慎重に形成されたコントラクトにより、分析能力を疎結合に進化できる