世界中の企業は、情報を収集、保存、管理するための集中型データベースの構築に全力を注いでおり、データエンジニアは、解読が困難なデータセットを、データサイエンティスト、アナリスト、消費者が利用できるデータパイプラインに変換しています。しかし、ITコンサルタント会社のThoughtWorks社の技術部長であるザマク・デハニ氏が提唱する新しいデータメッシュの概念では、ドメインチームが独立してクロスドメインのデータ分析を行うことができるようになり、 このアプローチは、データの分散化に重点を置いています。 そのアーキテクチャを掘り下げる前に、まずデータメッシュとは何か、どのように機能するかを理解していきましょう。

データメッシュとは

データメッシュは、データレイクやウェアハウスといった巨大なサイロを伴う大規模なモノリシックデータプラットフォームに対する最近の対応策です。また、運用データと分析データの間に明確な違いがあることから、「データの大きな隔たり」の結果でもあります。

データメッシュは、集中型データアーキテクチャのボトルネックに対処しようとするものです。これは、デベロッパーがソフトウェア工学で一般的に使われているドメイン駆動型デザインからヒントを得て、その概念をデータアーキテクチャの改善に利用していることを示唆しています。

データメッシュは、データ管理とスケーラビリティのためにクラウドプラットフォームの技術を採用することに重点を置いていることが重要です。
注目すべきは、データメッシュは、データ管理の目標達成のために、クラウドネイティブやクラウドプラットフォームの技術の採用を促すものであるということです。

データサイエンスの分野の専門家は、このコンセプトはマイクロサービスと比較できると考えています。マイクロサービスアーキテクチャは、アプリケーションの機能性を上げるために軽量のサービスをまとめることに重点を置いており、データメッシュは、分散型アーキテクチャと分散型ガバナンスを採用することで、データウェアハウスと似たようなことを行っています。

データメッシュアーキテクチャーの原理

データメッシュアーキテクチャは、単なるデータアーキテクチャの一種ではなく、最新のデータアーキテクチャのデザインをサポートする新しい概念であり、このアプローチでは、データ中心の概念と組織の構成が伝達されます。データメッシュの仕組みを理解するために、データメッシュアーキテクチャの4つの主要な構成要素について見てみましょう。

ドメイン指向の分散型データ所有権

ドメインとは、企業が管理する領域、あるいは知識範囲のことですが、組織内で何がドメインであるかはわかりにくいです。ただこの課題には、「ソースシステム」と呼ばれる用語を使うことで対応でき、ソースシステムは、個別のデータウェアハウスにおける出発点であり、データウェアハウス全体が基づいているデータソースと呼ぶことができます。

ザマク氏は、このようなソースシステムを、そのシステムからのデータセットが何ら変更されておらず、ビジネスで何が起こったかを明確に示していることから "現実のシステム"と呼んでいます。データの観点からだと、ドメインは、相互接続されたドメインデータセットを形成するソースシステムを結合することによって形成することができ、そのドメインデータセットが集まって、ソースドメインデータセットが形成されます。

ドメインを確定するものがハッキリとわかった後、データの所有権が登場します。ドメインは、データの取り込み、クレンジング、集計を行い、BI（ビジネスインテリジェンス）アプリ用のデータ資産を作成する、データ管理の責任を負います。

注意すべきは、データメッシュは、「データプロダクトオーナー」と「データエンジニア」というドメイン内の2つの主要な役割の間でデータの所有権を提供する点です。データプロダクトオーナーはデータプロダクトの青写真を作成しますが、この役割は、ユーザーが受信したデータに満足するということであり、顧客満足を目的としています。なのでデータプロダクトオーナーは、ユーザーのペルソナを理解し、そのニーズを常に把握しておく必要があるのです。

データエンジニアの役割は、ドメイン内のデータプロダクトの構築に重点を置くことであり、この役割は、ソフトウェアエンジニアリングの専門知識とデータエンジニアリングチームのスキル、特にAWS GlueやDatastageなどのETLソリューションのコンピテンシーを兼ね備えています。

目的は、ソフトウェアアーキテクチャで用いられるドメイン駆動型デザインの概念をデータアーキテクチャに適用して分析的なデータプロダクトを作成することであり、その結果、多くの関係者が協力して優れたデータを提供する「分散型アプローチ」となっています。

製品としてのデータ

戦略的な観点から見ると、「製品としてのデータ」は、中央のデータチームというよりは、別々のチームに組織のデータの所有権を与えるものです。 データプロダクトはデータメッシュアーキテクチャの中心であり、BIを用いて開発され、すべての必須質問に対する答えを提供します。

したがって、データ製品は「データ客」によって使用され、ビジネスをデータ駆動にするには不可欠なものです。データ客とは、組織内でのタスクや機能の達のためにデータを必要とする個人を指し、例えば、アナリストは予測モデリングのために特定のデータを必要とするかもしれないので、データ客となります。

つまるところ、データ製品とは、以下のいずれかを指します：

  • データファイル、ビュー、およびストリーム
  • 利用しやすい列、行、定義で構成されるメタデータ
  • システムとユーザーがデータを使ってビジネスのニーズを満たすことができるように、データアクセスの規定の概要を示すアクセス パターン (クエリパターンとも呼ばれる) 。
  • メタ部分を構成するデータ基盤とコード

要約すると、「製品としてのデータ」は、データ、メタデータ、インフラ、コードの集合体であり、ザマク氏は、データ製品には以下のような性質があるとしています：

  • 発見可能、つまりデータカタログ、レジストリ、メタデータがあり、その所有者とソースを特定できる。
  • ユーザーが確実にアクセスできるようにアドレス指定が可能であり、標準的な世界規模の規約の作成が必要。
  • データ客に出所と系統を提供するために、信頼性と真実性がある。さらに、データ所有者は、あらかじめ定められた目標を厳守することによって、データの質に責任を持つことが要求される。
  • データ客がデータ製品をセルフサービスできるようにするためには、自己記述的なセマンティックとシンタックスを持つデータスキーマが必要。
  • 必要なときにドメイン間の連携を促すために、相互運用可能で、世界基準で管理されている。この目的のために、発見性、ガバナンス、フォーマット、メタデータの標準化が必要。
  • ユーザーが安全にデータにアクセスできるように、世界規模で安全にアクセス管理されている。

プラットフォームとしてのセルフサービス型データ基盤

どの企業にも、論理的に自律したドメインがあり、そのドメインは、ビジネスプロセスや機能のサポートからデータ製品の開発まで、さまざまな目的に使われるため、データ製品の基盤となるインフラストラクチャが必要とされています。異なる企業ドメインは、このセルフサービス型のデータ基盤を利用して、データ製品を簡単に作成することができるのです。

そのため、ドメインは、サーバーのエラー、運営システムやネットワークの問題、その他の複雑な問題とは無縁であるべきです。そして中心となるIT組織は、ビジネス価値を生み出す優れたデータ製品の作成を可能にする、セルフサービス型のデータプラットフォームの提供が任されています。

このプラットフォームはドメインに依存しないため、各ドメインに応じたカスタマイズが可能であり、そのプラットフォームを活用することで、各ドメインのエンジニアは、干渉やベンダーの制約を受けることなく、エンドツーエンドのソリューションを作成することができます。さらに、それによってデザインの効率化や、わかりやすいデータプロダクトの作成が可能になります。

セルフサービス型のデータ基盤プラットフォームは、分析に最適です。分析プラットフォームには事欠きませんが、その多くはデータへのアクセスや共有の面で拡張性に欠けるものです。この提案するプラットフォームだと、データアナリスト、エンジニア、科学者などの、データ製品を作成・管理する様々なデータ客に分析データが分散的に提供されます。

さらに、セルフサービス型分析で、組織の従業員がデータに基づいた意思決定を行えるようになります。

連合型自動ガバナンス

データプラットフォームによってセルフサービス分析へのアクセスがより広範囲になり、データサイエンスやエンジニアリングのバックグラウンドを持たない従業員でも重要なデータを利用できるようになると、セーフガードの導入が不可欠になります。さらに、従来のデータガバナンスでは、データを通じて十分な価値を生み出せない可能性もあります。

データメッシュは、データのガバナンスにおけるパラダイムシフトを提唱しています。その考え方は、ガバナンスを中央集権的ではなく、連合体的なものにするというものあり、データの品質とセキュリティを維持する責任は、ビジネスドメインにあることを示唆しています。その一方で、中央の統治機関の役割は、データ品質とセキュリティのためのフレームワークやガイドラインの確定に限定されます。

そのため、このデータモデルでは、企業のデータ要件を満たすために、ドメインチームと中央のデータガバナンスチームの連携が必要であり、また、ドメインがセキュリティ標準やガイドラインに準拠した独自のデータパイプラインの構築に使用できる、共有データのインフラストラクチャレイヤーにも重点を置いています。 連合型自動ガバナンスにより、各ドメインはインフラを一から構築しなくていいのです。

APIがデータメッシュに不可欠な理由

APIにより、組織はそのデータメッシュにアクセスすることができます。APIでデータ構造、セキュリティ構造、クエリメソッドを指定するための一貫した方法が提供される、つまり、APIでデータ消費者が組織のデータメッシュ内のデータを検索し、消費することができるのです。
さらに、データメッシュアーキテクチャでは、すべてのCFT（クロスファンクショナルチーム）がデータのライフサイクル全体に責任を負い、マイクロサービスを構成する各ドメインに、独自のファイルストレージシステムとOLAP（オンライン分析処理）データベースがあるということになります。そしてマイクロサービスは、HTTP REST APIを通じてすべてを公開し、データドメインは、他のチームが簡単にアクセスできるデータを公開するために効率的なインターフェースを採用します。


Integrate.ioのデータメッシュにより、洗練された透明性の高い API を作成することができます。14日間の無料トライアルはこちらから。

関連記事
Is Data Mesh or API Management Right For You?