データリネージの取り込み制御について

費用とガバナンス ポリシーを管理するには、特定の Google Cloud サービスでデータリネージの取り込みを有効または無効にします。たとえば、リネージ トラッキングを必要としない開発プロジェクトや大量のワークロードでは、リネージ収集を無効にできます。

サポートされているサービス統合

次の表に、データリネージ取り込み制御をサポートする統合を示します。

連携名 取り込み制御のサポート デフォルト値 インテグレーションの詳細
Managed Service for Apache Spark: Apache Spark クラスタ はい 有効 Spark データリネージの使用
Managed Service for Apache Spark: Apache Hive クラスタ はい 有効 Hive データリネージを有効にする
Managed Service for Apache Spark: サーバーレス デプロイ はい 有効 Managed Service for Apache Spark でデータリネージを使用する
BigQuery はい 有効 BigQuery テーブルのリネージを追跡する
Managed Service for Apache Airflow はい 有効 Knowledge Catalog を使用したデータリネージ
Looker（Google Cloud コア） ○（プレビュー） 有効 Looker Core のデータリネージ
Cloud Data Fusion いいえ 有効 Knowledge Catalog でリネージを表示する
Dataflow いいえ Dataflow 側で無効になっている Dataflow でデータリネージを使用する
Vertex AI Pipelines いいえ 有効 パイプライン アーティファクトのリネージを追跡する

データリネージの取り込み制御の仕組み

組織、フォルダ、プロジェクトのレベルでデータの取り込みを制御し、これらの設定をサービス固有の構成と組み合わせることで、データリネージの取り込みをきめ細かく制御できます。

Knowledge Catalog は、プロジェクト、フォルダ、組織の順にリソース階層を評価して、有効な構成を決定します。この上向きのトラバーサルで、任意のレベルで明示的に設定された最初の構成が有効になります。

  • プロジェクト レベルで構成を設定すると、Knowledge Catalog はその構成を使用します。
  • プロジェクト レベルで構成が設定されていない場合、Knowledge Catalog は、明示的な構成を持つ最も近い親フォルダの構成を使用します。
  • プロジェクト レベルまたはフォルダレベルで構成が設定されていない場合、Knowledge Catalog は組織レベルの構成を使用します。
  • これらのレベルで構成が設定されていない場合、Knowledge Catalog は統合にシステムのデフォルトを使用します。

取り込み制御を一括で管理するには、階層型サービス有効化ルールに沿って、フォルダまたは組織内のすべてのプロジェクトで Data Lineage API を有効にします。Data Lineage API を有効にすると、組織、フォルダ、プロジェクトのサービス統合ごとにデータリネージの取り込みをきめ細かく制御できます。

単一サービスの統合におけるデータの取り込み構成の仕組み

次のシナリオは、Knowledge Catalog がリソース階層全体で単一のサービスのリネージ取り込み構成を解決する方法を示しています。

次の Managed Service for Apache Spark リネージ構成を持つ組織 test-org について考えてみましょう。

  • 組織 test-org: 有効
    • フォルダ folder-a: 無効
      • プロジェクト project-a: 構成が設定されていません
    • フォルダ folder-b: 有効
      • プロジェクト project-b: 無効

このシナリオでは、次の設定が適用されます。

  • project-a の場合、リネージの取り込みは無効になっています。Knowledge Catalog は project-a から評価を開始し、構成が見つからないため、folder-a に移動して、folder-a から無効構成を適用します。
  • project-b の場合、リネージの取り込みは無効になっています。Knowledge Catalog は project-b から評価を開始し、無効構成を適用して、folder-b と test-org の設定をオーバーライドします。

マルチサービス統合でのデータの取り込み構成の仕組み

次のシナリオは、Knowledge Catalog がリソース階層全体で複数のサービスの構成を個別に解決する方法を示しています。

複数のサービス統合にわたって次のリネージ構成を持つ組織 test-org について考えてみましょう。

  • 組織 test-org
    • Managed Service for Apache Spark: 有効
    • フォルダ folder-a
      • BigQuery: 有効
      • プロジェクト project-a
        • BigQuery: 無効
        • Managed Service for Apache Airflow: 有効
      • プロジェクト project-b: 構成が設定されていません

このシナリオでは、Knowledge Catalog はリソース階層全体で各サービス統合を個別に評価します。

  • project-a:
    • Managed Service for Apache Spark のリネージ取り込みが有効になっています。Knowledge Catalog は project-a から評価を開始し、Managed Service for Apache Spark の構成が見つからないため、folder-a に移動します（構成セットなし）。そして、test-org から有効構成を適用します。
    • BigQuery の系統取り込みは 無効 です。 Knowledge Catalog は、明示的なプロジェクト レベルの構成を適用します。これにより、folder-a で設定された有効構成がオーバーライドされます。
    • Managed Service for Apache Airflow のリネージ取り込みが有効になっている。Knowledge Catalog は、明示的なプロジェクト レベルの構成を適用します。
  • project-b:
    • Managed Service for Apache Spark のリネージ取り込みは有効です（test-org から継承）。
    • BigQuery リネージの取り込みは有効です（folder-a から継承）。
    • Managed Service for Apache Airflow のリネージ取り込みでは、階層のどのレベルでも明示的な構成が設定されていないため、システムのデフォルト（Data Lineage API がアクティブな場合はデフォルトで有効）が使用されます。

次のステップ