DataMeshの論理アーキテクチャ

この記事は?

前回はDataMeshの概念についてまとめました。今回はこちらの記事でデータメッシュの論理構造が解説されているので、まとめていこうと思います。

運用データと分析データの断絶

企業でのデータは運用データと分析データに分けられる。運用データとはビジネスを運営しているときに得られるデータである。分析データは、ビジネスにおけるファクトを集約したデータで、MLモデルや分析レポートに使われる。
この2つのデータプレーンは、分断されていて、ETLパイプラインでつながれている。そして、両方が拡大しETLパイプラインが複雑になるにつれて、ジョブが定期的に失敗するようになったりしてメンテナンスが大変になることはおなじみの光景である。 f:id:wata101wata:20210121211755p:plain f:id:wata101wata:20210121212702p:plain データメッシュはこの2つのデータプレーンを従来とは異なる構造で接続しようとする。2つのデータプレーンをマイクロサービスとしてその中に一緒に入れ込んでしまい、外からはAPIでアクセスする。

DataMeshの論理アーキテクチャと原則

データメッシュの目的は分析データを最大限活用できるスケールする基盤を作ることである。データソースと消費者(分析データを使うもの・ひと)の増加、ユーズケースの増加によるデータ変換と処理の多様化、変化への即応性などに対応する。これを達成するため次の4つの原則がある。

1.ドメイン志向のデータオーナーシップとデータアーキテクチャの分解
2.data as a product
3.self-serve data infrastructure as a platform
4.連合計算ガバナンス

ドメインオーナーシップ

データメッシュでは、責任はデータに最も近い人に分散される。スケーラビリティと継続的な変更を支援するためである。どのようにするかが問題である。
今日の組織はドメインごとに分割されているが、データメッシュもそれに沿う。これにより、システムの変更の影響を局所的にできる。
この例では、架空のメディアストリーミング会社(spotifyとか)を例にする。この会社も運用で分割されていて、”ポッドキャスト”チームはポッドキャストの運用と配信のシステムを運用しており、”アーティスト”チームはアーティストへの支払いシステムを運用している。データメッシュはこれらドメインごとが分析データを提供することに責任を持つ。例えば、”ポッドキャスト”チームはもちろん運用のためのAPIに責任を持つが、それだけでなく、分析用のデータのAPIにも責任を持つ。

論理アーキテクチャドメイン指向データ

このアーキテクチャは分析データの提供とデータの処理コードのリリースをドメインごとに独立させる。スケールするため、このアーキテクチャドメインチームが運用データAPIや分析データAPIをデプロイすることに関して、自立性を支援する。
角度名員は一つ以上の運用APIと分析APIを持つ。 f:id:wata101wata:20210121222205p:plain また、ほかのドメインAPIにあるドメインが依存していることもある。例えば、”ポッドキャストドメインは”ユーザ”ドメインの"ユーザーアップデート"分析APIを、ポッドキャストのリスナーとユーザデモグラフィックを結合するため、利用していることもあるだろう。 f:id:wata101wata:20210121222422p:plain

Data as a product

現在の分析データアーキテクチャでは、次のことに多大なコストがかかる。データ見つけること、データを理解すること、データ信頼すること、データの品質を担保することである。データメッシュにおいて、ドメインが増加するにつれてこれらの問題は悪化する。ここでData as a product(製品としてのデータ)の原則が必要となる。データを製品として扱い、消費者を顧客とみなすことにより、これらの問題に対処する。
製品としてのデータが満たす性質はこちらの記事に述べられている。製品してのデータを扱うチームは、ドメインデータプロダクトオーナーを設けるべきである。この役職は、データが製品としてデリバリされることを保証するための測定に責任がある。この測定はデータ品質、データを使い始められるまでのリードタイム、データの消費者の満足度などを含む。ドメインデータプロダクトオーナーは、だれがそのデータを分析するのか、どのように使うのかに深い理解を持たなければならない。また、データのユーザとデータプロダクトオーナーが会話することにより、データプロダクトのインターフェースを構築していく。
ドメインはデータプロダクトデベロッパーを含み、その人はそのドメインデータを開発し、メンテナンスし、提供することに責任を持つ。データプロダクトデベロッパーは運用を担当するエンジニアと一緒に仕事をする。これにより、従来と比較して、データのオーナーシップが上流へと移動する。

論理アーキテクチャ:データプロダクトはアーキテチュラルクオンタムである

ドメインが自律的に製品としてのデータを提供し消費することを支援するため、データメッシュはデータプロダクトをアーキテクチュラルクオンタムとみなす。アーキテクチュラルクオンタムは、独立に変更可能なシステムの最小単位である。
データプロダクトは、次の3つのコンポーネントを持つ。

  • コード:コードは次の3つを含む。(a)データをドメイン運用システムから受けて、処理して提供するためのコード、(b)APIとして提供するためのコード、(c)アクセスコントロールポリシー、コンプライアンス、来歴を追跡するためのコード
  • データとメタデータ:データは分析データと履歴データである。メタデータは計算内容、シンタックスの定義、質の指標などを含む。
  • インフラストラクチャ:ストレージへのアクセス、データプロダクトのビルド、デプロイ、実行を可能にする。 f:id:wata101wata:20210122212224p:plain 次の図はアーキテクチャクオンタムとしてのデータプロダクトを表現する。 f:id:wata101wata:20210122212424p:plain f:id:wata101wata:20210122212433p:plain

セルフサービスデータプラットフォーム

データプロダクトをビルドし、実行し、モニターし、アクセスするためには、かなりの量のインフラストラクチャが必要である。しかし、このインフラストラクチャをプロビジョニングするスキルは専門的で、各ドメインで複製するのは難しい。各ドメインのチームがデータプロダクトを自律的に所有するためには、データプロダクトのライフサイクルの煩雑さを取り除くインフラストラクチャが必要である。ここで新たな原則を紹介する。ドメインの自律のためのセルフサービスデータインフラストラクチャである。
このインフラストラクチャで使われる技術は、今日のサービス運用のためにのものとは異なる。例えば、ドメインチームはdockerコンテナをサービスとしてデプロイし、kuberbetsをオーケストレーションのためにプラットフォームとして使うかもしれない。しかし、データプロダクトではdatabricksクラスタでsparkジョブとしてパイプラインを実行するだろう。データメッシュではこの2つの異なるインフラストラクチャを接続する必要がある。 セルフサービスデータインフラストラクチャは、ドメインデータプロダクトデベロッパーがより少ないコストで専門性がなくてもデータプロダクトを開発・運用することを支援しなければならない。セルフサービスデータインフラストラクチャが満たすべき性質はこちらにまとめられている。

論理アーキテクチャ:マルチプレーンデータプラットフォーム

セルフサービスプラットフォームは複数のプレーンに分割される。 f:id:wata101wata:20210122223940p:plain セルフサービスプラットフォームは複数のプレーンを持ち、異なる機能を提供する。例えば、

  • データインフラストラクチャプロビジョニングプレーン:データプロダクトのコンポーネントを実行するのに必要なインフラストラクチャのプロビジョニングを支援する。これは。分散ファイルシステム、ストレージアカウント、データプロダクト内部コードのオーケストレーション、データプロダクトのグラフ上の分散クエリエンジンのプロビジョニングなどを含む。このプレーンは、ほかのデータプラットフォームプレーンまたは高度なデータプロダクトデベロッパーのみが直接使用する。かなり低レベルのデータインフラストラクチャプレーンである。
  • データプロダクトデベロッパーエクスペリエンスプレーン:これはデータプロダクトデベロッパーがメインで使うプレーンである。これは、シンプルな宣言型インターフェースをデータプロダクトのライフサイクルを管理するために使う。これはすべてのデータプロダクトとインターフェースに適用される、全社的な基準を満たすように実装する。
  • データメッシュ監督プレーン:データプロダクトの接続を提供する機能をもつプレーン。例えば、特定のユースケースのためのデータプロダクトを発見することは、データプロダクトのメッシュを検索することで提供される。もしくは、さらに高い視点のインサイトを得るために複数のデータプロダクトを掛け合わせることは、メッシュ上の複数のデータプロダクトを横断してセマンティッククエリを実行することで提供される。 f:id:wata101wata:20210122230849p:plain

連合計算ガバナンス

データメッシュでは独立したチームが独立したデータプロダクトをそれぞれのライフサイクルで開発・運用する。しかし。いくつかのデータプロダクトを統合して分析する場合には、それらが結合処理などが簡単にできるよう統一されている必要がある。データメッシュは次のようなガバナンスモデルをもつ。ドメインの自己主権、全社での標準化による相互運用性、動的トポロジー、プラットフォームによる意思決定の自動実行である。これを連合計算ガバナンスとよぶ。ドメインデータプロダクトオーナーとデータプラットフォームオーナーによって、すべてのデータプロダクトに適用されるグローバルルールを決める。難しい点としては、中央化と地方分権化のバランスをとることだ。ある規則を全社に適用するのか、そのドメインだけに適用するのかは適切に考える必要がある。

論理アーキテクチャ:メッシュに埋め込まれた計算ポリシー

連合計算ガバナンスには、支援的な組織構造、インセンティブモデルが必要である。 f:id:wata101wata:20210123110833p:plain 前述したとおり、何を全社基準として実装し、何を各ドメインに任せるかのバランスを決めるのは、アートである。例えば、データの用語の定義は全社で決めるべきだが、データの構造はドメインごとで決めるべきである。連合計算ガバナンスのインセンティブは各データプロダクトを相互運用可能にすることであり、各ドメインインセンティブはそのドメインのデータプロダクトの消費者を増やすことである。 f:id:wata101wata:20210123111426p:plain これは従来の中央集権データ管理チームが、データに対してゴールデンスタンダードを決めるのとは異なる。あくまで、各ドメインの自律性を支援しつつ、それらの代表者が集まるものとして連合計算ガバナンスがある。次の図は、中央化されたデータ(データレイク、データウェアハウス)とデータメッシュでのデータガバナンスの違いである。

中央化されたデータのガバナンス観点 データメッシュガバナンス観点
中央化したチーム 連合したチーム
データの質に責任を持つ データの質を定義することに責任を持つ(質自体は各ドメインの責任)
データセキュリティに責任を持つ データセキュリティの観点を定義することに責任を持つ
規律を順守する責任がある  規律がをどう守るかを定義することに責任を持つ
データの一元管理 ドメインの連合によりデータを管理する
多義語の正規化を行う 複数のドメインにわたる多義語の定義をする
ドメインから独立している ドメインの代表者で構成される
明確に定義されたデータの静的構造を目指す メッシュが動的にトポロジーを変えることにより効率的な運用を可能にすることを目指す
モノシリックなデータレイクやデータウェアハウスといった技術 ドメインで使用されるセルフサービスプラットフォームの技術
どれだけ多くのデータを管理できたかが成功指標 メッシュのネットワークが効率的かが成功指標
人手で介入 プラットフォームに自動処理を埋め込む
エラーを防ぐ  エラーを検知しプラットフォームの自動処理で回復する

まとめ

f:id:wata101wata:20210123120553p:plain

感想

  • データプロダクトオーナーいいですね!例えば、MLを用いたマーケティングができるデータがあるってことも、そもプロダクトの競争力になると思うので、プロダクト側の責任としてドメインデータ活用を推し進める役割も必要になるのですね。

  • あとは、この記事の観点を具体的にどのようなツールで実現するかまとめていきたいですね。セルフサービスデータプラットフォームつくりたいです。