データ メッシュ アーキテクチャ: エンタープライズ向けの分散型データ

集中型データ ウェアハウスは、30 年間にわたって主要なエンタープライズ データ アーキテクチャでした。このモデルでは、中央のデータ エンジニアリング チームが企業のデータ インフラストラクチャを所有し、ソース システムからデータを取り込み、データをクリーニングして変換し、中央のウェアハウスまたはデータ レイクを通じて消費者に提供します。ビジネス チームは新しいデータを要求し、中央チームがデータを提供するのを待ち、組織のすべてのデータ ニーズに対して単一の中央チームが行った優先順位の決定を受け入れます。

このモデルは、データ量が管理可能で、データ ソースが限られており、ビジネスの変化のペースが遅い場合には、かなりうまく機能しました。数千のデータ ソース、中央チームの帯域幅を奪い合う数十の分析ユース ケース、および四半期ではなく数日で測定されるデータ アクセスを必要とするビジネス チームを特徴とする現代のエンタープライズ環境では、これはひどく失敗します。

データ メッシュは、これらの制限に対するアーキテクチャ的および組織的な対応です。データの所有権をプラットフォーム チームに集中させるのではなく、データを最もよく知っているビジネス ドメイン、つまりデータを生成するチームに所有権を分散します。データを運用の副産物として扱うのではなく、消費者、品質基準、サービス レベルを備えた製品として扱います。

重要なポイント

• データ メッシュは、データの所有権を中央のデータ チームに集中させるのではなく、ドメイン チームに分散します。
• 4 つの原則: ドメイン所有権、製品としてのデータ、セルフサービス データ インフラストラクチャ、フェデレーテッド コンピューティング ガバナンス
• データ メッシュは、集中型データ アーキテクチャのスケーラビリティ、品質、俊敏性の問題を解決します
• 導入には技術プラットフォームへの投資と大幅な組織変更の両方が必要です
• セルフサービス データ インフラストラクチャ プラットフォームは技術基盤です。これがなければ、ドメイン チームはデータを効果的に所有できません。
• フェデレーション ガバナンスにより、中心的なボトルネックを再生成することなく一貫性とコンプライアンスを確保
• データ メッシュによって中央データ チームが排除されるわけではありません。データ メッシュの役割がプロデューサーからプラットフォーム プロバイダーおよびイネーブラーに変わります。
• ほとんどの組織は、最も負担の大きいドメインから始めて段階的にデータ メッシュを実装する必要があります。

---

一元化されたデータ アーキテクチャの問題

データ メッシュが企業の関心をこれほどまでに高めた理由を理解するには、大規模な集中型アーキテクチャの特有の問題点を理解する必要があります。

中央チームのボトルネック

集中型モデルでは、データ エンジニアリング チームがすべてのデータ パイプラインを所有します。すべての新しいデータ ソースを統合するには、中央チームの努力が必要です。新しい分析ユースケースにはすべて、中央チームの開発時間が必要です。データ品質の問題はすべて、中央チームによって診断され、修正される必要があります。

組織が成長し、データの使用例が急増すると、中央チームがボトルネックになります。ビジネスチームはデータ統合まで 2 ～ 6 か月待ちます。中央チームには根本原因を診断するためのドメイン コンテキストがないため、データ品質の問題が解決されないままになります。分析への取り組みは、他の優先事項と競合するデータ インフラストラクチャの作業によって遅れています。

キューはチームの成長を超える速さで増大します。中央データ エンジニアを追加しても根本的な問題は解決されません。根本的なアーキテクチャ上の問題は残ったまま、ボトルネックが一時的に遅くなります。

ドメインの専門知識のギャップ

中央データ チームはパイプラインの構築方法を知っています。彼らは、処理しているデータのビジネス セマンティクスを知りません。販売領域とサービス領域の文脈における「顧客」とは何を意味しますか?フルフィルメント ドメインにおける「完了した」注文とは何ですか?サブスクリプション製品販売の正しい収益認識ルールは何ですか?

ドメインの専門家、つまりデータを生成するビジネス チームは、この知識を持っています。中央チームはそうではない。この専門知識のギャップにより、修復者にはエラーを理解するためのコンテキストが欠けているため、診断と修復が困難なデータ品質の問題が発生します。

矛盾と信頼性の低さ

さまざまなチームがソース システムから直接データを抽出し、ローカル データ ストアを構築し、部門レベルのスプレッドシートを維持するなど、独自の回避策を構築すると、中心となる「唯一の信頼できる情報源」が崩壊します。 「収益」や「アクティブ顧客」などの複数のバージョンの指標がチーム間で急増しており、定義には小さいながらも重大な違いが生じています。

ビジネスリーダーはデータを信頼することをやめ、直感に立ち戻り、データ主導の意思決定に抵抗します。それは概念を拒否しているからではなく、データが信頼できないからです。

---

データメッシュの 4 つの原則

ThoughtWorks在籍中の2019年に「データメッシュ」という用語を作ったZhamak Dehghani氏は、それを4つの原則を通じて定義した。

原則 1: データのドメイン所有権

データ メッシュでは、ビジネス ドメインが生産、品質、公開などのデータを所有します。販売ドメインは販売データを所有します。サプライ チェーン ドメインは、在庫とフルフィルメント データを所有します。顧客ドメインは、顧客プロファイルとエンゲージメント データを所有します。

ドメインの所有権とは、ドメイン チームが、公開するデータの品質、データを生成するパイプライン インフラストラクチャ、消費者向けに提供するサービス レベルに責任を負うことを意味します。データが間違っている場合、ドメイン チームはそれを修正します。彼らはそれを行うための説明責任とドメインの専門知識の両方を持っています。

これは、すべてのドメイン チームがデータ エンジニアリング チームになるという意味ではありません。セルフサービス データ インフラストラクチャ プラットフォーム (原則 3) は、あらゆるドメインにおけるデータ エンジニアリングの深い専門知識を必要とせずに、ドメインの所有権を実用化するツールを提供します。

原則 2: 製品としてのデータ

データ メッシュでは、データは他の製品と同様に、消費者、品質基準、ドキュメント、サービス レベルを含む製品として扱われます。

データ製品は、次のような制限されたデータ資産です。

• 明確な所有権を持っています (ドメイン チーム)
• 発見可能である (消費者はデータカタログを通じて見つけることができます)
• 文書化されている（消費者は内容と使用方法を理解している）
• 品質基準がある（正確さ、完全性、適時性が測定され、維持されます）
• 定義されたサービス レベル (鮮度、可用性、アクセス遅延) がある
• 明確に定義されたインターフェイスがある (消費者はソース システムにアクセスするのではなく、定義された API またはクエリ インターフェイスを通じてデータにアクセスします)

「製品」という考え方によって、ドメイン チームが公開するデータについての考え方が変わります。データ パイプラインは実装の詳細です。データ製品は消費者に役立つものであり、維持する必要があります。このフレーミングの変化により、品質と信頼性に関するさまざまな動作が引き起こされます。

原則 3: セルフサービスのデータ インフラストラクチャ

ドメインによるデータの所有権は、専門的なデータ エンジニアリングの専門知識を必要とせずに、データ パイプラインの開発、品質の監視、データ製品の公開を可能にするツールをドメインが備えている場合にのみ現実的です。

セルフサービス データ インフラストラクチャ プラットフォームは以下を提供します。

• データ パイプライン ツール: データ エンジニアリングの深い専門知識がなくても、ドメイン エンジニアが使用できるローコードまたは構成主導のパイプライン開発
• データ品質フレームワーク: ドメインが構成および監視できる自動品質テスト、異常検出、品質スコア ダッシュボード
• データ カタログの統合: メタデータ抽出によるエンタープライズ データ カタログへの新しいデータ製品の自動登録
• アクセス制御: IT 部門の関与なしでドメインが構成できるポリシーベースのアクセス管理
• 消費インターフェイス: どのドメインがデータを生成したかに関係なく、消費者が使用できる標準化されたクエリ インターフェイス (SQL、API)
• 監視と可観測性: パイプラインの健全性監視、データ鮮度ダッシュボード、およびドメイン チームが操作できるアラート

このプラットフォームの構築は、データ メッシュへの主な技術投資です。それがなければ、データ メッシュは機能を有効にすることなく責任を分散させ、権限を付与するのではなく混乱を招くことになります。

原則 4: 連合コンピューティング ガバナンス

データ所有権を分散化することは、ガバナンスを放棄することを意味するものではありません。データ メッシュは、ドメインがローカルに適用される中央で定義された標準であるフェデレーション ガバナンスを使用します。

中央ガバナンス機能は、データ品質標準、セキュリティおよびプライバシー ポリシー、相互運用性標準 (共通データ形式、識別子標準)、法規制遵守要件、およびすべてのデータ製品が準拠する必要があるデータ カタログ スキーマを定義します。

ドメインは、データ製品内でこれらの標準を実装します。ガバナンス機能は、手動レビューではなく自動ポリシー適用を通じてコン​​プライアンスを検証します。

「コンピュータによる」ガバナンスとは、手動の承認プロセスではなく、コードを通じてガバナンス ポリシーが自動的に適用されることを意味します。アクセス制御はプラットフォームによって適用されます。データ品質基準は自動テストによって検証されます。セキュリティ ポリシーはインフラストラクチャによって適用されます。これにより、ガバナンスが拡張可能になります。中央チームがすべてのデータ製品を手動でレビューする必要がなくなります。

---

データ メッシュ アーキテクチャの実践

データドメイン設計

データ ドメインの設計は、最初の実際的な課題です。ドメインの境界は、明確なデータ責任とビジネス コンテキストの所有権を持つ組織単位であるビジネス ドメインの境界と一致する必要があります。

一般的なドメイン設計パターン:

運用ドメイン: 既存のビジネス ユニット (販売、マーケティング、財務、運用、人事、サプライ チェーン) と一致します。各ドメインは、運用システムによって生成されたデータを所有します。

顧客ドメイン: 集約された顧客プロファイル データは、専任の顧客データ チームが所有することが多く、共通の横断的ドメインです。

分析ドメイン: 組織によっては、特定の分析目的のために複数の運用ドメインからのデータを集約する専用の分析ドメイン (営業、業務、財務からのデータを結合する財務分析ドメイン) を作成する場合があります。

ドメイン境界は、ドメイン間の依存関係を最小限に抑えるために描画する必要があります。ドメインのデータの大部分が別のドメインから取得されている場合、境界の再描画が必要になる場合があります。

データプロダクトの構造

データ メッシュ実装のデータ製品には通常、次のものが含まれます。

入力データ: イベント ストリーム (Kafka)、API 呼び出し、またはデータベース レプリケーションを介して消費される、運用システムからのソース データ。

変換コード: 生のソース データをパブリッシュされたデータ製品に変換するパイプライン ロジック。通常は、CI/CD デプロイメントを使用してバージョン管理のコードとして管理されます。

出力インターフェイス: データがコンシューマーに提供される形式 (共有クエリ レイヤー内のテーブル、API エンドポイント、イベント ストリーム、マテリアライズド ビュー)。

品質契約: 定義およびテストされた品質基準 - NULL レート、鮮度要件、参照整合性チェック、ビジネス ルールの検証。

メタデータ: スキーマ定義、データ ディクショナリ、系統情報、および運用ドキュメント - データ カタログに自動的に登録されます。

可観測性: パイプラインの健全性モニタリング、鮮度ダッシュボード、品質スコア追跡。

技術プラットフォームの選択

データ メッシュ実装スタックは、組織、クラウド プラットフォーム、既存のツールによって大きく異なります。

データ カタログ: Atlan、Collibra、Alation、DataHub (オープンソース)、Google Dataplex、AWS Glue データ カタログ。データ製品の検出可能性レイヤーを提供します。

データ品質: Great Expectations (オープンソース)、モンテカルロ、ソーダ、アノマロ。自動化されたデータ品質テストと異常検出。

パイプライン オーケストレーション: dbt (データ変換)、Apache Airflow、Prefect、Dagster。ドメインがパイプラインを構築するために使用するデータ変換およびパイプライン オーケストレーション ツール。

クエリ レイヤー: Databricks Unity Catalog、Snowflake、BigQuery、Amazon Redshift。消費者が複数のドメインからデータ製品をクエリするために使用する共有分析クエリ レイヤー。

アクセス管理: Apache Ranger、AWS Lake Formation、Databricks Unity Catalog。ドメイン全体にわたるポリシーベースのアクセス制御。

イベント ストリーミング: Apache Kafka、AWS Kinesis、Google Pub/Sub。ストリーミング消費者向けのリアルタイム データ製品インターフェイス。

---

Analytics および Power BI との統合

データ メッシュ アーキテクチャは、分析チームが利用するドメイン所有のデータ基盤を提供します。データ メッシュと分析ツールの間のインターフェイスは重要です。

データ メッシュ + Power BI

データ メッシュ アーキテクチャでは、Power BI は共有クエリ レイヤー (通常はレイクハウス (Databricks、Azure Synapse、Microsoft Fabric) またはデータ ウェアハウス (Snowflake、BigQuery、Redshift)) を介してドメイン データ製品に接続します。

ドメイン データ製品は、クエリ レイヤーのテーブルまたはビューとして公開されます。 Power BI セマンティック モデル (データセット) は、これらのドメイン データ製品の上に構築されます。データ利用者 (アナリスト、ビジネス ユーザー) は、基礎となるデータを生成したドメインを理解する必要なく、セマンティック モデルに基づいてレポートを作成します。

Microsoft Fabric の OneLake は、データ メッシュ アーキテクチャに特に適しています。これは、ドメイン チームがデータ製品を公開できる統合ストレージ レイヤーと、Power BI やその他の分析ツールが使用する共有クエリ レイヤーを提供します。 Microsoft Fabric のドメイン レベルのワークスペースは、データ メッシュ ドメインの境界と自然に一致します。

分析のためのデータリネージ

成熟したデータ メッシュで最も価値のある機能の 1 つは、エンドツーエンドのデータ リネージです。これは、データ製品、変換、ソース システムを通じて、分析レポート内のすべての数値の起源を追跡することです。

Power BI レポートに予期しない収益数値が表示された場合、データリネージによって迅速な診断が可能になります。収益指標はどのデータ製品に由来するのか?どのドメインがそれを所有していますか?どのような変換ロジックがそれを生み出したのでしょうか?最終的な起源はどのソースシステムでしたか?

リネージ機能を備えたデータ カタログ ツール (Atlan、Collibra、DataHub) は、このリネージの可視性を提供し、分析のトラブルシューティングを劇的に迅速かつ効果的にします。

---

組織変革

データ メッシュは、技術的な変革であると同時に、組織的な変革でもあります。技術的なアーキテクチャは比較的迅速に構築できます。組織の変革にはさらに時間がかかります。

役割の変更

中央チームのデータ エンジニア: 役割は、本番データ パイプラインの構築から、セルフサービス データ インフラストラクチャ プラットフォームの構築と保守に移行します。プロデューサーからプラットフォームビルダーへ。これは慎重な管理が必要な有意義なキャリア移行です。

ドメイン チームのデータ エンジニア: 新しい役割 — ビジネス ユニットに組み込まれ、ドメイン データ製品の構築と保守を行うドメイン データ エンジニア。データ エンジニアリングのスキルとドメイン ビジネスの知識の両方が必要です。

データ アナリスト: 役割がさらに強力になります。検出可能で高品質なドメイン データ製品により、アナリストはデータの取得とクリーニングに費やす時間が減り、分析により多くの時間を費やすことができます。そのためには、データ スキルとともに、より強力な分析スキルを開発する必要があります。

データ プロダクト オーナー: 新しい役割 — データ プロダクト ロードマップを所有し、消費者との関係を管理し、データ品質への取り組みに責任を負うドメイン チームのメンバー。プロダクト マネージャーの役​​割と同様に、データに適用されます。

中央データ ガバナンス チーム: 役割は、データ品質の修復からガバナンス標準の設定と施行へと移行します。問題解決者から政策立案者へ。

変更管理の考慮事項

ドメイン データの所有権は、ドメイン チームが必ずしも望んでいるわけではない責任です。 「データを生成するのは私たちです。なぜ私たちがデータ エンジニアリングの責任を負わなければならないのでしょうか?」は一般的な反応です。その答えを得るには、ドメインの所有権により、チームが自らのデータの運命を制御できるようになり、イテレーションの高速化、品質の向上、中央キューへの依存の軽減が可能になると同時に、データを実質的に管理可能にするセルフサービス ツールを提供できることを実証する必要があります。

上級リーダーの連携が不可欠です。データ メッシュでは、ドメイン リーダーは運用上の責任とともにデータ品質に対する責任も受け入れる必要があります。リーダーレベルでのこの取り組みがなければ、ドメインチームは、たとえコントロールを望んでいたとしても、その責任に抵抗することになります。

---

よくある質問

データ メッシュは中小企業に適していますか、それとも大規模組織にのみ適していますか?

データ メッシュは、中央データ アーキテクチャのボトルネックが実際のビジネス上の苦痛を引き起こしている組織、つまり 10 を超える重要なデータ生成ドメイン、実質的な分析ユース ケース、需要に対応できない中央データ チームを抱える組織に最も有益です。データ ソースが少なく、分析ニーズが単純な小規模組織の場合は、適切に構造化された集中型データ ウェアハウスの方が適している可能性があります。データ メッシュは組織的およびアーキテクチャの複雑さを追加しますが、それが正当化されるのは、データ メッシュによって解決される問題がビジネスの成果を本当に制限している場合に限られます。

データ メッシュの実装にはどれくらいの時間がかかりますか?

大企業の現実的なデータ メッシュ実装タイムライン: セルフサービス データ インフラストラクチャ プラットフォームの構築に 6 ～ 12 か月、最初の 3 ～ 5 つのドメイン データ製品が運用可能になるまでに 12 ～ 18 か月、ほとんどの主要ドメインをカバーするプログラムに 24 ～ 36 か月。組織は、ドメイン チームにデータ エンジニアを組み込み、ドメイン プロダクト オーナーをトレーニングし、データ所有権を中心としたドメイン チームの文化を変えるなど、ドメイン チームの能力構築にどれくらいの時間がかかるかを現実的に評価する必要があります。データ メッシュ プラクティスへの組織全体の変革には通常 3 ～ 5 年かかりますが、初期のドメイン実装から最初の 1 年で有意義な価値が提供されます。

データ レイク、データ ウェアハウス、データ レイクハウス、データ メッシュの違いは何ですか?

データ レイクは、生データをネイティブ形式で保存するストレージ リポジトリです。データ ウェアハウスは、分析クエリ用に最適化された構造化された統合データ ストアです。データ レイクハウスは、データ レイクのストレージ エコノミーと、データ ウェアハウスのクエリ パフォーマンスおよびガバナンスを組み合わせます。データ メッシュは、ストレージ テクノロジではなく、アーキテクチャおよび組織的なアプローチです。データ メッシュは、データがどのように所有、生成、管理されるかを説明します。データ メッシュは、データ レイク、ウェアハウス、またはレイクハウスのテクノロジー基盤上に実装できます。最新のデータ メッシュ実装では、データ レイクハウス (Databricks、Microsoft Fabric、Snowflake) を共有クエリ レイヤーとして使用します。

データ メッシュはマイクロサービス アーキテクチャとどのように関係しますか?

データ メッシュは、マイクロサービス アーキテクチャの原則をデータ管理に適用します。具体的には、ドメインの所有権、限定されたコンテキスト、独立した展開可能性の考え方です。マイクロサービスがモノリシック アプリケーションをドメイン所有のサービスに分解するのと同じように、データ メッシュは中央データ プラットフォームをドメイン所有のデータ製品に分解します。この類似は組織構造にも当てはまります。マイクロサービスが開発者、運用、製品管理を含む部門横断的なチームによって所有されるのと同じように、データ製品はデータ エンジニア、ドメイン専門家、データ製品所有者を含む部門横断的なドメイン チームによって所有される必要があります。

最も一般的なデータ メッシュ実装の失敗は何ですか?

最も一般的な失敗パターン: 十分な投資なしでセルフサービス プラットフォームを構築する (ツールなしでドメインに責任が与えられ、混乱が生じる)。続行する前にドメイン リーダーの同意を得ることができなかった (ドメイン チームは、リーダーからの組織的なコミットメントがなければ所有権に抵抗します)。データ メッシュを純粋にテクノロジーへの取り組みとして扱う (ドメイン所有権を持続可能にする組織変更管理を無視する)。そして、すべてのドメインにわたってデータ メッシュを同時に実装しようとします (組織全体にわたる同時変更の複雑さにより、通常は実装が失敗します。2 ～ 3 つの負担の大きいドメインから始めて、スケーリングがより成功する前にモデルを証明する必要があります)。

---

次のステップ

データ メッシュは、集中型モデルのスケーリング、品質、俊敏性の制限に対処するエンタープライズ データ アーキテクチャの根本的な再考を表します。データのボトルネックに悩まされている組織にとって、スケーラブルでドメインに適したデータ所有権への道を提供します。

ECOSIRE の Power BI および分析サービス は、組織がデータ メッシュ アーキテクチャの上に位置する分析レイヤーを設計および実装するのに役立ち、ドメイン データ製品を意思決定者に洞察を提供するビジネス インテリジェンス ツールに接続します。私たちのチームは、データ アーキテクチャ戦略と、データ メッシュへの投資をビジネス価値に変える分析実装の両方についてアドバイスできます。

分析およびデータ アーキテクチャ チームにお問い合わせ、データ メッシュが組織のデータ課題に対する適切なアプローチであるかどうかについて話し合ってください。