データメッシュ Q&A
分析屋の下滝です。
データメッシュを勉強し始めました。
まだ理解不足ですが（そして全部読めてませんが）、Q＆A形式で整理しておくと役立つかもしれないので、整理していく記事にしたいと思います。徐々に増やしていきます。
エンジニアとしては、技術的な視点で、これまのでデータウェアハウスやデータレイクといった中央集権的なデータアーキテクチャのアプローチだとどうして駄目なのかという視点での理解のほうがわかりやすいと思いますので、そういう視点でのものが多くなるかもしれません。
Q.データメッシュの原則間に何か関係はありますか
はい、関係があります。
データメッシュは、以下の4つの原則で説明がされています。
・ドメイン主導のデータ所有権（Domain Ownership）
・プロダクトとしてのデータ（Data as a product）
・セルフサービス型のデータプラットフォーム（Self-serve data platform）
・コンピューテーショナルな連携型の統制（Federated computational governance）
『Data Mesh』の図1-2でこれらの原則の関係が示されています。
たとえは、「ドメイン主導のデータ所有権」の原則に基づくと、データのサイロ化という問題が発生します。この問題を解決するのが「プロダクトとしてのデータ」という原則になります（図での (1)）。
Q.一つのドメインには一つのデータプロダクトだけが存在しますか
いいえ。ドメインには、複数のデータプロダクトがあってかまいません。
Each domain can have multiple data products.
Q.データメッシュとドメイン駆動設計、マイクロサービスはどのように関係しますか
データメッシュは、ドメイン駆動設計とマイクロサービスが適用されていることを前提としているように読めます。
Data mesh adopts the boundary of bounded contexts to individual data products --- data, its models, and its ownership.
For organizations that have already adopted a microservices or domain-oriented architecture this is a relatively simple extension. They have built services based on the domain bounded contexts. Now, they apply the same decomposition and modeling to their analytical data in each domain.
データメッシュは、データ、そのモデル、その所有権といった個々のデータ製品に、境界付けられたコンテキストの境界を採用する。
すでにマイクロサービスやドメイン指向アーキテクチャを採用している組織にとっては、これは比較的簡単な拡張となる。ドメインによって境界付けられたコンテキストに基づいてサービスを構築している。であるなら、同様の分割とモデリングを各ドメインにおける分析データに対して適用できる。
Q.データメッシュのゴールはなんですか。これまでのアプローチのどんな問題点を解決するのですか。
データメッシュのゴールは次のように表現されています。翻訳が間違っているような気がしますので、注意してください。
Ultimately, data mesh's goal is to enable organizations to get value from data at scale, using data to not only improve and optimize their business but also reshape it.
データメッシュの最終的なゴールは、データによりビジネスを改善・最適化するだけでなく、ビジネスを再形成することで、組織が大規模なデータから価値を引き出せるようにすることだ。
もう少し詳しく、ゴールが整理されています（p.117-118の表7-1）。大きく3つの観点から整理されています。各項目を詳しく書いている7章を参照する方が良いかもしれません。
ゴール１：複雑で、変わりやすく、不確実なビジネス環境において、データの変化を円滑に管理する。
＜そのために何をするか。どうやって行うか＞
・ビジネス、技術、データを一致させる：ビジネス、技術、データに関する横断的なチームを作り、チームが管理するデータの長期的な所有権に対して責任を持ってもらう。【ドメイン主導のデータ所有権の原則】
・業務データプレーンと分析データプレーンの間のギャップを埋める：組織全体にわたるパイプラインと２つのプレーンのデータアーキテクチャを無くし、アプリケーションとデータプロダクトを単純なパイプでより密にして統合する。【プロダクトとしてのデータの原則】
・データの変更をビジネスドメインに局所化する：特定のドメインに、データプロダクトの保守と所有権を局所化する。データの変更の影響を少なくするために、ドメイン指向のデータプロダクト間に明確なコントラクトを作成する。【プロダクトとしてのデータの原則】
・パイプラインとデータコピーの偶発的複雑性を減らす：パイプラインを分解し、必要な変換ロジックは対応するデータプロダクトに移動させ、内部実装としてそれらの変換を実行するように抽象化する。【プロダクトとしてのデータの原則】【データプロダクト量子としてのアーキテクチャコンポーネント】
ゴール2：成長の中においてアジリティを保つ
＜そのために何をするか。どうやって行うか＞
・中央集権化によるアーキテクチャのボトルネックを無くす：中央集権的なデータウェアハウスとデータレイクを無くし、データインターフェースを通じて、データプロダクト間でのピアツーピアのデータ共有を可能にする。【ドメイン主導のデータ所有権の原則】【プロダクトとしてのデータの原則】
・データパイプラインの調整を減らす：パイプラインアーキテクチャをトップレベルで機能的に分解することから、ドメイン指向のアーキテクチャの分割に移行する。ドメイン指向のデータプロダクト間には、明示的なデータコントラクトを導入する。【ドメイン主導のデータ所有権の原則】【プロダクトとしてのデータの原則】
・データガバナンスの調整を減らす：自律的なドメインとデータプロダクトオーナーに、ガバナンスの責任を委譲する。ガバナンスポリシーは、コードとして各データプロダクト量子に埋め込み、検証させることで、自動化する。【コンピューテーショナルな連携型の統制の原則】
・チームの自律性を可能にする：ドメインチームに独立して迅速に動く自律性を与える。相互運用性とメッシュのグローバルな一貫した体験を作るために、コンピューテーショナル標準とチームの自律性をバランスさせる。ドメインチームに自律性を与えるために、ドメイン特有ではないインフラの能力をセルフサービスな方法で使えるように提供する。【コンピューテーショナルな連携型の統制の原則】【セルフサービス型のデータプラットフォーム】
ゴール3：コストを超えてデータからの価値を増加させる
＜そのために何をするか。どうやって行うか＞
・データプラットフォームにより複雑性を抽象化する：データ開発と使用のジャーニーにおける摩擦と隠れたコストを削除するために、データ開発者中心で、データユーザー中心となるインフラを作成する。ベンター統合の複雑性を減らすために、データプロダクトではオープンで標準化されたインタフェースを定義する。【プロダクトとしてのデータの原則】【セルフサービス型のデータプラットフォーム】
・プロダクトシンキングを至るところに取り入れる：データユーザーと開発者の幸福をベースにした成功に焦点を置いて測定する。データとデータプラットフォームをプロダクトとして扱う。【セルフサービス型のデータプラットフォーム】【プロダクトとしてのデータの原則】
・組織の境界を超えて行動する：プラットフォームと組織の物理的および論理的な境界を越えてデータを共有し、データプロダクト全体で標準的な、またはインターネットベースのデータ共有コントラクトを使用する。【プロダクトとしてのデータの原則】【セルフサービス型のデータプラットフォーム】
Q.データプロダクトとアーキテクチャはどのような構造的な関係ですか
データプロダクトは、データメッシュアーキテクチャにおける最小単位となります。
In the case of data mesh, a data product is an architectural quantum. It is the smallest unit of architecture that can be independently deployed and managed. …
データメッシュにおいては、データプロダクトは、アーキテクチャ量子である。アーキテクチャにおける最小単位であり、独立してデプロイされ管理される。
アーキテクチャ量子の定義は、『進化的アーキテクチャ』での定義が参照されています。
『進化的アーキテクチャ』では、アーキテクチャ量子は、次のように定義されています。「アーキテクチャ量子とは、高度な機能的凝集を持つ、独立してデプロイ可能なコンポーネントだ。」
Q.データプロダクトとアウトプットポートの実装がわかりません。
『Data Mesh』では、具体的には書かれていないように読めましたが、GCPでの実装の考え方がありましたので紹介します。
スタンドアロン データ ウェアハウスの構築と、データ プロデューサー チームがデータ プロダクトを作成するドメイン データ ウェアハウスを構築することには基本的な違いはありません。2 つの唯一の違いは、後者は消費インターフェースを介してデータのサブセットを公開することです。
ここで書かれているように、データウェアハウス自体がデータプロダクトの実装方法の一つとなります。消費インターフェースというのは、データメッシュでのアウトプットポートのことだと思われます。
より具体的には次のように書かれています。
データドメインは、明確に定義されたデータ消費インターフェースを介してデータのサブセットをデータプロダクトとして公開します。データプロダクトには、テーブル、ビュー、構造化ファイル、トピック、ストリームなどがあります。BigQuery ではデータセット、Cloud Storage ではフォルダまたはバケットです。データプロダクトとして公開できるさまざま種類のインターフェースが存在します。インターフェースの例は、BigQuery テーブルに対する BigQuery ビューです。
書き方としては少し曖昧です。「データのサブセット」自体がデータプロダクトのように読めます。このサブセットは BigQuery ビューとして公開されると読めます。そして、消費インタフェース（『Data Mesh』でいうところのアウトプットポート）がBigQuery ビューに対応します。
なお、他の解釈の例として『Data Mesh in Action』では、データプロダクトとなりうるものの例があげられています。
データを使うユーザーにとって価値のあるデータ表現であればなんでもデータプロダクトの候補となると書かれています（p.134）。いくつか紹介します。
・生の非構造化ファイル：画像や動画など。
・単純なファイル：CSVなど
・データベース内のデータセット
・REST API
・データマート
また、アウトプットポートの例として次が挙げられています。
・データベースライクなストレージ
・ファイル
・（REST） API
・ストリーム
・可視化
一方で、データプロダクトの内部アーキテクチャの例としては次の図が説明されています。
なお、参考として、『Data Mesh』でのデータプロダクトの説明例は以下となっています。
データメッシュにおいては、データプロダクトは、アーキテクチャ量子の一種となる。アーキテクチャにおける最小単位であり、独立してデプロイされ管理される。高度な機能的凝集、つまり、特定の分析のための変換が実行され、結果としてのドメイン指向の分析データを安全に共有する。データプロダクトは、機能するために必要となる全ての構造的なコンポーネント、つまり、変換のためのコード、データ、メタデータ、データガバナンスのためのポリシー、インフラとの依存関係のすべてを備えている。（p.151）
Q.データメッシュにおけるアーキテクチャの構成要素は何ですか
より細かくは次のように整理されています（p.168の表9-1）。
・ドメイン
・ドメイン分析データインタフェース
・ドメイン業務インタフェース
・データ（プロダクト）量子
・データ（プロダクト）コンテナ
・データプロダクトサイドカー
・インプットデータポート
・アウトプットデータポート
・ディスカバリーとオブザーバビリティーAPI
・コントロールポート
・プラットフォームプレーン
・データインフラストラクチャユーティリティプレーン
・データプロダクトエクスペリエンスプレーン
・メッシュエクスペリエンスプレーン
Q.データメッシュにおける登場人物を教えて下さい
ペルソナ（ロール）として次のものが挙げられています（p.174）。
・データプロダクト開発者
・データプロダクトコンシューマー
・データプロダクトオーナー
・データガバナンスメンバー
・データプラットフォームプロダクトオーナー
・データプラットフォーム開発者
Q.データメッシュはどのような組織にとっても取り入れる方がいいですか
15章「戦略と実行」では、組織がデータメッシュを取り入れる準備ができるかどうかのアセスメントが解説されています。
以下の8つの視点でスコアリング（高、中、低）します。詳しくは、同書を参照してください。
・組織の複雑性
・データ指向の戦略
・経営陣のサポート
・データ技術が中心にある
・アーリーアダプター
・モダンエンジニアリング
・ドメイン指向の組織
・長期間のコミットメント
Q.既存のアーキテクチャからデータメッシュに移行するのはどうすればいいですか。
15章「戦略と実行」の中に、レガシーからのマイグレーションという節があります。
特定の状況からデータメッシュへ移行する戦略は、同書のスコープ外としていますが、著者の経験に基づいて、いくつかの教訓が述べられています。
・データメッシュと中央集権型のアーキテクチャは、同時に存在しないこと。ただし、移行期間中は存在しても良い。
・中央集権型のアーキテクチャで使われる技術は、データメッシュで使うことができる。
・データレイクとデータウェアハウスを使わず、ソースデータを扱うデータプロダクトを直接使うようにする。
・データウェアハウスはデータを消費するエッジノードとして使う
・データウェアハウスやデータレイクからの移行は、アトミックな進化のステップで行う
株式会社分析屋について
ホームページはこちら。
noteでの会社紹介記事はこちら。
【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。