About

この記事は、「Data Mesh」について書かれたものです。参考文献に記載された内容をベースとして、個人的な感想や意見を加えたものです。 事例ではありません。

TL;DR

• Data Mesh はデータ基盤の新しいアーキテクチャ原則であり、現在主流である中央集中型のデータ基盤と、そこから起こる問題への解決策です。
• Data Mesh はマイクロサービスと DDD から着想を得ており、データの生成・管理・提供を中央ではなくドメインごとに管理します。
• 管理が分散することでスケーラビリティ・自律性を確保しつつ、統一的なガバナンスを保持できるアイデアです。

主な想定読者

• Data Mesh が気になる方
• データ基盤を開発・保守するデータエンジニア
• データマネジメントをより洗練させたいと感じている方

Data Mesh の登場した背景 (WHY)

詳細に入る前に、Data Mesh が前提に置く現代のデータ基盤アーキテクチャと、その課題についてまとめます。

現代のデータ基盤アーキテクチャと課題

Zhamak Dehghani によると、現代のデータ基盤は中央に集中されたモノリシックなものです。

この中央の DataLake や、ETL、DataMart/DWH を生成するパイプラインの開発／管理は特定のプロダクトチームに属さないチーム（基盤チームと呼ぶ）のデータエンジニアがしています。

このアーキテクチャの課題は、責務が中央に集中しており、スケーラビリティが欠けていることです。

Zhamak Dehghani は、3 つの "Architectural failure modes" として、現代のアーキテクチャの問題点を指摘しています。

1. 中央集権でモノリシックな基盤 (Centralized and monothlic)
2. パイプラインのステージごとでの分割 (Coupled pipeline decomposition)
3. サイロ化された基盤チーム (Siloed and hyper-specialized ownership)

これらにより起こる具体的な問題は以下のようなものです。

• 新しいデータパイプラインの開発は基盤チームとの調整コストや、基盤チームが別チームのタスクを抱えているとすぐには着手できないといった事情により、スピードが出ない
• パイプラインは挿入・加工・サービングの３つのステージが疎結合に分解されているが、例えば新しいデータを活用したい場合、挿入・加工・サービングすべてに変更を加える必要があり、実際は結合度が高い。
• データ処理はプロダクトチームが自分たちで完結できるのが最も効率的だが、基盤を触るには特殊な「データエンジニアスキル」が必要となり、ハードルが高い。

サービスは DDD などにより綺麗に責務分解されていても、データに関してはデータレイクに入れた瞬間にオーナーシップが手放されてしまいコントロールが思うにようにできなくなる、ということも述べられています。

しかしながら、中央集権的なデータ基盤ではなく、各ドメインに任せたときには以下のようなガバナンスの問題が出てきてしまいます。

• 各ドメインで車輪の再発明のようなことが必要となる
• データの保存・変換・提供の方法が各ドメインでバラバラになり、ドメインをまたいだデータ活用がしづらくなる
• アクセスコントロールなどのセキュリティ観点の対策がドメイン任せとなり、リスクが増大する

Data Mesh が解決を試みる点

上記のように、現代のデータ基盤はスケーラビリティの問題を抱えている一方、単純に解消しようとするとガバナンスの問題が浮上してきてしまいます。

Data Mesh は、まさにこういった板挟みの状況を脱却し、 スケーラビリティとガバナンスの両方を得るアーキテクチャ として提案されています。

具体的にはどのようなものか、以下で確認しましょう。

Data Mesh とは (WHAT)

簡潔に述べると、「Data As A Product」として、データの保存・変換・提供を各ドメインの責務としつつ、それらの基盤は「Data Infrastructure」により構成することで速度と標準化を担保するというものです。

アーキテクチャ

アーキテクチャとしては以下のようなイメージです。物理的なアーキテクチャではなく、概念図として捉えてください。

最初にお見せしたアーキテクチャとは随分違いますね。ポイントは以下 2 点です。

• 中央のデータレイクがなく、各ドメインが、保有するデータの ETL・提供 (インターフェースは SQL/API など利用者次第) を担っている
• 各ドメインは、必要なデータを中央データレイクではなく各ドメインから直接提供されている
• 共通部分として Data Infrastructure がおり、ここが標準化やディスカバリを担保している。

Data As A Product

Data Mesh では、データをプロダクト（もしくはマイクロサービス）として捉え、各ドメインチームが自身が保有するデータの管理に責任を持ちます。

責任範囲には以下のようなものが含まれます。

• 別ドメインが使いやすいようなデータ提供 (API, DB など)
• 上記に伴う ETL
• データ信頼性の確保・管理
• アクセスコントロール
• スキーマの記述やデータカタログへの登録

また、このようなデータプロダクトを扱うチームには、それ相応のクロスファンクショナルチームが求められます。具体的には、データプロダクト  のライフサイクルや品質について責任を持つ「データプロダクトオーナー」や技術的な面を支援するデータエンジニアが必要となります。

Zhamak Dehghani は、

software generalists must add the experience and knowledge of data product development to their tool belt

と書いており、従来の SWE がデータエンジニアリングスキルを獲得することを想定しているようです。

Data Infrastructure

上記のデータプロダクトが「Self Served」であるというのも Data Mesh の重要なキーワードです。

何もない状態で Data Mesh に進むと車輪の再発明とサイロ化が待っていることは明白なので、それを防ぐために共通コンポーネントや規約を用意します。そうすることで、各ドメインでデータエンジニアリングに関するディープな知識がなくともある程度簡単にデータプロダクトを実装できるようにしつつ、標準化を確保することが可能となります。

Intuite の Data Mesh 事例 によると、DomainEventService や Pipeline、Data Quality Service など多くの共通コンポーネントを用意しているようです。

Data Mesh をいつ適用すべきか (WHEN)

Data Mesh について簡潔にまとめられたWhat is a Data Mesh — and How Not to Mesh it Upでは、以下の観点で点数をつけ、Data Mesh に適しているかどうかを測る質問が用意されています。是非お試しください。

• データソースの数
• データチームのサイズ
• ドメインの数
• データエンジニアリングからくるボトルネックやペインの頻度
• データガバナンスのプライオリティ

Data Mesh をどう実装すべきか (HOW)

Data Mesh を試しているという事例は少なく、標準といえる実装パターンはないようです。

ただ、2020 年に出版された「Data Management At Scale」は、まさに Data Mesh 実装のヒントを示していると感じました。

この本でも、キーとなるアイデアは責任分離とそこから得られるスケーラビリティです。OOP や DDD が重要な思想として紹介されています。

その他、以下のようなキーワードについても言及があります。

• 品質確保と周知のための、Data Delivery Contract と Data Sharing Agreement を作る
• Streaming
• Data Security
• Metadata
• Golden source

興味ある方は是非読んでみてください。 (ボリュームあります)

以上、Data Mesh についてまとめてみました。まだコンセプトが提示されているという段階だと思うので、これからどう実装・適用されていくか期待です。