データメッシュの概念は、大規模なデータ管理における共通的な問題に対処するための新たな手法を提供する。Zhamak Dehghani氏はデータメッシュの４つの原則を、対応する論理アーキテクチャと組織化構造によってさらに明確化した。氏の記事は、データメッシュとドメイン指向データを説明した過去の記事やプレゼンテーション、ポッドキャストをフォローアップしたものだ。
氏が強調するのは、運用データと分析データの"大きな相違"だ。従来のETL(Extreact/Transform/Load)ジョブのパイプラインは、ビジネスの実行に使用されるトランザクショナルなデータと、ビジネスに関する洞察の提供に使用されるデータレイクやデータウェアハウスという、この2つの分割にまたがるものだった。データメッシュでもこれら2つの異なる視点とユースケースの必要性は認識するが、このテクノロジ境界に沿ってチームやアーキテクチャを編成するのではなく、ドメインに注目することでこの2つを統合する点が異なっている。
このようなトポロジに従うことにより、マイクロサービスと自己完結型データベースがトランザクションデータのスケールアップを可能にするのと同じ方法で、分析データをスケールアップすることが可能になる。スケールアップに対する期待を、品質や整合性とともに達成するために、Dehghani氏は、データメッシュの4つの原則を明確化した。
1. ドメイン志向で分散型のデータオーナシップとアーキテクチャ
2. プロダクトとしてのデータ
3. セルフサービス型データインフラストラクチャ・アズ・ア・プラットフォーム
4. 連合型の計算ガバナンス
出典: https://martinfowler.com/articles/data-mesh-principles.html — Figure 13
これらの原則に対してDehghani氏は、テクノロジに依存しない論理アーキテクチャを提供している。これにより、ツールあるいは実装の詳細において必要以上に規範的になることを明確に避けるとともに、いくつかの疑問には答えないままにすることによって、データメッシュソリューションに対するイマジネーションやクリエイティビティを促進する効果を期待しているのだ。
"ドメイン志向で分散型のデータオーナシップ"という考え方は、ビジネスドメインに基づいて分解された組織をベースとする。従ってデータメッシュでは、この継ぎ目に沿って分解軸を見つけ出す必要がある。Conwayの法則については直接的に言及されていないが、自身のビジネスユニットに属する運用データと分析データ、および、その間のETLプロセスすべての責務を持つチームを見れば、それが適用され得ることは理解できる。
それぞれのビジネスドメインがデータの両面を担うのであるから、そこに属するチームには、運用APIと分析用エンドポイントの両方を提供する責務がある。ひとつのドメインは、公開されているエンドポイントにアクセスすることで、別のドメインの運用データ、および/または分析データに依存することが可能だ。
出典: https://martinfowler.com/articles/data-mesh-principles.html — Figure 5
マイクロサービスではサービスディスカバリが必要になるため、分散データメッシュは検出可能なデータプロダクトを所持しなければならない。データが容易に検出および理解可能でなければ、分散することによって既存の分析システムの抱える問題が悪化する可能性もある。これを解決するためには、データメッシュの実装におけるドメインデータをプロダクトとして、プロダクトオーナと開発者がデータプロダクトの構築とメンテナンスの責務を持つ必要がある。論理アーキテクチャ内では、このデータプロダクトを、アーキテクチャ量子(architectural quantum)として説明している。
"アーキテクチャ的には、ドメインが自律的に提供および消費の可能なプロダクトとしてデータをサポートするために、アーキテクチャ量子としてのデータプロダクト、という概念を導入しています。アーキテクチャ量子は進化的アーキテクチャ(Evolutionary Architecture)で定義されているもので、高度な機能的コヒージョンを持ち、独立的にデプロイ可能で、機能上必要な構造的要素をすべて含んだ、アーキテクチャの最小単位を表します。"
それぞれのデータプロダクトはデータメッシュ上で動作可能なノードであり、各チームがコード、データとメタデータ、インフラストラクチャを担当する。これら3つの構成コンポーネントを同じコンテキスト境界内に留めるというのは、強固に分離されたトランザクションデータと分析データ間のパイプライン、という従来のパラダイムから離脱することに他ならない。
多くのチームが組織標準に準拠したデータプロダクトを確実に提供できるようにするためには、セルフサービスデータインフラストラクチャ・アズ・ア・サービスの存在が不可欠となる。これはマイクロサービスPaaSの"舗装道路(paved road)"という考え方に倣ったものなので、マイクロサービス開発を成功させるという意味での両者の類似点は明らかだ。既存のサービス展開プラットフォームをスタートポイントに使用することも可能だが、データ分析やパイプラインコードを追加するため、新たなレベルの複雑性を抱えることになる。Dehghari氏の個人的な希望は、運用インフラストラクチャとデータインフラストラクチャの2つが賢明な形での収束を見ることだ。
セルフサービスプラットフォームの論理アーキテクチャは、データインフラストラクチャプロビジョニング、データプロダクト開発者エクスペリエンス、データメッシュ管理という3つのプレーンで編成されている。関心対象を明確に分離することがその目的だが、厳密なレイヤ構成や物理的階層構造を意味するものではない。
出典: https://martinfowler.com/articles/data-mesh-principles.html — Figure 10
データメッシュはデータチームが独立的に作業することを可能にするが、ほとんどのユースケースにおいては、複数のデータプロダクトを結び付けるための相互運用性が必要になる。ルールを強要する(と同時にパイプラインにボトルネックを生じさせる)単一のデータウェアハウスを持たないデータメッシュでは、連合的な処理ガバナンスが必要だ。
ドメインデータプロダクトのオーナとデータプラットフォームプロダクトのオーナで構成されるグループは、すべてのチームが遵守すべきグローバルルールを決定する一方で、チームが自身のドメインや実装を十分にコントロールできるような権限を付与しなければならない。"グローバルな決定の最終的な目標はただひとつ、データプロダクトの検出と構成を通じた相互運用性と複合的ネットワーク効果を作り出すことです。"
出典: https://martinfowler.com/articles/data-mesh-principles.html — Figure 12