データリネージについて

Knowledge Catalog（旧称 Dataplex Universal Catalog）のデータリネージを使用すると、データの送信元、変換方法、BigQuery や Vertex AI などのシステム間での移動を追跡できます。これらのリネージ レコードは、信頼できるソースの検証、パイプライン エラーの根本原因の追跡、変更によるダウンストリームへの影響の評価、コンプライアンスのサポートに役立ちます。 Google Cloud コンソールでインタラクティブなグラフを探索したり、マルチリージョン リネージを検索したり、Data Lineage API を使用してメタデータをプログラムで記録してクエリしたりできます。

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

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

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

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

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

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

データリネージは、データの送信元、転送先、転送の過程で行われた変更や変換を記録することで、これらの課題に対処します。このドキュメント化されたレコードにより、データソースの把握、エラーの追跡、変更の影響の評価、コンプライアンスの維持が可能になります。

データリネージの仕組み

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

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

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

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

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

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

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

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

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

    • プログラムによるアクセス: 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

    データリネージは、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 バケットに出力します。

Google Cloud リージョンとプロジェクトにわたるデータ ライフサイクルの統合されたエンドツーエンド ビューを確立するには、マルチリージョン リネージ検索方法を使用します。

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

データリネージの留意点と制限事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Data Lineage API を使用して送信されたカスタム OpenLineage イベントは、列レベルのリネージをサポートしていません。

  • BigQuery の読み込みジョブやルーティンでは、列レベルのリネージは収集されません。これには、マルチステートメント スクリプトと Dataform 増分テーブルが含まれます。これらは、一時ストアド プロシージャにコンパイルされます。

  • ソーステーブルがすべて一時データセットに存在するクエリの場合、列レベルの系統は収集されません。

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

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

  • ALTER TABLE RENAME オペレーション（テーブルスワップ ETL パターンでよく使用される）を使用してテーブルの名前を変更する場合、列レベルのリネージは転送または保持されません。

  • 列レベルのリネージのサポートは、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 の請求書にリージョン リネージ 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 を無効にしてデータリネージをオフにする必要があります。

次のステップ