（非推奨）データメッシュ ユーザーガイド

警告: Google Cloud Cortex Framework のデータメッシュ機能は非推奨となり、無効になりました。この変更は、 Google Cloudのデータ マネジメント サービスの進化に伴うものです。データメッシュ ソリューションは、メタデータ管理に Data Catalog を使用して構築されました。これは、より高度な Knowledge Catalog に置き換えられています。Knowledge Catalog は、統合 API、強化されたメタデータ機能、新しい機能を備え、より包括的なデータ ガバナンス エクスペリエンスを提供します。

Cortex Framework のデータメッシュは、データ基盤を拡張して、BigQuery メタデータと Knowledge Catalog を通じてデータ ガバナンス、検出可能性、アクセス制御を可能にします。これは、カスタマイズ可能なメタデータ リソースと BigQuery アセット アノテーションの基本セットを提供し、必要に応じてデータ基盤とともにデプロイすることで実装されます。これらの基本仕様は、Cortex Framework Data Foundation を補完するメタデータ基盤となるカスタマイズされた構成を提供します。このガイドに進む前に、データメッシュのコンセプトをご覧ください。

このページで説明する手順は、Cortex Framework 用にデータメッシュを構成するために特別に設計されています。データメッシュ ディレクトリ セクションで、各ワークロードに固有のフォルダ内にあるデータメッシュ構成ファイルを見つけます。

警告: このデータメッシュ ガイドは、時間の経過とともに変更される可能性があります。フィードバックや問題については、Cortex チームにお問い合わせください。

図 1. Cortex Framework のデータメッシュ アーキテクチャ。

デザイン

Cortex のデータメッシュは、全体的なデータ基盤と同様に設計されており、Cortex またはユーザーが管理するさまざまなサブコンポーネントを含む 3 つのフェーズで構成されています。

1. ベースリソース仕様の更新: リリースごとに、Cortex はベースリソース仕様を更新し、データメッシュに標準化されたメタデータ基盤を提供します。
2. リソース仕様のカスタマイズ: デプロイ前に、ユーザーは特定のユースケースと要件に合わせてリソース仕様をカスタマイズできます。
3. データメッシュのデプロイと更新: ユーザーは、Cortex 構成ファイルでデータメッシュを有効にできます。Cortex のデプロイ中にデータアセットの後にデプロイされます。さらに、ユーザーはデータメッシュを個別にデプロイして、さらに更新することもできます。

図 2. Cortex Framework のデータメッシュ設計。

データメッシュ ディレクトリ

各ワークロードとデータソースの Data Mesh ベース構成ファイルは、次の場所にあります。ディレクトリには異なるファイル構造が含まれていますが、すべての仕様は config フォルダの下に同様に配置されています。

ワークロード	データソース	ディレクトリ パス
運用	SAP ECC	src/SAP/SAP_REPORTING/config/ecc
	SAP S/4 HANA	src/SAP/SAP_REPORTING/config/s4
	Salesforce Sales Cloud（SFDC）	src/SFDC/config
	Oracle EBS	src/OracleEBS/config
マーケティング	CM360	src/marketing/src/CM360/config
	Google 広告	src/marketing/src/GoogleAds/config
	Meta	src/marketing/src/Meta/config
	Salesforce Marketing Cloud（SFMC）	src/marketing/src/SFMC/config
	TikTok	src/marketing/src/TikTok/config
	YouTube（ディスプレイ＆ビデオ 360 を使用）	src/marketing/src/DV360/config
	Google アナリティクス 4	src/marketing/src/GA4/config

注: データメッシュ は、LiveRamp または Dun & Bradstreet（環境、社会、企業統治）のデータをサポートしていません。

メタデータ リソースは、 Google Cloud プロジェクトごとに 1 つの YAML ファイルを使用してデータソース レベルで定義され、すべてのリソースのリストが含まれます。ユーザーは、必要に応じて、既存のファイルを拡張したり、そのディレクトリ内にリソース仕様を追加した YAML ファイルを作成したりできます。

アセット アノテーションはアセットレベルで定義され、ディレクトリ内の多くの YAML ファイルが含まれます。ファイルごとに 1 つのアノテーションが含まれます。

API を有効にして権限を確認する

データメッシュのデフォルト値を変更すると、説明以外の機能を実装できます。説明以外の機能を実装するために config.json でデータメッシュのデフォルト値を変更する必要がある場合は、必要な API と確認権限が次の表に示すように設定されていることを確認してください。データ基盤を使用してデータメッシュをデプロイする場合は、デプロイするユーザーまたは Cloud Build アカウントに権限を付与します。デプロイに異なるソース プロジェクトとターゲット プロジェクトが含まれている場合は、これらの機能が使用されている両方のプロジェクトで、これらの API と権限が有効になっていることを確認します。

機能	権限ロール	ドキュメント
BigQuery アセットと行アクセス	BigQuery データオーナー	詳細については、アセットロールの必要なロールと、行ロールの必要な権限をご覧ください。
BigQuery の列アクセス	ポリシータグ管理者	詳細については、列レベルのアクセス制御で使用されるロールと列レベルのアクセス制御によるアクセス制限のドキュメントをご覧ください。
カタログタグ	Data Catalog TagTemplate オーナー	詳細については、Data Catalog を使用して BigQuery テーブルにタグ付けすると Data Catalog IAM のドキュメントをご覧ください。
Knowledge Catalog レイク	Dataplex 編集者	詳細については、レイクを作成するのドキュメントをご覧ください。

注: Cortex データメッシュでは、Managed Service for Apache Spark と Managed Service for Apache Spark metastore API の統合は必要ありません。

基本リソース仕様について

Cortex の データメッシュ を構成するための プライマリ インターフェース は、ベースリソース仕様です。これは、デプロイされるメタデータ リソースと アノテーション を定義する、すぐに使用できる YAML ファイルのセットです。ベース仕様は、初期の推奨事項と構文例を提供しますが、ユーザーのニーズに合わせてさらにカスタマイズすることを目的としています。これらの仕様は、次の 2 つのカテゴリに分類されます。

• メタデータ リソース。さまざまなデータアセットに適用できます。たとえば、ビジネス ドメインでアセットにタグを付ける方法を定義するカタログタグ テンプレートなどです。
• メタデータ リソースを特定のデータアセットに適用する方法を指定するアノテーション。たとえば、特定のテーブルを Sales ドメインに関連付けるカタログタグ。

以降のセクションでは、各仕様タイプの基本的な例と、それらをカスタマイズする方法について説明します。ベース仕様には ## CORTEX-CUSTOMER のタグが付けられています。関連するデプロイ オプションが有効になっている場合は、デプロイに合わせて変更する必要があります。高度な用途については、src/common/data_mesh/src/data_mesh_types.py でこれらの仕様スキーマの正規定義をご覧ください。

メタデータ リソース

メタデータ リソースは、プロジェクト内に存在する共有エンティティであり、多くのデータアセットに適用できます。ほとんどの仕様には、次の条件に従う display_name フィールドが含まれています。

• Unicode の文字、数字（0 ～ 9）、アンダースコア（_）、ダッシュ（-）、スペース（ ）のみを使用してください。
• 先頭または末尾にスペースを使用することはできません。
• 最大文字数は 200 文字です。

display_name が ID として使用される場合もあり、その場合は追加の要件が導入される可能性があります。その場合は、正規のドキュメントへのリンクが記載されています。

デプロイが異なるソース プロジェクトとターゲット プロジェクトのメタデータ リソースを参照する場合は、プロジェクトごとに仕様を定義する必要があります。たとえば、Cortex Salesforce（SFDC）には 2 つのレイク仕様が含まれています。1 つは未加工ゾーンと CDC ゾーン用、もう 1 つはレポート用です。

Knowledge Catalog レイク

Knowledge Catalog のレイク、ゾーン、アセットは、エンジニアリングの観点からデータを整理するために使用されます。レイクには region があり、ゾーンには location_type があります。これらはどちらも Cortex のロケーション（config.json > location）に関連しています。Cortex のロケーションは、BigQuery データセットが保存される場所を定義し、単一リージョンまたはマルチリージョンにすることができます。ゾーン location_type は、これに合わせて SINGLE_REGION | MULTI_REGION に設定する必要があります。ただし、レイク リージョンは常に単一のリージョンである必要があります。Cortex のロケーションとゾーン location_type がマルチリージョンの場合は、そのグループ内の単一のリージョンをレイク リージョンとして選択します。

• 要件
  • レイク display_name は lake_id として使用され、公式の要件に準拠する必要があります。これは、ゾーンとアセットの display_name の場合も同様です。ゾーン ID は、プロジェクト内のすべてのレイクで一意である必要があります。
  • レイク仕様は単一のリージョンに関連付ける必要があります。
  • asset_name は BigQuery データセットの ID と一致する必要がありますが、display_name はよりユーザー フレンドリーなラベルにできます。
• 制限事項
  • Knowledge Catalog では、個々のテーブルではなく、BigQuery データセットを Knowledge Catalog アセットとして登録することのみがサポートされています。
  • アセットが 1 つのゾーンにのみ登録されている。
  • Knowledge Catalog は特定のロケーションでのみサポートされています。詳細については、Knowledge Catalog のロケーションをご覧ください。

lakes.yaml の次の例をご覧ください。

これらのリソースは、data_mesh_types.Lakes を指定する YAML ファイルで定義されます。

カタログ タグ テンプレート

Data Catalog タグ テンプレートを使用すると、BigQuery テーブルまたは個々の列にコンテキストを追加できます。これにより、Knowledge Catalog 検索ツールと統合された方法で、技術的な観点とビジネスの観点の両方からデータを分類して理解できます。これらは、データのラベル付けに使用できる特定のフィールドと、各フィールドに保持できる情報の種類（テキスト、数値、日付など）を定義します。カタログタグは、実際のフィールド値を持つテンプレートのインスタンスです。

テンプレート フィールド display_name はフィールド ID として使用され、クラス TagTemplate で指定された TagTemplate.fields の要件に従う必要があります。サポートされているフィールド タイプの詳細については、Data Catalog のフィールド タイプをご覧ください。

Cortex Data Mesh は、すべてのタグ テンプレートを一般公開で読み取り可能として作成します。また、タグ テンプレート仕様に level のコンセプトが追加されています。これは、タグをアセット全体、アセット内の個々のフィールド、またはその両方に適用するかどうかを定義します。有効な値は ASSET | FIELD | ANY です。これは現時点では厳密に適用されていませんが、今後の検証チェックでは、デプロイ時にタグが適切なレベルで適用されるようになる可能性があります。

次の例をご覧ください。

テンプレートは、data_mesh_types.CatalogTagTemplates を指定する YAML ファイルで定義されます。

カタログタグはテンプレートのインスタンスであり、以下のアセット アノテーションで説明します。

タグ テンプレートを使用したアセットレベルと列レベルのアクセス制御

Cortex Framework では、カタログ タグ テンプレートに関連付けられているすべてのアーティファクトに対して、アセットレベルまたは列レベルのアクセス制御を有効にできます。たとえば、ユーザーが事業部門に基づいてアセットへのアクセス権を付与する場合は、line_of_business カタログタグ テンプレートの asset_policies を作成し、ビジネス ドメインごとに異なるプリンシパルを指定できます。各ポリシーは、特定の値を持つタグとのみ一致するように使用できる filters を受け入れます。この場合、domain 値を一致させることができます。これらの filters は、等価の一致のみをサポートし、他の演算子はサポートしません。複数のフィルタがリストされている場合、結果はすべてのフィルタを満たす必要があります（例: filter_a AND filter_b）。アセット ポリシーの最終的なセットは、アノテーションで直接定義されたポリシーと、テンプレート ポリシーのポリシーの和集合です。

カタログタグを使用した列レベルのアクセス制御は、一致するフィールドにポリシータグを適用することで同様に動作します。ただし、列に適用できるポリシータグは 1 つのみであるため、優先順位は次のようになります。

1. 直接ポリシータグ: ポリシータグが列アノテーションに直接定義されている場合は、それが優先されます。
2. 一致ポリシー: それ以外の場合、アクセスは、関連付けられたカタログタグ テンプレート内のフィールドに定義されている、最初に一致するポリシーによって決定されます。

この機能を使用する場合は、カタログタグとアクセス制御リスト（ACL）のデプロイを一緒に有効または無効にすることを強くおすすめします。これにより、ACL が適切にデプロイされます。

この高度な機能の仕様については、data_mesh_types.CatalogTagTemplate の asset_policies パラメータと field_policies パラメータの定義をご覧ください。

カタログ用語集

用語集は、データアセット内の特定の列で使用される用語の辞書を提供するツールです。これらの用語は、一般的に理解されていない可能性があります。ユーザーはコンソールで手動で用語を追加できますが、リソース仕様によるサポートはありません。

ポリシーの分類とタグ

ポリシーの分類とタグを使用すると、機密データアセットに対して列レベルのアクセス制御を標準化された方法で実行できます。たとえば、特定の事業部門の PII データを制御するタグの分類があり、特定のグループのみがマスクされたデータ、マスクされていないデータを読み取ることができるか、読み取りアクセス権がまったくない場合があります。

ポリシーの分類とタグの詳細については、列データ マスキングの概要のドキュメントをご覧ください。特に次のセクションが関連しています。

• ロールの相互作用
• 承認の継承
• マスキング ルールと階層
• ポリシータグのベスト プラクティス

Cortex Framework には、ポリシー タグの指定方法と潜在的な用途を示すサンプル ポリシー タグが用意されていますが、アクセス制御に影響するリソースは、デフォルトではデータメッシュのデプロイで有効になっていません。

次の例をご覧ください。

ポリシータクソノミーは、data_mesh_types.PolicyTaxonomies を指定する YAML ファイルで定義されます。

アセットのアノテーション

アノテーションは、特定のアセットに適用されるメタデータを指定します。定義された共有メタデータ リソースを参照することもできます。アノテーションには、以下が含まれます。

• アセットの説明
• フィールドの説明
• カタログタグ
• アセット、行、列レベルのアクセス制御

注: アノテーション ファイルを変更する場合、コンソールでは説明の改行が空白としてのみレンダリングされることに注意してください。

Cortex Framework Data Foundation には、次のワークロード用に事前構成されたアノテーション（説明）が用意されています。

• SAP ECC（未加工、CDC、レポート）
• SAP S4 HANA（未加工、CDC、レポート）
• SFDC（レポートのみ）
• Oracle EBS（レポートのみ）
• CM360（レポートのみ）
• Google 広告（レポート専用ターゲット）
• Meta（レポート専用）
• SFMC（レポートのみ）
• TikTok（レポートのみ）
• YouTube（ディスプレイ＆ビデオ 360 を使用）（レポートのみ）
• Google アナリティクス 4（レポートのみ）

次の例をご覧ください。

アノテーションは、data_mesh_types.BqAssetAnnotation を指定する YAML ファイルで定義されます。

カタログタグ

カタログタグは、特定のアセットに適用されるフィールド値が割り当てられた、定義済みのテンプレートのインスタンスです。関連付けられたテンプレートで宣言されているフィールド タイプと一致する値を割り当ててください。

TIMESTAMP の値は、次のいずれかの形式にする必要があります。

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

次の例をご覧ください。

data_mesh_types.CatalogTag の仕様定義をご覧ください。

アクセス ポリシーの読み取り元とプリンシパルの指定

アクセス ポリシーを使用して、Cortex Framework の BigQuery データへのアクセスを制御します。これらのポリシーは、特定のデータアセット、アセット内の行、個々の列にアクセスできるユーザー（プリンシパル）を定義します。プリンシパルは、IAM ポリシー バインディング メンバーで定義された特定の形式に従う必要があります。

アセットレベルのアクセス

さまざまな権限を使用して、BigQuery アセット全体へのアクセス権を付与できます。

• READER: アセット内のデータを表示します。
• WRITER: アセットのデータを変更して追加します。
• OWNER : アクセスの管理を含む、アセットに対する完全な管理権限。

これらの権限は、SQL の GRANT DCL ステートメントと同等です。

ほとんどのリソースとアノテーションの動作とは異なり、上書きフラグは OWNERS ロールを持つ既存のプリンシパルを削除しません。上書きを有効にして新しいオーナーを追加すると、既存のオーナーにのみ追加されます。これは、意図しないアクセス権の喪失を防ぐための安全対策です。アセット オーナーを削除するには、コンソールを使用します。上書きすると、READER ロールまたは WRITER ロールを持つ既存のプリンシパルが削除されます。

次の例をご覧ください。

data_mesh_types.BqAssetPolicy の仕様定義をご覧ください。

行レベルのアクセス

特定の列値フィルタに基づいて、一連の行へのアクセス権を付与できます。行アクセス ポリシーを指定すると、指定したフィルタ文字列が CREATE DDL statement に挿入されます。overwrite フラグが有効になっている場合、新しいポリシーを適用する前に既存の行アクセス ポリシーがすべて削除されます。

行レベルのアクセスについては、次の点を考慮してください。

• 行アクセス ポリシーを追加すると、それらのポリシーで指定されていないユーザーは、どの行も表示できなくなります。
• 行ポリシーはテーブルでのみ機能し、ビューでは機能しません。
• 行アクセス ポリシー フィルタでパーティション分割列を使用しないでください。アセットタイプとパーティション分割された列の詳細については、関連するレポート設定の YAML ファイルをご覧ください。

行レベルのアクセス ポリシーの詳細については、行レベルのセキュリティに関するベスト プラクティスをご覧ください。

次の例をご覧ください。

data_mesh_types.BqRowPolicy の仕様定義をご覧ください。

列レベルのアクセス

列レベルのアクセスを有効にするには、ポリシータグ名と分類名で識別されるポリシータグを使用して、個々のフィールドにアノテーションを付けます。ポリシータグ メタデータ リソースを更新して、アクセス制御を構成します。

次の例をご覧ください。

data_mesh_types.PolicyTagId の仕様定義をご覧ください。

データメッシュのデプロイ

Data Mesh は、データ基盤のデプロイの一部としてデプロイすることも、単独でデプロイすることもできます。どちらの場合も、Cortex config.json ファイルを使用して、BigQuery データセット名やデプロイ オプションなどの関連する変数を決定します。デフォルトでは、データメッシュをデプロイしても、意図しない損失を防ぐために、既存のリソースやアノテーションは削除または上書きされません。ただし、単独でデプロイされたときに既存のリソースを上書きすることもできます。

導入オプション

次のデプロイ オプションは、config.json > DataMesh で、ユーザーのニーズと費用の制約に基づいて有効または無効にできます。

注: deployACLs が有効になっている場合は、これらのリソース仕様のみを使用してアクセス制御を行うことを強くおすすめします。これにより、意図しないアクセスの追加や削除を防ぐことができます。

オプション	注
deployDescriptions	これはデフォルトで有効になっている唯一のオプションで、アセットと列の説明を含む BigQuery アノテーションをデプロイします。追加の API や権限を有効にする必要はありません。
deployLakes	レイクとゾーンをデプロイします。
deployCatalog	カタログ テンプレート リソースと、それに関連付けられたタグをアセット アノテーションにデプロイします。
deployACLs	アセット アノテーションを使用して、ポリシー分類リソースと、アセット、行、列レベルのアクセス制御ポリシーをデプロイします。ログには、アクセス ポリシーの変更方法を示すメッセージが含まれています。

Data Foundation を使用したデプロイ

デフォルトでは、config.json > deployDataMesh を使用すると、各ワークロード ビルドステップの最後にデータメッシュ アセットの説明をデプロイできます。このデフォルト構成では、追加の API やロールを有効にする必要はありません。データ メッシュの追加機能は、デプロイ オプション、必要な API とロールを有効にし、関連するリソース仕様を変更することで、データ基盤とともにデプロイできます。

単独でデプロイする

データメッシュのみをデプロイするには、common/data_mesh/deploy_data_mesh.py ファイルを使用します。このユーティリティは、ビルドプロセス中にデータメッシュを一度に 1 つのワークロードにデプロイするために使用されますが、直接呼び出された場合は、複数のワークロードを一度にデプロイするために使用されることもあります。デプロイする仕様のワークロードは、config.json ファイルで有効にする必要があります。たとえば、SAP 用 Data Mesh をデプロイする場合は、deploySAP=true を確認します。

必要なパッケージとバージョンでデプロイするには、次のコマンドを使用して、Cortex デプロイ プロセスで使用される同じイメージからユーティリティを実行します。

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

使用可能なパラメータとその使用方法については、次のコマンドを実行します。

  python src/common/data_mesh/deploy_data_mesh.py -h

SAP ECC の呼び出しの例を次に示します。

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

ディレクトリの場所については、データメッシュ ディレクトリ セクションをご覧ください。

上書き

警告: 上書きオプションを使用する前に、このセクションをよくお読みください。

デフォルトでは、データメッシュをデプロイしても、既存のリソースやアノテーションは上書きされません。ただし、データメッシュ のみをデプロイするときに --overwrite フラグを有効にすると、次のようにデプロイを変更できます。

レイク、カタログタグ テンプレート、ポリシータグなどのメタデータ リソースを上書きすると、同じ名前を共有する既存のリソースが削除されますが、名前が異なる既存のリソースは変更されません。つまり、リソース仕様が YAML ファイルから完全に削除され、上書きを有効にしてデータメッシュが再デプロイされた場合、名前の競合が発生しないため、そのリソース仕様は削除されません。これは、Cortex Data Mesh のデプロイが、使用中の既存のリソースに影響しないようにするためです。

レイクやゾーンなどのネストされたリソースの場合、リソースを上書きすると、そのすべての子が削除されます。たとえば、レイクを上書きすると、既存のゾーンとアセット参照も削除されます。上書きされたカタログ タグ テンプレートとポリシータグの場合、既存の関連付けられたアノテーション参照もアセットから削除されます。アセット アノテーションのカタログタグを上書きすると、同じテンプレートを共有するカタログタグの既存のインスタンスのみが上書きされます。

アセットとフィールドの説明の上書きは、既存の説明と競合する有効な空でない新しい説明が指定されている場合にのみ有効になります。

一方、ACL の動作は異なります。ACL を上書きすると、既存のプリンシパルがすべて削除されます（アセットレベルのオーナーを除く）。これは、アクセス ポリシーから除外されるプリンシパルが、アクセス権を付与されるプリンシパルと同じくらい重要であるためです。

データメッシュの探索

データメッシュをデプロイすると、ユーザーは Data Catalog でデータアセットを検索して表示できます。これには、適用されたカタログタグ値に基づいてアセットを検出する機能が含まれます。必要に応じて、ユーザーはカタログ用語集の用語を手動で作成して適用することもできます。

デプロイされたアクセス ポリシーは、BigQuery の [スキーマ] ページで確認できます。このページでは、各レベルで特定のアセットに適用されているポリシーを確認できます。

データリネージ

BigQuery アセット間のリネージを有効にして可視化すると、ユーザーにとって有用な場合があります。リネージには、API を介してプログラムでアクセスすることもできます。データリネージは、アセットレベルのリネージのみをサポートしています。データリネージは Cortex Data Mesh とは関連していませんが、今後、リネージを利用する新機能が導入される可能性があります。

Cortex Data Mesh または Cortex Framework のリクエストについては、サポート セクションをご覧ください。