分散型データ分析基盤「データメッシュ（Data Mesh）」概説（２）
５．データの流れとアーキテクチャ
データメッシュは、従来の中央集権型データ基盤とは異なるデータの流れとアーキテクチャを採用します。本章では、データの流れの変化、データメッシュにおけるアーキテクチャの構成要素、データのライフサイクル管理、およびデータ統合の新しいアプローチについて詳細に解説します。
データの流れの変化
データメッシュを導入すると、データの流れが従来のETL（Extract, Transform, Load）中心の中央集権型パイプラインから、ドメインごとの分散処理へと変化します。
従来型（中央集権型）データ基盤のデータフロー
従来のデータ基盤では、データの流れは以下のように中央に集約されていました。
- データ収集
- さまざまなアプリケーションやシステムからデータを抽出（Extract）し、中央のデータレイクやデータウェアハウスに送信。
- データ変換（ETL処理）
- データを統合・変換し、分析に適した形式へ変換（Transform）。
- ビジネスルールやデータモデルに基づき、統一されたスキーマに整理。
- データ格納
- 変換後のデータをデータウェアハウスに格納（Load）。
- すべてのデータが一元管理され、分析チームが活用。
- データ提供
- BIツールやデータサイエンスチームが、中央のデータをクエリして利用。
このアプローチは、データの更新に時間がかかり、スケーラビリティに限界がありました。また、中央データチームがボトルネックとなり、新たなデータニーズに迅速に対応できないという課題もありました。
データメッシュにおけるデータフロー
データメッシュでは、データの流れが分散型になります。ドメインごとに独立したデータパイプラインを持ち、データを製品（Data Product）として管理することで、以下のような流れが実現されます。
- データ生成・収集（ソースデータの管理）
- 各ドメインが、業務アプリケーションやIoTデバイス、ログシステムから直接データを収集。
- データはそのドメイン内で所有・管理される。
- データ変換・統合
- ドメインごとのパイプラインでデータを変換し、各ドメインのニーズに最適化。
- 必要に応じて、他のドメインのデータと統合し、分析可能な形式にする。
- データの公開・提供
- 各ドメインは、データをAPIやイベントストリームを通じて公開し、他のドメインや利用者が直接アクセスできるようにする。
- データはData Productとして管理され、利用者は標準化された方法でアクセス可能。
- データ消費
- BIツール、データサイエンスチーム、アプリケーション開発者が、セルフサービス型でデータを取得・分析。
- データカタログを活用し、適切なデータを簡単に検索・利用。
このような分散型のデータフローにより、データの鮮度や可用性が向上し、各ドメインが柔軟にデータ提供を行うことが可能になります。
データメッシュのアーキテクチャ
データメッシュのアーキテクチャは、分散型でありながら統一性を保つために、以下の主要な構成要素で成り立っています。
ドメインデータプロダクト
- 各ドメインがデータの所有者となり、データを「製品（Data Product）」として管理。
- データの提供方法、品質保証、アクセス管理を含めたパッケージ化されたデータ資産。
セルフサービス型データプラットフォーム
- データストレージ（データレイク、データウェアハウス）
- データ処理エンジン（ETL、ストリーミング処理）
- クエリエンジン（SQL、GraphQL、APIゲートウェイ）
- データカタログ・検索機能
- アクセス管理とセキュリティ機能
フェデレーテッド・コンピュテーショナル・ガバナンス
- データ品質管理、アクセス制御、セキュリティポリシーの自動化。
- ドメインごとに柔軟なルール設定を可能にしながら、全体の一貫性を確保。
データライフサイクル管理
データメッシュでは、データのライフサイクルを各ドメインが責任を持って管理します。データのライフサイクルは以下の段階で構成されます。
- データの作成（収集）
- ドメイン内の業務システムやセンサーからデータを収集。
- データの処理・変換
- 必要に応じてデータをクレンジング、集計、変換。
- スキーマ変更やデータ品質保証もこの段階で行う。
- データの公開
- APIやイベントストリームを通じてデータを他のドメインや分析チームへ提供。
- データの利用
- 各チームがセルフサービス型でデータを取得し、分析や機械学習に活用。
- データのアーカイブ・削除
- 古いデータの管理、適切なデータ保持ポリシーの適用。
データ統合の新しいアプローチ
従来の中央集権型データ基盤では、データ統合はETLパイプラインを介して実施されていました。一方、データメッシュでは、以下の新しいアプローチを採用します。
- APIによるリアルタイムデータ統合
- 各データプロダクトがAPIを提供し、必要なデータを直接取得。
- イベント駆動型アーキテクチャ
- KafkaやPub/Subを活用し、ストリームデータをリアルタイムで処理。
- 分散クエリエンジン
- Presto、Trinoなどの分散クエリエンジンを利用し、複数のドメインデータを一元的にクエリ。
データメッシュのアーキテクチャは、従来の中央集権型データ基盤と大きく異なり、ドメイン指向の分散型アプローチを採用しています。このアーキテクチャにより、データの流れがより迅速で柔軟になり、各ドメインが独立してデータを提供・管理できるようになります。
６．データメッシュに適した技術スタック
データメッシュを成功させるためには、分散データ管理、セルフサービス機能、スケーラビリティ、およびガバナンスを支える適切な技術スタックの選定が不可欠です。本章では、データメッシュの実現に必要な主要技術要素を整理し、それぞれの役割について詳しく解説します。
データメッシュに求められる技術要件
データメッシュを実装するためには、以下の技術要件を満たす技術スタックを構築する必要があります。
- 分散データ管理
- 各ドメインが独立してデータを管理し、適切に提供できるようにする。
- 一元的なデータウェアハウスへの集約を前提としない。
- セルフサービス型データプラットフォーム
- データの発見・アクセス・処理を開発者やデータアナリストが容易に行える。
- スケーラブルなデータ処理
- 大量データのストリーミング処理・バッチ処理に対応し、負荷に応じて自動スケールできる。
- データガバナンスの自動化
- フェデレーテッド・コンピュテーショナル・ガバナンスを実装し、セキュリティ・コンプライアンスを自動化。
- 標準化と相互運用性
- APIやデータカタログを活用し、データプロダクト間で容易に統合・活用できる。
データメッシュを支える主要技術スタック
データメッシュの導入には、以下の技術カテゴリが重要となります。
データストレージ
データメッシュでは、ドメインごとに最適なデータストレージを選択できる柔軟性が求められます。
| ストレージ技術 | 特徴 |
|---|---|
| データレイク (AWS S3, Azure Data Lake, GCS, Apache Iceberg, Delta Lake) | 大規模データの低コスト保存、スキーマレスで柔軟なデータ管理 |
| データウェアハウス (BigQuery, Snowflake, Amazon Redshift, Databricks SQL Warehouse) | 分析に最適化された列指向ストレージ、強力なクエリエンジン |
| NoSQLデータベース (MongoDB, DynamoDB, Cassandra) | 柔軟なデータモデル、高速クエリ、スケーラビリティ |
| 時系列データベース (InfluxDB, TimescaleDB) | IoTやログデータの時系列解析に最適 |
データメッシュでは、データプロダクトの特性に応じて最適なストレージを選択し、それぞれが相互運用可能な形で統合されることが重要です。
データ処理エンジン
各ドメインが独立してデータ処理を実行するために、以下のエンジンが利用されます。
| 処理エンジン | 用途 |
|---|---|
| Apache Spark | 大規模バッチ処理、機械学習、ETL |
| Apache Flink / Kafka Streams | ストリーミングデータ処理、リアルタイム分析 |
| dbt (Data Build Tool) | SQLベースのデータ変換・モデル化 |
| Presto / Trino | 分散クエリエンジン、異なるデータソースを横断的にクエリ |
データメッシュでは、バッチ処理とストリーミング処理の両方が求められるため、適切なツールを組み合わせる必要があります。
データ統合と API 管理
データメッシュでは、APIを介したデータのやり取りが標準となります。
| 統合技術 | 用途 |
|---|---|
| GraphQL / REST API | データプロダクト間の標準化されたデータアクセス |
| Apache Kafka / Pulsar | イベント駆動型のデータ共有、ストリーミングデータ処理 |
| Fivetran / Airbyte | データの自動取り込み・統合 |
| OpenAPI / gRPC | APIの標準化、相互運用性向上 |
APIを活用することで、データの流通がスムーズになり、データプロダクト間の依存関係が適切に管理できます。
データカタログとメタデータ管理
データメッシュでは、セルフサービス型のデータ探索とメタデータ管理が不可欠です。
| メタデータ管理技術 | 用途 |
|---|---|
| DataHub | 分散環境でのメタデータ管理、データリネージ |
| Amundsen | 検索可能なデータカタログ、データ発見機能 |
| AWS Glue Data Catalog | クラウド環境向けの統合メタデータ管理 |
| Atlas (Apache Atlas) | エンタープライズ向けデータガバナンス |
データカタログを活用することで、データの所在や利用状況が可視化され、データの発見・活用が容易になります。
フェデレーテッド・コンピュテーショナル・ガバナンス
データメッシュでは、ガバナンスの自動化が求められます。
| ガバナンステクノロジー | 用途 |
|---|---|
| IAM (Identity and Access Management) | ユーザー・ロールベースのアクセス制御 |
| OAuth / OpenID Connect | APIアクセス制御と認証統合 |
| Data Governance Tools (Collibra, Alation) | データポリシーの管理と監査 |
| Policy as Code (OPA, HashiCorp Sentinel) | ポリシーのコード化、自動適用 |
フェデレーテッドガバナンスを実装することで、分散環境においてもセキュアで統一的なポリシー管理が可能になります。
データメッシュに適した技術スタックは、従来のデータ基盤とは異なり、分散環境に適応した柔軟な技術の組み合わせが求められます。本章で紹介した技術を適切に組み合わせることで、データメッシュの強みを最大限に活かしながら、スケーラブルでガバナンスの効いたデータ管理を実現することができます。
７．データメッシュに必要なガバナンス
データメッシュの成功には、単なる技術導入だけでなく、適切な データガバナンス の実装が不可欠です。従来の中央集権型データ基盤では、一元的な管理者がデータ品質やセキュリティを保証していましたが、データメッシュでは 「フェデレーテッド・コンピュテーショナル・ガバナンス（Federated Computational Governance）」 という新しいアプローチを採用します。
本章では、データメッシュに必要なガバナンスの考え方、主要な要素、導入のポイントについて詳しく解説します。
データメッシュにおけるガバナンスの考え方
データメッシュでは、各ドメインが自らのデータプロダクトを管理し、一定のグローバルポリシーに従いながらも、独立してガバナンスを維持する ことが求められます。そのため、従来の中央集権型ガバナンスとは異なるアプローチが必要です。
従来型ガバナンスとの違い
| 項目 | 従来型ガバナンス | データメッシュのガバナンス |
|---|---|---|
| 管理方式 | 中央集権型 | 分散・フェデレーテッド |
| データの管理者 | 中央データチーム | 各ドメイン（データプロダクトオーナー） |
| データ品質保証 | データガバナンスチームが監査・管理 | 各ドメインが品質基準を定義し実装 |
| アクセス管理 | 一元的なポリシー管理 | 各データプロダクトが個別にポリシーを適用 |
| ガバナンスの実装 | 手作業・手続き中心 | 自動化・ポリシー適用のコード化（Computational Governance） |
データメッシュにおけるガバナンスの目的は、中央集権的な管理を排除しつつも、適切な セキュリティ、品質、コンプライアンス、相互運用性 を確保することです。
データメッシュのガバナンスは、大きく以下の 3つの柱 に分かれます。
- システム思考によるガバナンス（Systems Thinking）
- フェデレーテッドな運用モデル（Federated Operating Model）
- コンピュテーショナルガバナンス（Computational Governance）
システム思考によるガバナンス
データメッシュは、データプロダクト同士が相互に関連し合うエコシステム です。そのため、ガバナンスを 静的なルールの押し付け として考えるのではなく、「動的なバランスを保つための仕組み」 として設計する必要があります。
主なポイント
- ドメインの独立性と相互運用性のバランスを取る
- ガバナンスの基準を一度決めたら固定するのではなく、継続的に評価・更新する
- データプロダクトの利用状況を観測し、品質の低いものは自動的に淘汰される仕組みを作る
- 「データの一元管理」ではなく、「データ間の連携・相互活用」に着目する
例えば、データ品質が低いデータプロダクトは、利用者の評価が下がり、検索結果での表示順位が下がるなどの仕組みを導入することで、自然に淘汰される フィードバックループ を活用できます。
フェデレーテッドな運用モデル
データメッシュのガバナンスは、一元管理ではなく、ドメインごとに管理される フェデレーション型 になります。
フェデレーション型ガバナンスの主要な役割
| 役割 | 担当者 | 主な責務 |
|---|---|---|
| データプロダクトオーナー | 各ドメインの責任者 | データ品質の維持、アクセス制御の設定 |
| プラットフォームチーム | IT基盤管理者 | ガバナンスの自動化、標準APIの提供 |
| ガバナンス専門家 | セキュリティ、法務、コンプライアンス担当 | グローバルポリシーの策定 |
| ガバナンスファシリテーター | 運営支援者 | 全体のルール調整、各ドメイン間の調整 |
フェデレーション型の利点
フェデレーション型ガバナンスを採用することのメリットには次のようなものが挙げられます。
- 各ドメインが独自にデータを管理できるため、柔軟性が向上
- 標準ポリシーは全体に適用されつつ、各ドメインの独自ポリシーも許容
- データの利用促進と管理のバランスが取れる
コンピュテーショナルガバナンス
データメッシュのガバナンスは、可能な限り自動化 され、手作業による管理を最小限に抑えます。
主なコンピュテーショナルガバナンスの要素
| 項目 | 実装方法 |
|---|---|
| ポリシーのコード化（Policy as Code） | OPA (Open Policy Agent), HashiCorp Sentinel |
| データ品質の自動検証 | Great Expectations, Soda.io |
| データカタログとメタデータ管理 | DataHub, Amundsen, Apache Atlas |
| アクセス制御と監査 | IAM (Identity and Access Management), OAuth, OpenID Connect |
| データプライバシー管理 | Differential Privacy, Data Masking |
例えば、「データプロダクトが GDPR に準拠しているか？」 を手動でチェックするのではなく、データプラットフォームが自動的にデータのスキャンを行い、コンプライアンス違反を検出・通知 する仕組みを構築できます。
データメッシュのガバナンス導入ステップ
データメッシュのガバナンスを導入するには、以下のステップが必要です。
フェデレーテッド・コンピュテーショナル・ガバナンスの要素
データメッシュのガバナンスは、中央集権型ではなく、分散型・自動化型に進化 します。本章で紹介した システム思考、フェデレーション運用、コンピュテーショナルガバナンス を適切に組み合わせることで、セキュアかつ柔軟なデータ管理を実現することができます。
参考文献
- Data Mesh Delivering Data-Driven Value at Scale 2022 Zhamak Dehghani.
- Deciphering Data Architectures 2024 James Serra.