メインコンテンツまでスキップ

🧩 Data Mesh

✅ このスタイルの概要​

組織のデータを「分散したプロダクト」として扱い、ドメインチームに所有権と責任を持たせるデータアーキテクチャ。

✅ 解決しようとした問題​

  • 中央集権型 DWH/Lake のボトルネック
  • データ基盤チームへの要求集中（データ要求が捌けない）
  • ドメイン知識不足によるデータ品質問題

✅ 基本思想・ルール​

  1. ドメイン指向のデータ所有
  2. データプロダクト思考（SLO・品質・API）
  3. セルフサービスデータプラットフォーム
  4. 標準化されたインターフェースとガバナンス

✅ 得意なアプリケーション​

  • 大規模組織でのデータ分散管理
  • 事業部ごとの独立した分析基盤運用
  • データカタログ・データ API を活用する環境

❌ 不向きなケース​

  • 小規模な組織（分散のメリットが薄い）
  • ガバナンス組織や SLO 運用の文化がない場合

✅ 歴史​

  • Zhamak Dehghani による提唱
  • Data Lake / Warehouse の限界に対する設計思想的アプローチ

✅ 関連スタイル​

✅ 代表的なフレームワーク​

  • Databricks / Lakehouse Platform
    データプロダクト単位の管理に向いたプラットフォーム。

  • Snowflake + Data Marketplace
    データシェアリングを前提とした Mesh 的運用が可能。

  • AWS Glue / Athena + Lake Formation
    分散したデータプロダクトのメタデータ・アクセス権を統一管理。

  • Data Catalog（Amundsen / DataHub / Collibra）
    データ検索・オーナーシップ管理を行う Mesh 必須コンポーネント。

✅ このスタイルを支えるデザインパターン​

Data Mesh は組織構造のパターン寄りだが、技術的には次が関連する。

  • Facade
    データ API やデータプロダクトの“入口”として機能する。

  • Mediator
    プラットフォームが各データプロダクト間を調停する役割を担う。

  • Strategy
    ドメインごとに異なる処理方式・保持形式を選択できる柔軟性。

  • Iterator
    分散データを横断的に扱う際の抽象に利用されることがある。

✅ まとめ​

Data Mesh は中央集権型データ基盤の限界に対し、
ドメインチームがデータをプロダクトとして所有し、
分散協調しながら全体最適を図るアーキテクチャ思想 である。

大規模組織向けであり、データプロダクト管理・ガバナンス・SLO 運用が不可欠である。