データメッシュは、データをプロダクト(このドキュメントではデータ プロダクトと呼びます)として扱うアーキテクチャおよび組織フレームワークです。このフレームワークでは、データを完全に理解し、組織全体の一連のデータ ガバナンス基準に従うチームによって、データ プロダクトが開発されます。データ プロダクトがデータメッシュにデプロイされると、組織内の分散チームは、ニーズに関連するデータを迅速かつ効率的に検出してアクセスできます。このようなデータメッシュを適切に機能させるには、まずこのドキュメントで説明するアーキテクチャ コンポーネントと組織のロールの概要を理解する必要があります。
このドキュメントは、Google Cloud でデータメッシュを実装する方法を説明するシリーズの一部です。ここでは、Google Cloud での最新の分散型データメッシュの構築で説明されているコンセプトを理解していることを前提としています。
このシリーズは、次のパートから構成されています。
- データメッシュのアーキテクチャと関数(このドキュメント)
- データメッシュ用のセルフサービス データ プラットフォームを設計する
- データメッシュでデータ プロダクトを構築する
- データ メッシュでデータ プロダクトを検出して使用する
このシリーズでは、説明するデータメッシュは組織内部にあります。データ メッシュ アーキテクチャを拡張してデータ プロダクトをサードパーティに提供することは可能ですが、そのような拡張的な手法についてはこのドキュメントでは説明しません。データメッシュを拡張する場合は、組織内での使用だけでなく、その他の考慮事項も考慮する必要があります。
アーキテクチャ
このシリーズで説明するアーキテクチャ コンポーネントを定義する際は、次の重要な用語を使用します。
- データ プロダクト: データ プロダクトは、1 つ以上の関連データリソースの論理コンテナまたはグループです。
- データリソース: データリソースは、構造化データを保持するストレージ システム内の物理アセット、または構造化データを生成するクエリを保存する物理アセットです。
- データ属性: データ属性は、データリソースのフィールドまたは要素です。
次の図は、Google Cloud に実装されたデータメッシュの主なアーキテクチャ コンポーネントの概要を示しています。
上の図は、次のことを示しています。
- セントラル サービスを使用すると、データメッシュ参加者に影響を与える組織のポリシー、(Identity and Access Management グループによる)アクセス制御、インフラストラクチャ固有のアーティファクトなどのデータ プロダクトの作成と管理が可能になります。このようなコミットメントと予約、データメッシュの機能を容易にするインフラストラクチャについては、プラットフォーム コンポーネントとソリューションを作成するをご覧ください。
- セントラル サービスは主に、データメッシュ内のすべてのデータ プロダクトに Data Catalog を提供し、これらのプロダクトのユーザーに対して検出メカニズムを提供します。
- データドメインは明確に定義されたデータ消費インターフェースを通じて、データのサブセットをデータ プロダクトとして公開します。これらのデータ プロダクトにはテーブル、ビュー、構造化ファイル、トピック、ストリームなどがあります。BigQuery ではデータセット、Cloud Storage ではフォルダまたはバケットになります。データ プロダクトとして公開できるさまざま種類のインターフェースが存在します。インターフェースの例として、BigQuery テーブルの BigQuery ビューがあります。分析目的で最も一般的に使用されるインターフェースの種類については、データメッシュでデータ プロダクトを構築するをご覧ください。
データメッシュのリファレンス実装
このアーキテクチャのリファレンス実装は、data-mesh-demo
リポジトリにあります。リファレンス実装で使用されている Terraform スクリプトは、データメッシュのコンセプトを示していますが、本番環境での使用は想定していません。これらのスクリプトを実行すると、次のことができるようになります。
- プロダクトの定義と基礎となるデータを分離する。
- プロダクトのインターフェースを記述するための Data Catalog テンプレートを作成する。
- これらのテンプレートを使って、プロダクトのインターフェースにタグ付けする。
- プロダクトの消費者に権限を付与する。
プロダクトのインターフェースについては、リファレンス実装では、次のインターフェース タイプを作成して使用します。
- BigQuery テーブルの承認済みビュー。
- Pub/Sub トピックに基づくデータ ストリーム。
詳細については、リポジトリの README ファイルをご覧ください。
データメッシュの機能
データメッシュを適切に動作させるには、データメッシュ内でタスクを実行するユーザーに明確なロールを定義する必要があります。所有権はチームのアーキタイプまたは関数に割り当てられます。これらの機能は、データメッシュで作業するユーザーのコアユーザー ジャーニーを保持します。ユーザー ジャーニーを明確に説明するために、ユーザーロールに割り当てられています。これらのユーザーロールは各企業の状況に応じて分割または結合できます。組織内の従業員やチームに直接ロールをマッピングする必要はありません。
データドメインはビジネス ユニット(BU)または企業内の機能と連携します。ビジネス ドメインの一般的な例としては、銀行の住宅ローン部門や企業の顧客部門、流通部門、財務部門、人事部門などがあります。概念的には、データ メッシュにはデータ プロデューサー チームとデータ コンシューマ チームの 2 つのドメイン関連の機能があります。1 つのデータドメインが同時に両方の機能を処理する可能性が高いことを理解することが重要です。データドメイン チームは、自身が所有するデータからデータ プロダクトを生成します。また、チームはデータ プロダクトを利用してビジネスに関する分析情報を入手し、他のドメインで使用するため派生データ プロダクトを生成します。
データメッシュには、ドメインベースの機能に加えて、組織内の一元管理されたチームによって実行される一連の機能もあります。これらの一元管理されたチームは、クロスドメインの監視、サービス、ガバナンスを提供することで、データメッシュの運用を可能にします。これによりデータ プロダクトの作成と消費におけるデータドメインの運用の負担が軽減され、データメッシュの運用に必要なクロスドメイン関係が容易になります。
このドキュメントでは、データメッシュ固有のロールを持つ機能についてのみ説明します。プラットフォームに採用されているアーキテクチャに関係なく、企業で必要なロールは他にもいくつかあります。ただし、これらの他の役割についてはこのドキュメントでは説明しません。
データメッシュの主な 4 つの機能は次のとおりです。
- データ ドメインベースのプロデューサー チーム: ライフサイクル全体でデータ プロダクトを作成し、維持します。これらのチームは多くの場合、データ プロデューサーと呼ばれます。
- データドメイン ベースのコンシューマー チーム: データ プロダクトを検出し、さまざまな分析アプリケーションで使用します。これらのチームは、データ プロダクトを使用して新しいデータ プロダクトを作成できます。これらのチームは多くの場合に、データ コンシューマーと呼ばれます。
- 一元管理されたデータ ガバナンス チーム: データ プロデューサー間でデータ ガバナンス ポリシーを定義して適用し、コンシューマーに対してデータ品質とデータの信頼性を確保します。このチームは多くの場合に、「データ ガバナンス チーム」と呼ばれます。
- 一元管理されたセルフサービス インフラストラクチャ プラットフォーム チーム: データ プロデューサーにセルフサービス データ プラットフォームを提供します。このチームは、データ コンシューマーとデータ プロデューサーの両方が使用する、一元的なデータ検出とデータ プロダクトのオブザーバビリティのためのツールも提供しています。このチームは多くの場合に「データ プラットフォーム チーム」と呼ばれます。
考慮する必要があるその他の任意の機能は、データメッシュのセンター オブ エクセレンス(COE)の機能です。COE の目的はデータメッシュを管理することです。COE は、他の機能によって発生した競合を解決するための指定された仲裁チームでもあります。この機能は、他の 4 つの機能を接続する場合に活用できます。
データ ドメインベースのプロデューサー チーム
通常、データ プロダクトはデータの物理リポジトリ(単一または複数のデータ ウェアハウス、レイク、ストリーム)の上に構築されます。従来のデータ リポジトリを作成して維持するには、組織に従来のデータ プラットフォームのロールが必要です。ただし、従来のデータ プラットフォームのロールは通常、データ プロダクトを作成するユーザーではありません。
これらの物理リポジトリからデータ プロダクトを作成するには、データ エンジニアやデータ アーキテクトなど、さまざまなデータ実務者が必要です。次の表に、データ プロデューサー チームに必要なドメイン固有のユーザーロールを示します。
ロール |
業務内容 |
必要なスキル |
求めている結果 |
---|---|---|---|
データ プロダクト オーナー |
|
データ分析 データ アーキテクチャ プロダクト管理 |
|
データ プロダクト テクニカル リード |
|
データ エンジニアリング データ アーキテクチャ ソフトウェア エンジニアリング |
|
データ プロダクトのサポート |
|
ソフトウェア エンジニアリング サイト信頼性エンジニアリング(SRE) |
|
データドメイン対象分野の専門家(SME) |
|
データ分析 データ アーキテクチャ |
|
データオーナー |
|
|
|
データ ドメインベースのコンシューマ チーム
データメッシュでは、データ プロダクトを使用するユーザーは通常、データ プロダクト ドメイン外のデータユーザーです。これらのデータ コンシューマは、中央のデータカタログを使用して、ニーズに関連するデータ プロダクトを見つけます。ニーズは複数のデータ プロダクトで満たされることもあるため、データ コンシューマは最終的に複数のデータ プロダクトにサブスクライブする可能性があります。
データ コンシューマがユースケースに必要なデータ プロダクトを見つけられない場合は、データメッシュ COE に直接相談する必要があります。データ コンシューマは相談時にデータニーズについて提起し、1 つ以上のドメインでそのニーズを満たす方法についてアドバイスを求めることができます。
データ コンシューマはデータ プロダクトを探す際、永続的な分析ダッシュボードやレポート、個々のパフォーマンス レポート、その他のビジネス パフォーマンス指標など、さまざまなユースケースを実現できるデータを求めます。また、データ コンシューマは人工知能(AI)や機械学習(ML)のユースケースで使用できるデータ プロダクトを探している場合もあります。このようなさまざまなユースケースを実現するには、データ コンシューマは次のようなデータ実務者ペルソナを組み合わせる必要があります。
ロール |
業務内容 |
必要なスキル |
求めている結果 |
---|---|---|---|
データ アナリスト |
単一ドメインまたはクロスドメインのデータ プロダクトを検索、識別、評価、サブスクライブして、ビジネス インテリジェンス フレームワークの運用の基盤を構築します。 |
アナリティクス エンジニアリング ビジネス分析 |
|
アプリケーション デベロッパー |
ドメイン内外の 1 つ以上のデータ プロダクトでデータを使用するためのアプリケーション フレームワークを開発します。 |
アプリケーション開発 データ エンジニアリング |
|
データ可視化スペシャリスト |
|
要件分析 データの可視化 |
|
データ サイエンティスト |
|
ML エンジニアリング アナリティクス エンジニアリング |
|
中央データ ガバナンス チーム
データ ガバナンス チームによって、データ プロデューサーとコンシューマは、組織にコンプライアンス リスクをもたらすことなく、セルフサービス方式でデータを安全に共有、集約、計算できます。
組織のコンプライアンス要件を満たすために、データ ガバナンス チームは次のようなデータ実務担当者で構成されます。
ロール |
業務内容 |
必要なスキル |
求めている結果 |
---|---|---|---|
データ ガバナンス スペシャリスト |
|
法務 SME セキュリティ SME データ プライバシー SME |
|
データ スチュワード(各ドメイン内) |
|
データ アーキテクチャ データ スチュワードシップ |
|
データ ガバナンス エンジニア |
|
ソフトウェア工学 |
|
一元的なセルフサービス データ インフラストラクチャのプラットフォーム チーム
セルフサービスのデータ インフラストラクチャ プラットフォーム チームまたは単にデータ プラットフォーム チームは、一連のデータ インフラストラクチャ コンポーネントの作成を担当します。分散データドメイン チームは、これらのコンポーネントを使用してデータ プロダクトを構築し、デプロイします。またデータ プラットフォーム チームは、ベスト プラクティスを推進し、新しいテクノロジーを導入する際に分散しているチームの認知負荷の軽減に役立つツールと手法を紹介します。
プラットフォーム インフラストラクチャはグローバルなオブザーバビリティ、計測、コンプライアンスの自動化のための運用ツールと簡単に統合できる必要があります。また分散型チームを成功に導くために、そのような統合を容易にできるようにする必要があります。
データ プラットフォーム チームには、分散ドメインチームと基盤となるインフラストラクチャ チームと共有する責任モデルがあります。このモデルは、プラットフォームの利用者に期待される責任と、データ プラットフォーム チームがサポートするプラットフォーム コンポーネントを示します。
データ プラットフォーム自体が内部プロダクトであるため、すべてのユースケースがサポートされているわけではありません。データ プラットフォーム チームは代わりに、優先順位の高いロードマップに従って新しいサービスと機能を継続的にリリースします。
データ プラットフォーム チームは、開発中の標準のコンポーネント セットを用意している場合があります。ただしデータ プラットフォームが提供するニーズがチームのニーズと一致しない場合、データドメイン チームは別の固有のコンポーネント セットを使用する可能性があります。データドメイン チームが別のアプローチを選択する場合は、チームが構築して維持するプラットフォーム インフラストラクチャが、セキュリティとデータ ガバナンスに関する組織全体のポリシーとガードレールを遵守していることを確認する必要があります。中央データ プラットフォーム チームの外部で開発されたデータ プラットフォーム インフラストラクチャの場合、データ プラットフォーム チームは、共同投資するか、独自のエンジニアをドメインチームに組み込みます。データ プラットフォーム チームがエンジニアの共同投資を選択するか、エンジニアを組み込むかは、組織にとってのデータドメイン プラットフォーム インフラストラクチャの戦略的重要性によって決まります。組織はデータドメイン チームによるインフラストラクチャの開発に常に関与することで、将来の再利用に向けて開発中の新しいプラットフォーム インフラストラクチャ コンポーネントを再パッケージ化するために必要な調整と技術的な専門知識を提供できます。
データ メッシュのスケールアップについて関係者からの承認を得ることを主な目的としている場合は、データメッシュの作成の初期段階で自律性を制限することが必要な場合があります。ただし自律性を制限すると、中央データ プラットフォーム チームにボトルネックが発生するリスクがあります。このボトルネックがデータメッシュのスケーリングを妨げる可能性があります。そのため、一元化に関する決定は慎重に行う必要があります。データ プロデューサーにとって、限られた利用可能なオプション セットから技術的な選択を行うほうが、自分で無制限のオプション リストを評価して選択するよりも望ましい場合があります。データ プロデューサーの自律性を促進することは、管理されていないテクノロジー環境を構築することではありません。選択の自由と標準化の適切なバランスを取り、コンプライアンスとプラットフォームの導入を促進することが目標になります。
最後に、優れたデータ プラットフォーム チームは、社内の他のメンバーに教育やベスト プラクティスを提供する中心的な情報源となります。中央データ プラットフォーム チームに推奨される、特に影響の大きいアクティビティは次のとおりです。
- 新しい機能プロジェクトの定期的なアーキテクチャ設計のレビューを促進し、開発チーム全体に共通の開発方法を提案する。
- 知識と経験を共有し、共同でベスト プラクティスとアーキテクチャ ガイドラインを定義する。
- エンジニアが適切なツールを導入して、コードの問題やバグ、パフォーマンスの低下などの一般的な落とし穴を検証、チェックできるようにする。
- 開発チームが内部ツールのニーズに対する要件を明確にできるように、内部のハッカソンを開催する。
中央データ プラットフォーム チームの役割と責任の例を次に示します。
役割 | 責務 | 必要なスキル |
求めている結果 |
---|---|---|---|
データ プラットフォーム プロダクト オーナー |
|
データ戦略と運用 プロダクト管理 関係者の管理 |
|
データ プラットフォーム エンジニア |
|
データ エンジニアリング ソフトウェア エンジニアリング |
|
プラットフォームとセキュリティ エンジニア(ネットワーキングやセキュリティなど、一元管理された IT チームの代表者。データ プラットフォーム チームに組み込まれています) |
|
インフラストラクチャ エンジニアリング ソフトウェア エンジニアリング |
|
エンタープライズ アーキテクト |
|
データ アーキテクチャ ソリューションのイテレーションと問題解決 コンセンサスの構築 |
|
データメッシュに関するその他の考慮事項
分析データ プラットフォームのアーキテクチャには複数のオプションがあり、オプションごとに前提条件が異なります。各データメッシュ アーキテクチャを有効にするには、このセクションで説明するベスト プラクティスに従うことをおすすめします。
プラットフォームの資金調達
ブログ投稿「If you want to transform start with finance」で説明されているように、プラットフォームは完了していません。常に優先順位の高いロードマップに基づいて動作しています。したがって、プラットフォームは固定エンドポイントを持つプロジェクトではなく、プロダクトとして資金を調達する必要があります。
データメッシュの最初の導入者が費用を負担します。通常、費用はデータメッシュを開始する最初のデータドメインを形成する企業と、一般に中央データ プラットフォーム チームを擁する中央技術チームとで分担されます。
財務チームが中央プラットフォームの資金調達を承認するよう説得するには、一元化されたプラットフォームの価値が徐々に実現されることを示すビジネスケースを作成することをおすすめします。その価値は個々のデリバリー チームに同じコンポーネントを再実装することで得られます。
データメッシュに必要な最小限のプラットフォームを定義する
データメッシュに実用最小限のプラットフォームを定義するために、1 つ以上のビジネスケースで試験運用とイテレーションを行うことをおすすめします。試験運用で必要なユースケースと、結果として得られるデータ プロダクトを採用する準備ができているコンシューマが存在するユースケースを見つけます。ユースケースではデータ プロダクトを開発するための資金がすでにあるはずですが、技術チームからの情報提供が必要になるはずです。
試験運用を実装するチームが、データメッシュの運用モデルを次のように理解していることを確認してください。
- バックログ、サポート、メンテナンスはビジネス(データ プロデューサー チーム)が行う。
- 中央チームはセルフサービス パターンを定義し、ビジネスによるデータ プロダクトの構築を支援するが、完了したデータ プロダクトの実行と所有を企業に任せる。
- 主な目標は事業運営モデル(ドメインによる本番環境、ドメインでの使用)を証明することである。2 つ目の目標は、技術的な運用モデル(中央チームが開発したセルフサービス パターン)を証明することである。
- プラットフォーム チームのリソースは限られているため、トランクチームとブランチチーム モデルを使用して知識をプールし、専用のプラットフォーム サービスとプロダクトの開発を可能にする。
また、次のことをおすすめします。
- サービスや機能を有機的に進化させるのではなく、ロードマップを計画する。
- 取り込み、保存、処理、分析、ML にわたる実用最小限のプラットフォーム機能を定義する。
- データ ガバナンスを個別のワークストリームとしてではなく、すべてのステップに組み込む。
- ガバナンス、プラットフォーム、バリュー ストリーム、チェンジ マネジメント全体で最小限の機能を実装する。最小限の機能とはビジネスケースの 80% を満たす機能。
データメッシュと既存のデータ プラットフォームとの共存を計画する
データメッシュを実装する多くの組織には、データレイク、データ ウェアハウス、またはその両方の組み合わせなどの既存のデータ プラットフォームがすでに存在する可能性があります。データメッシュを実装する前に、データメッシュの成長に合わせて既存のデータ プラットフォームを進化させる方法を計画する必要があります。
このような組織は、次のような要因を考慮する必要があります。
- データメッシュで最も効果的なデータリソース。
- 既存のデータ プラットフォーム内に留める必要があるアセット。
- アセットを移動する必要があるかどうか、既存のプラットフォームで維持したままデータメッシュに参加できるかどうか。
次のステップ
- クラウド トポロジの設計と運用の詳細について、Google Cloud アーキテクチャ フレームワークで確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。