データリネージについて

データリネージは、データのライフサイクル全体を視覚的に追跡できるマップです。データの送信元、転送先、転送の過程で行われた変更や変換をすべて確認できます。

このデータの流れを完全にマップ化したものを、Knowledge Catalog（旧称 Dataplex Universal Catalog）、BigQuery（Iceberg REST Catalog 用に作成された外部テーブルを含む）、Vertex AI などのプロダクトで作成されたアセットのGoogle Cloud コンソールで直接確認できます。ワークフローは複数のリージョンにまたがることが多いため、Knowledge Catalog はマルチリージョン リネージをサポートしています。これにより、グローバル Google Cloud エコシステム全体にわたるデータの流れを統合的に把握できます。上級ユーザーは、 Data Lineage API を使用してこの情報を取得することもできます。

データリネージが必要な理由

今日の企業は、常に大量のデータを移動および変更しています。たとえば、顧客の購入履歴をレポート、ダッシュボード、ML モデルに変換します。この複雑さにより、チームは次のような重大な課題に直面します。

  • 信頼と検証。データユーザーは、表示されるレポートや数値が正確で、信頼できるソースから取得されたものであることを確認するのに苦労しがちです。

  • トラブルシューティングがあります。最終レポートにエラーが表示された場合、データチームはすべての手順を遡って問題の根本原因を特定しますが、これは困難で時間がかかることがあります。

  • チェンジ マネジメント。チームは、重要なシステムが破損しないように、データ（テーブルの列など）を変更または削除する前に、そのデータに依存するすべてのダウンストリーム レポートまたはモデルを把握する必要があります。

  • 契約の遵守。リーダーは、規制要件を満たすために、組織全体でセンシティブ データ（顧客情報や財務情報など）がどのように使用されているかを把握する必要があります。

データリネージは、データの流れを明確に視覚化して文書化したものを提供することで、これらの問題を解決します。これにより、データソースを把握し、エラーを追跡し、変更の影響を評価し、コンプライアンスを維持できます。

データリネージの仕組み

データリネージ ワークフローには次の手順が含まれます。

  1. データソースと取り込み: データソースからのリネージ情報によって、プロセス全体が開始されます。

    • Google Cloud サービス: Data Lineage API が有効になっている場合、BigQuery や Dataflow などのサポートされているサービスは、データが移動または変換されるたびにリネージ イベントを自動的にレポートします。

    • カスタムソース:Google Cloud 統合で自動的にサポートされていないシステムについては、Data Lineage API を使用してリネージ情報を手動で記録できます。OpenLineage 標準に従ってフォーマットされたイベントをインポートすることをおすすめします。

  2. リネージ プラットフォーム: この中央プラットフォームは、すべてのリネージデータを取得、モデル化、保存します。

    • Data Lineage API: この API は、すべての受信リネージ情報の単一のエントリ ポイントとして機能します。プロセス、実行、イベントという 3 つのコアコンセプトで構成される階層型データモデルを使用します。

    • 処理と保存: プラットフォームは受信データを処理し、信頼性の高いクエリ最適化データベースに保存します。

  3. ユーザー エクスペリエンス: 保存されたリネージ情報には、主に次の 2 つの方法でアクセスできます。

    • ビジュアル探索: Google Cloud コンソールで、フロントエンド サービスがリネージデータを取得して、インタラクティブなグラフまたはリストとしてレンダリングします。これは、Knowledge Catalog、BigQuery、Lakehouse（Iceberg REST カタログ テーブルの場合）、物理レイヤ（Cloud Storage）、Vertex AI（モデル、データセット、パイプライン、特徴ストアビュー、特徴グループ）でサポートされています。これは、データの流れを視覚的に確認するのに最適です。

    • プログラムによるアクセス: API クライアントを使用して Data Lineage API と直接通信し、リネージ管理を自動化できます。これにより、カスタムソースからリネージ情報を書き込むことができます。また、保存されたリネージデータを読み取ってクエリし、他のアプリケーションで使用したり、カスタム レポートを作成したりすることもできます。

データ リネージにはどの方法を使用すればよいですか？

即時の単一レベルのルックアップを実行するには、SearchLinks メソッドを使用します。完全なリネージ グラフを構築したり、詳細な影響分析（最大 100 レベル）を実行したりするには、SearchLineageStreaming メソッドを使用します。

ユースケースに応じて、最も適切な方法を選択します。

機能 SearchLinks SearchLineageStreaming
奥行き 1 レベル（直接的なネイバー） 最大 100 レベル
実行 同期 リアルタイム ストリーミング
ユースケース 直接のソースまたはターゲットの簡単なルックアップ 完全なリネージ グラフの構築または影響分析の実行

方向を特定する

  • アップストリーム（オリジン）:
    • SearchLinks で、target フィールドをアセットの FQN に設定します。
    • SearchLineageStreaming で、direction を UPSTREAM に設定します。
  • ダウンストリーム（宛先）:
    • SearchLinks で、source フィールドをアセットの FQN に設定します。
    • SearchLineageStreaming で、direction を DOWNSTREAM に設定します。

データリネージ情報モデル

リネージは、ソースからターゲットに変換されたデータのレコードです。Data Lineage API は、この情報を収集し、プロセス、実行、イベントのコンセプトを使用して階層型データモデルに整理します。

コンセプト 説明
プロセス データ変換の定義。
実行 プロセスの実行。
イベント 実行中のデータ移動の記録。

リネージ プロセスとは

プロセスは、特定のシステムにおけるデータ変換オペレーションの定義です。BigQuery リネージの場合、プロセスはサポートされているサービスの種類のジョブです。同じ SQL クエリのすべての実行は単一のプロセスにリンクされるため、特定の変換ロジックが使用されるすべてのインスタンスを追跡できます。

たとえば、次の SQL クエリはプロセスです。このクエリは、2 つのソーステーブルから各ベンダーの合計乗車数をカウントしてテーブルを作成します。

  CREATE TABLE `dataplex-docs.data_lineage_demo.total_green_trips_22_21`
  AS
  SELECT
      vendor_id,
      COUNT(*) AS number_of_trips
  FROM
      (
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2022`
          UNION ALL
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2021`
      )
  GROUP BY
      vendor_id;

プロセスの REST リソース名の形式は projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID です。

次に例を示します。projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6

process リソースの詳細については、プロセス リソースのリファレンスをご覧ください。

リネージ実行とは

プロセスを 1 回実行することを 1 つの「実行」と呼びます。プロセスには複数の実行を指定できます。

各実行は、startTime、endTime、最終状態（COMPLETED、FAILED、ABORTED など）で特徴付けられる一意のオペレーションです。

たとえば、午前 9 時に [プロセス] セクションから SQL クエリを実行すると、特定の実行が作成されます。午前 10 時に同じクエリを再度実行すると、新しい個別の実行が作成されます。両方の実行が同じ親プロセスにリンクされています。

実行の REST リソース名形式は、プロセスの子であることを示しています（projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID/runs/RUN_ID）。

次に例を示します。projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6/runs/83dd03a51cd2ac80f465c9e267a950b1

run リソースの詳細については、実行リソースのリファレンスをご覧ください。

リネージ イベントとは

イベントは、データ変換によってソース エンティティとターゲット エンティティ間でデータが移動した時点を表します。イベントは、特定の実行のソーステーブルとターゲット テーブルを接続する特定のデータ移動の詳細なレコードです。イベントには複数のソースとターゲットを設定することもできます。

たとえば、プロセスのセクションで説明した SQL クエリが実行されると、系統イベントは、nyc_green_trips_2021 と nyc_green_trips_2022 のソーステーブルを使用して total_green_trips_22_21 のターゲット テーブルが作成されたことを記録します。

リネージ イベントには、送信元とターゲットを定義するリンクのリストが含まれます。イベントは、リネージグラフの作成に使用されます。 Google Cloud コンソールにはこれらのリネージグラフが表示されますが、個々のイベントが直接表示されることはありません。Data Lineage API を使用して、イベントの作成、読み取り、削除を行うことができます（更新はできません）。

イベント内の各リンクは、ソース エンティティからターゲット エンティティへのデータフローの単一のパスを定義します。エンティティは、BigQuery テーブルなどのデータアセットへの参照であり、完全修飾名（FQN）で識別されます。1 つのイベントに複数のリンクを含めることができます。これは、複数のソースが 1 つのターゲットに貢献するテーブル結合などのオペレーションでよく見られます。

イベントが列レベルのリネージをサポートする方法の詳細については、列レベルのリネージをご覧ください。

データ リネージでサポートされているデータソースは何ですか？

Knowledge Catalog にリネージ情報を入力するには、次の方法があります。

  • 統合された Google Cloud サービスから自動的に入力
  • カスタムソースの Data Lineage API を使用して手動で入力
  • OpenLineage からイベントをインポートして入力

BigQuery

BigQuery プロジェクトでデータリネージを有効にすると、Knowledge Catalog は次のリネージ情報を自動的に記録します。

BigQuery のコピー、クエリ、読み込みジョブは、プロセスとして表されます。

プロセスの詳細を表示するには、リネージグラフで [プロセスの詳細] アイコン プロセスの詳細。 をクリックします。

各プロセスでは、最新の BigQuery ジョブの属性リストに BigQuery job_id が含まれています。

その他のサービス

データリネージは、次のGoogle Cloud サービスとのインテグレーションをサポートしています。

  • Cloud Data Fusion

    プロジェクトで Data Lineage API が有効になっている場合、リネージ トラッキングを Cloud Data Fusion のみに制限することはできません。

  • Dataflow

    Dataflow ジョブでリネージ イベントをキャプチャし、Data Lineage API にパブリッシュできます。

  • Iceberg REST カタログ テーブルの Lakehouse

  • Looker（Google Cloud コア） （プレビュー）

    データ リネージを使用して BigQuery ソースの Looker（Google Cloud コア）メタデータを可視化することはサポートされています。データ リネージは、Looker（Google Cloud コア）リソースレベルとデータ リネージ サービスレベルで有効にする必要があります。

  • Managed Service for Apache Airflow

    Managed Airflow は、環境レベルのデータリネージ統合制御を使用します。データリネージは、要件を満たす新しい Managed Airflow 環境に対して自動的に有効になります。既存の環境では、環境設定を使用してデータリネージ インテグレーションを有効または無効にします。Managed Airflow のデータリネージの取り込みを構成して、データリネージの自動取り込みを有効または無効にできます。

  • Managed Service for Apache Spark: Apache Hive クラスタ

    Managed Service for Apache Spark Hive ジョブでリネージ イベントをキャプチャし、Data Lineage API に公開できます。Managed Service for Apache Spark のデータリネージの取り込みを構成して、データリネージの自動取り込みを有効または無効にできます。

  • Managed Service for Apache Spark: Apache Spark クラスタ

    Managed Service for Apache Spark Spark ジョブでリネージ イベントをキャプチャし、Data Lineage API に公開できます。Managed Service for Apache Spark のデータリネージの取り込みを構成して、データリネージの自動取り込みを有効または無効にできます。

  • Managed Service for Apache Spark: サーバーレス デプロイ

    Managed Service for Apache Spark サーバーレス ジョブでリネージ イベントをキャプチャし、Data Lineage API に公開できます。Managed Service for Apache Spark のデータリネージの取り込みを構成して、データリネージの自動取り込みを有効または無効にできます。

  • Vertex AI Feature Store

    データ リネージは、特徴ストアビューと特徴グループのメタデータを追跡します。

  • Vertex AI Pipelines

    データリネージは、Vertex AI Pipelines パイプラインで自動的に有効になり、入力アーティファクトと実行パラメータ（モデル、データセット、コンポーネントなど）と、ダウンストリームの派生アセットを追跡します。

カスタム データソースのデータリネージ

Data Lineage API を使用すると、統合システムでサポートされていないデータソース（外部データベースやオンプレミス パイプラインなど）のリネージ情報を手動で記録できます。既存の Knowledge Catalog エントリの完全修飾名と一致する fullyQualifiedName を使用すると、Knowledge Catalog は手動で記録されたリネージのリネージグラフを作成できます。カスタム データソースのリネージを記録する場合は、まずカスタム エントリを作成する必要があります。

カスタム データソースの各プロセスでは、属性リストに sql キーを含めることができます。このキーの値は、データリネージ グラフの詳細パネルでコードのハイライトをレンダリングするために使用されます。記載のとおりに SQL ステートメントが表示されます。機密情報を除外する責任はユーザーにあります。鍵名 sql では、大文字と小文字が区別されます。

たとえば、カスタム sql 属性を含むプロセス リソース ペイロードは次のようになります。

{
  "displayName": "custom-sql-query",
  "attributes": {
    "sql": "SELECT user_id, SUM(amount) FROM `project.dataset.purchases` GROUP BY user_id"
  }
}

詳細については、外部システムのリネージ情報を追跡するをご覧ください。

OpenLineage

すでに OpenLineage を使用して他のデータソースからリネージ情報を収集している場合は、OpenLineage イベントを Knowledge Catalog にインポートし、 Google Cloud コンソールでそれらのイベントを表示できます。詳細については、OpenLineage との統合をご覧ください。

データリネージの自動追跡

Data Lineage API を有効にすると、データリネージをサポートしている Google Cloud システムがデータの移動の報告を開始します。統合された各システムは、異なる範囲のデータソースのリネージ情報を送信できます。

リネージの取り込みを制御する

リネージ データの生成を制御すると、費用とガバナンス ポリシーを管理できます。たとえば、リネージ トラッキングを必要としない開発プロジェクトや大容量のワークロードのリネージ収集を無効にできます。

リネージの取り込みを構成して制御する方法については、サービスのリネージの取り込みを制御するをご覧ください。

マルチリージョンのデータリネージ

データ リネージは本質的にリージョン化されたサービスです。リンク、プロセス、イベントなどのリネージ メタデータは、基盤となるデータ変換またはアセットの変更が発生する特定の地理的位置内で安全に記録され、分離されます。

最新のエンタープライズ データ アーキテクチャがスケーリングされると、パイプライン ワークフローはプロジェクトとリージョンの境界を頻繁に越えます。たとえば、us-central1 で実行されている BigQuery 変換パイプラインは、us-east1 のソーステーブルを読み取り、集計された指標を europe-west1 にある Cloud Storage バケットに出力します。

これらの独立した地理的空間にわたるデータのライフサイクルの包括的なエンドツーエンドのビューを確立するには、マルチリージョン リネージ検索メソッドを使用します。

詳細については、マルチリージョン リネージ検索についてをご覧ください。

データリネージの考慮事項と制限事項

データ ガバナンス戦略を計画する際は、次のリネージ統合、コンプライアンス パラメータ、サービス制限に留意してください。

商品レベルのリネージ制御

Data Lineage API が有効になっている場合、サポートされているシステムは商品レベルの制御に従ってリネージをレポートします。サポートされているシステムとその制御の完全なリストについては、データ リネージでサポートされているシステムをご覧ください。

データリネージのコンプライアンス

  • データリネージはデータ移動に関するメタデータを記録しますが、データ自体はキャプチャしません。メタデータに含まれるフィールドの詳細については、データリネージ情報モデルと Data Lineage API リファレンスをご覧ください。
  • Knowledge Catalog の一部としてのデータリネージは、VPC-SC をサポートしています。
  • Knowledge Catalog には、顧客管理の暗号鍵（CMEK）を使用して、収集されたリネージ メタデータを保護する機能はありません。

データリネージの制限事項

データリネージには次の制限があります。

  • すべてのリネージ情報は、システムに 30 日間のみ保持されます。

  • リネージ情報は、関連するデータソースを削除しても保持されます。たとえば、BigQuery テーブルを削除しても、API とコンソールで最大 30 日間リネージを表示できます。

  • データリネージでは、BigQuery ルーティンの直接リネージ情報は自動的に記録されません。ルーティンがクエリで使用されている場合、データリネージは、ルーティンが読み取るテーブルと、クエリが書き込むテーブルの依存関係として、テーブル間のリネージを記録します。

リネージグラフでノードを選択すると、次の場合にノード詳細サイドパネルが空になります。

  • リソースが別の組織に配置されている。
  • ユーザーがリソースをホストしている組織のメンバーではない。

列レベルのリネージの制限事項

列レベルのリネージには、次の追加の制限があります。

  • BigQuery の読み込みジョブやルーティンでは、列レベルのリネージは収集されません。

  • 外部テーブルの上流の列レベルのリネージは収集されません。

  • ジョブで 1,500 個を超える列レベルのリンクが作成された場合、列レベルのリネージは収集されません。この場合、テーブルレベルの系統のみが収集されます。

  • 列レベルのリネージのサポートは、BigQuery テーブルの最上位の列に限定されます。複合型（STRUCT や JSON など）内のネストされたフィールドはサポートされていません。

  • フィールド パラメータを使用した検索機能は、列間の関係を明示的に定義するリンクでのみ機能します。テーブルレベルでのみ定義されている結果やリンクは返されません。テーブルレベルのリンクと列レベルのリンク間の検索はサポートされていません（たとえば、テーブルレベルのリンクに関連するすべての列を見つけるなど）。API は、ソースとターゲットの両方でフィールドが指定されているリンクのみを返します。

  • _PARTITIONDATE や _PARTITIONTIME などのパーティショニング列がリネージグラフで認識されないため、パーティション分割テーブルのサポートは制限されています。

  • コンソールの制限:

    • リネージグラフのトラバーサルは、各方向で 20 レベルの深さと 10,000 個のリンクに制限されています。

料金

Knowledge Catalog は、プレミアム処理 SKU（データ コンピューティング ユニット（DCU）で測定）を使用してデータリネージの料金を課金します。料金の詳細については、Knowledge Catalog の料金をご覧ください。または、 Google Cloud 料金計算ツールを使用してください。

コスト要因と請求への影響

データ リネージの実装を計画する際は、次の費用要因を考慮してください。

  • プロジェクトごとの有効化。Data Lineage API はプロジェクトごとに実行されます。データ量の多いプロジェクト ワークフローで有効にする前に、課金への影響を確認します。
  • メタデータの保存と検索。30 日間の保持期間中に保存されたリネージ メタデータ（プロセス、実行、イベント、リンク）は、メタデータ ストレージ SKU で課金されます。 Google Cloud コンソールでリネージを表示しても、BigQuery のクエリ料金やスキャン料金は発生しません。
  • BigQuery Omni。リネージ処理は特定のリージョンに分散され、費用は処理が行われるリージョンによって異なります。
  • BigQuery マルチリージョン データセット。マルチリージョン データセット（US マルチリージョンなど）を使用する場合、BigQuery は物理データセンター ゾーン間でクエリを動的にルーティングします。データリネージは、ジョブが実行された物理ロケーション（us-east1 など）でクエリ実行と並行して実行されます。これにより、Cloud Billing の請求書にリージョン Lineage DCU SKU エントリが生成されます。
  • カスタム送信元ソースタイプ。CUSTOM 以外の値を指定して Data Lineage API Origin sourceType を呼び出すと、追加費用が発生します。

費用のモニタリングと管理

  • Cloud Monitoring の指標の制限。データ リネージ DCU の使用量はサーバーレス コンピューティングで実行され、dataplex.googleapis.com/* のリアルタイムの時系列指標は Cloud Monitoring に出力されません。
  • Cloud Billing で費用をフィルタして属性を割り当てる。Knowledge Catalog プレミアム処理 SKU で、データリネージの課金を他の課金と分離して属性を設定するには、Cloud Billing レポートまたは BigQuery への Cloud Billing エクスポートで、ラベル goog-dataplex-workload-type を値 LINEAGE で使用します。クエリの詳しい例については、Cloud Billing エクスポートを使用して Knowledge Catalog DCU の費用をモニタリングして属性を割り当てるをご覧ください。
  • 開発プロジェクトで無効にする。不要な処理費用を回避するには、リネージ トラッキングが必要なプロジェクトでのみ Data Lineage API を有効にします。
  • 請求を停止する。Data Lineage API の料金は、Dataplex API とは別に発生します。Dataplex API を無効にしても、Data Lineage API は無効にならず、料金も停止されません。データリネージの課金が発生しないようにするには、Data Lineage API を無効にして、データリネージをオフにする必要があります。

次のステップ