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

費用とガバナンス ポリシーを管理するには、特定の 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 から Disabled 構成を適用します。
  • 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 から Enabled 構成を適用します。
    • 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 がアクティブな場合はデフォルトで有効）が使用されます。

次のステップ