データメッシュ ユーザーガイド

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

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

デザイン

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

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

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

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

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

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

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

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

ベースリソースの仕様を理解する

Cortex 用 Data Mesh を構成するための主なインターフェースは、ベースリソース仕様です。これは、デプロイされるメタデータ リソースとアノテーションを定義する、すぐに使用できる 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 つの Lake 仕様が含まれています。1 つは未加工ゾーンと CDC ゾーン用、もう 1 つはレポート用です。

Dataplex レイク

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

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

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

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

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

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

テンプレート フィールド display_name はフィールド ID として使用され、Class 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 デプロイで有効になっていません。

次の例をご覧ください。

ポリシー分類は、data_mesh_types.PolicyTaxonomies を指定する YAML ファイルで定義されます。

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

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

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

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

• SAP ECC（元データ、CDC、レポート）
• SAP S4 HANA（元データ、CDC、レポート）
• SFDC（レポート専用）
• Oracle EBS（レポートのみ）
• CM360（レポートのみ）
• Google 広告（レポートのみ）
• メタ（レポート専用）
• 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 の Spec 定義をご覧ください。

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

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

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

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

• READER: アセット内のデータを表示します。
• WRITER: アセットのデータを変更して追加します。
• OWNER : アクセスの管理など、アセットを完全に制御できます。

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

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

次の例をご覧ください。

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

行レベルのアクセス

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

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

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

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

次の例をご覧ください。

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

列レベルのアクセス

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

次の例をご覧ください。

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

Data Mesh のデプロイ

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

導入オプション

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

Data Foundation を使用したデプロイ

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

単独でデプロイする

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

ディレクトリのロケーションについては、Data Mesh ディレクトリをご覧ください。

上書き

デフォルトでは、Data Mesh をデプロイしても、既存のリソースやアノテーションが上書きされることはありません。ただし、Data Mesh のみをデプロイする場合は、--overwrite フラグを有効にして、次の方法でデプロイを変更できます。

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

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

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

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

データメッシュの概要

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

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

データリネージ

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

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