Zenn
🪄

Dataplex の データリネージ機能を BigQuery で試してみた

2024/11/01に公開
Google Cloud
BigQuery
Dataplex
datalineage
tech

こんにちは、クラウドエース第三開発部の丸山です。

本記事では、Google Cloud で提供されている Dataplex の機能の一部である 「データリネージ」機能をご紹介します。

データリネージとは

データリネージ (Data Lineage) とは、システム内のデータの移動を追跡するプロセスのことを指します。
データの送信元、データの送信先、データに適用される変換など、データのライフサイクル全体を可視化することで、データの信頼性向上やエラー分析を支援します。
「リネージ」は、日本語では「血統」「家柄」を意味し、Google Cloud に留まらない一般的な用語として知られています。

データリネージを利用することによって、次のようなメリットがあります。

  • 信頼性の向上
    データが信頼されたソースから取得されたことを証明できます。
    特に金融業界や医療業界など、データの信頼性が極めて重要な業界でこの機能が重宝されています。

  • エラーや異常値の発見
    データ加工処理は正常に終了するが、最終的に利用したいデータがおかしい場合に、どこでデータがおかしくなったのかを発見しやすくなります。

Dataplex とは

Dataplex とは、複数の Google Cloud プロジェクトや、同一 Google Cloud プロジェクトの中の様々なプロダクトで、分散されたデータの統合・管理を自動化するための Google Cloud のフルマネージド サービスです。
公式ドキュメントでは以下のように説明されています。

Dataplex は、分散データを統合し、そのデータのデータ マネジメントとガバナンスを自動化するデータ ファブリックです。

Dataplex によって、次のことができます。

  • 複数の Google Cloud プロジェクトに保存されているデータにわたって、データを移動せずにドメイン固有のデータメッシュを構築します。
  • 単一の権限セットで一貫してデータを管理、モニタリングできます。
  • カタログ機能を使用して、さまざまなサイロにわたってメタデータを検出し、キュレートします。詳細については、Dataplex Catalog の概要をご覧ください。
  • SparkSQL、Presto、HiveQL などのオープンソース ツールと BigQuery を使用して、メタデータを安全にクエリできます。
  • サーバーレス Spark タスクを含む、データ品質とデータ ライフサイクルの管理タスクを実行します。
  • ノートブックにアクセスして SparkSQL クエリを使用し、フルマネージドのサーバーレス Spark 環境でデータを探索できます。

Dataplex は、Data Catalog と呼ばれるサービスを内包しています。
この Data Catalog の中に、「データリネージ機能」が存在しています。

また、本記事が指している Data Catalog は、別のサービスである Dataplex Catalog とは異なります。
ここでは各プロダクトの解説は省略します。
詳細については公式ドキュメントをご確認ください。
Dataplex
Data Catalog
Dataplex Catalog

データリネージ機能は、以下の Google Cloud サービスで利用できます。

本記事では BigQuery で利用できるデータリネージ機能に焦点を当ててご紹介いたします。

BigQuery で利用できるデータリネージ機能

概要

BigQuery で利用できるデータリネージ機能では、BigQuery ジョブのリネージ情報が自動で記録されます。
記録されたリネージ情報は、以下の画像のような「リネージグラフ」で確認することができます。
このリネージ情報は 30 日間保存され、以降は見ることができなくなります。
また、この保存期間を変更することは本記事執筆時点（2024 年 10 月 31 日）では不可能です。

対応しているジョブ

データリネージ機能で追跡できるリネージ情報は以下の通りです。

  • 次の BigQuery ジョブの結果として作成されたテーブル情報
    • コピージョブ
    • Cloud Storage URI を使用して Cloud Storage から許可された形式でデータを読み込む読み込みジョブ
    • Google Standard SQL で次のデータ定義言語（DDL）を使用するクエリジョブ
      • CREATE TABLE
      • CREATE TABLE AS SELECT
      • CREATE TABLE COPY
      • CREATE TABLE CLONE
      • CREATE TABLE FUNCTION
      • CREATE TABLE LIKE
      • CREATE VIEW
      • CREATE MATERIALIZED VIEW
  • 既存のテーブルに対して、Google Standard SQL で次のデータ操作言語（DML）ステートメントを使用した結果の情報
    • 次のタイプのテーブルに対してSELECT するクエリを発行するジョブ
      • BigQuery ビュー
      • BigQuery マテリアライズド ビュー
      • BigQuery 外部テーブル
    • INSERT SELECT
    • MERGE
    • UPDATE
    • DELETE

カラムレベルのデータリネージ

従来、BigQuery で利用できるデータリネージは、テーブルレベルで利用できるものとして存在していました。
しかし、2024 年 7 月 24 日に、カラムレベルでデータリネージが利用できるようになったことで、よりきめ細かいレベルでデータを追跡できるようになりました。（該当リリース）

カラムレベルのデータリネージに関しては、本記事執筆時点（2024 年 10 月 31 日）では詳細に書かれている公式ドキュメントがありませんでした。
そこで本記事では、後の章でカラムレベルのデータリネージまで調査範囲を広げて試してみようと思います。

料金

データリネージでは「Dataplex 処理」と「ストレージ」に対して料金が発生します。

Dataplex 処理は、Dataplex のコンピューティング リソースを使用したときに発生するもので、DCU(Data Compute Unit) という独自の単位で計算されます。
また、Dataplex 処理は Standard と Premium の 2 種類があり、機能ごとに分類されています。
データリネージは Premium 処理として扱われます。

Dataplex Premium 処理の料金は、東京リージョンで 1 DCU 時間あたり＄0.114 の料金が発生します。
ストレージ料金は 1 ヶ月ごとに 1 MiB まで無料です。
1 MiB を超えると 1 ヶ月ごとに $2.00/GiB の料金が発生します。

料金の詳細は公式ドキュメントをご覧ください。

データリネージ機能を使ってみた

それでは、実際にデータリネージ機能を試してみます。
今回は、公式ガイドにある手順を参考に進めます。

実施した手順の概要は以下の通りです。

  • API を有効にする
  • 必要なロールを付与する
  • BigQuery ジョブを実行する
  • リネージグラフを確認する

なお上記の全ての操作は、事前に作成した同一のプロジェクト内で行います。

API を有効にする

次の API を有効にします。

  • Data Catalog API
  • BigQuery API
  • Data Lineage API

必要なロールを付与する

データリネージの API を有効にしたプロジェクトで、本記事の手順を実行するユーザーに次のロールを付与します。

  • BigQuery でジョブを実行するためのロール
    • BigQuery ユーザー（roles/bigquery.user） もしくは BigQuery ジョブユーザー（roles/bigquery.jobUser）
  • リネージ情報を閲覧するためのロール
    • Data Catalog 閲覧者 （roles/datacatalog.viewer）
    • データリネージ閲覧者（roles/datalineage.viewer）
    • BigQuery データ閲覧者（roles/bigquery.dataViewer）

BigQuery ジョブを実行する

データリネージでデータの出所を表示させるために、BigQuery でジョブを実行します。
詳細な内容については記事の本質から逸れるため省略しますが、今回は概ね以下の手順でジョブを実行しました。

  1. サンプルデータとテーブルの作成

    • BigQuery パブリック データセットにある「NYC TLC TRIP」というデータを利用し、そのデータを CSV ファイルにする
    NYC TLC TRIP の詳細

    NYC TLC TRIP データセットでは、ニューヨークのタクシーの乗車記録に関する過去 5 年間のデータが格納されています。
    乗車記録には、乗車開始日時と降車日時、乗車開始場所と降車場所、乗車距離、内訳料金、料金タイプ、支払い方法、運転手が報告した乗客数などのカラムが含まれています。

    • BigQuery で nyc_green_trips_2021 と nyc_green_trips_2022 の 2 つのサンプルテーブルを作成する

  2. ロードジョブの実行
    1 で作成した CSV ファイルを BigQuery にロードするジョブを、 Dataflow / BigQuery コンソールの 2 種類の方法で実行する

    • ジョブ 1 : Cloud Storage に格納されている CSV ファイルを、Dataflow を介して BigQuery の nyc_green_trips_2021 テーブルにロードする
    • ジョブ 2 : Cloud Storage に格納されている CSV ファイルを、コンソールから BigQuery の nyc_green_trips_2022 テーブルにロードする

  3. クエリジョブの実行
    ロード後、BigQuery のクエリエディタで total_green_trips_22_21 という新しいテーブルを作成するクエリジョブを実行する
    ここでは、以下のクエリジョブを実行しました。

    • nyc_green_trips_2021 / nyc_green_trips_2022 のテーブルから vendor_id / pickup_datetime / dropoff_datetime を取得し、2 つのテーブルを UNION する
    • 上記の結果から、4 つのカラムを取得もしくは生成する
      • vendor_id : 上記の結果からそのまま取得
      • number_of_trips : 各 vender_id の乗車回数を集計
      • driving_time : 乗車時間を分単位で計算
      • create_date : データの作成日

実行したクエリ

CREATE TABLE
  data_lineage.total_green_trips_22_21 AS
SELECT
  vendor_id,
  COUNT(*) AS number_of_trips,
  TIMESTAMP_DIFF(dropoff_datetime,pickup_datetime,minute) AS driving_time,
  CURRENT_DATE() AS create_date
FROM (
  SELECT
    vendor_id,
    pickup_datetime,
    dropoff_datetime
  FROM
    data_lineage.nyc_green_trips_2021
  UNION ALL
  SELECT
    vendor_id,
    pickup_datetime,
    dropoff_datetime
  FROM
    data_lineage.nyc_green_trips_2022 )
GROUP BY
  vendor_id,
  dropoff_datetime,
  pickup_datetime

出力内容例（一部の行を抜粋）

vendor_id number_of_trips driving_time create_date
1 1 10 2024-10-22
2 1 42 2024-10-22

リネージグラフを確認する

上記で作成したそれぞれのテーブルやジョブについて、リネージグラフを確認します。

確認方法

リネージグラフは 2 通りの方法で確認できます。

  • Dataplex コンソール
    ① Dataplex コンソールを開き、以下画像中央の「検索」欄から、確認したいリネージ情報が含まれている BigQuery テーブルを検索する
    ② 出てきたテーブル名をクリックして、詳細画面に遷移する

    ③ 詳細画面で「リネージ」タブをクリックする

  • BigQuery コンソールの「リネージ」タブ
    ① BigQuery コンソールを開き、確認したいリネージ情報が含まれている BigQuery テーブルをクリックして表示する

    ② 「リネージ」タブをクリックする

それぞれの方法でリネージグラフを確認してみましたが、どちらも表示される内容に変わりありませんでした。
そこで、以降の画像は全て BigQuery コンソールの「リネージ」タブから取得したものに統一します。

リネージグラフの読み方

次に、簡単にリネージグラフの読み方を解説します。
リネージグラフでは「グラフタブ」と「リストタブ」の 2 種類の画面があります。

  • グラフタブ

グラフタブとは、以下の画像のようなリネージグラフが表示されるタブのことを指します。

上記画像 ① のオレンジのアイコンをクリックすると、グラフタブの右もしくは下に、実行した処理の詳細が表示されます。
以下の画像は、実行した処理の詳細例です。

上記画像 ② のテーブル名をクリックすると、グラフタブの右もしくは下に、 BigQuery テーブルの詳細が表示されます。
以下の画像は、BigQuery テーブルの詳細例です。

また、上記画像 ② のように、現在リネージを表示しているテーブル（ここでは total_green_trips_22_21）ではカラム名も一緒に表示されます。
各カラムをクリックすると、カラムごとの詳細を確認できるリストタブに遷移します。

  • リストタブ

リストタブでは、以下画像の左側にあるリネージ エクスプローラ（③）でフィルタリングをした結果（④）が表示されます。
以下の画像は、テーブルレベルでリストタブを表示したときの例です。


リストタブの表示例 テーブルレベル

リネージ エクスプローラでは、以下のフィルタリング項目を設定することができます。

  • 列の選択 : 任意のカラムをフィルタリングする（選択しない場合はテーブルレベルで表示される）
  • 方向
    • アップストリーム : 選択したエントリ（テーブルやカラム）の元となるエントリを表示する
    • ダウンストリーム : 選択したエントリを利用しているエントリを表示する
  • 期間 : データリネージが発生した期間をフィルタリングする

フィルタリングで「列の選択」を指定しない場合は、上記画像 ④ のようにテーブルレベルでリネージの詳細が表示されます。

一方、以下画像 ⑤ のように「列の選択」で任意のカラム名を指定した場合は、カラムレベルでリネージの詳細が表示されます。

リストタブの表示例 カラムレベル

このとき、リネージ エクスプローラでフィルタリングできる項目に、上記画像 ⑥ のような「依存関係のタイプ」が追加されます。
「依存関係のタイプ」は以下のフィルタリング項目があります。

  • データ変換 : 元となるカラムからデータを変換しながら生成されたカラムをフィルタリングする
  • 完全なデータのコピー : 元となるカラムからデータを変換せずに生成されたカラムをフィルタリングする

また、フィルタリング結果を表示する場所には、上記画像 ⑦ のように「ソース列」「ターゲット列」「依存関係のタイプ」という項目が追加されます。
カラムレベル独自の項目が表示されることで、より細かいリネージ情報を確認することができます。

ロードジョブで生成されたテーブルのデータリネージ

ここからは、実際に生成されたデータリネージをジョブの種類ごとに確認します。
まずはロードジョブで生成された 2 つのテーブルのリネージを確認していきます。

  • テーブル 1 (nyc_green_trips_2021) : Cloud Storage に格納されている CSV ファイルを、Dataflow を介して BigQuery の nyc_green_trips_2021 テーブルにロードすることで作成
  • テーブル 2 (nyc_green_trips_2022) : Cloud Storage に格納されている CSV ファイルを、コンソールから BigQuery の nyc_green_trips_2022 テーブルにロードすることで作成

はじめに nyc_green_trips_2021 のリネージ情報を、テーブルレベルで確認します。
以下 2 つの画像から、次のことが分かりました。


nyc_green_trips_2021 グラフタブ


nyc_green_trips_2021 リストタブ

① ソース
Dataflow では、「2021.csv」というファイル名をソースにしてロードジョブを実行しました。
一方、グラフタブとリストタブの画像両方から、ソースが「ad36b88f-511f-409c-a221-d6e820e0e779」という名前で表示されていることが分かります。
これは Cloud Storage のファイルパスを指しており、元のファイル名である「2021.csv」は表示されません。
そのため、リネージ情報としてはあまり良いものではなさそうです。

② 宛先
グラフタブとリストタブの画像両方から、「nyc_green_trips_2021」というテーブルがターゲット（宛先）になっていることが分かります。

③ プロセスの種類
グラフタブの画像から、プロセスの種類は読み込み（ロードジョブ）であることが分かります。
しかし、「nyc_green_trips_2021」のテーブルには Dataflow を介してデータをロードしましたが、このロード手段に関する情報は確認できませんでした。
なお、後述の BigQuery ジョブ ID にある「beam_bq_job_LOAD」という記載から、「おそらく Dataflow を利用したんだな」ということまでは推測できそうです。

④ BigQuery ジョブ ID
グラフタブの画像から、BigQuery のジョブ ID が分かります。

同様に、nyc_green_trips_2022 のリネージ情報を、テーブルレベルで確認します。
以下 2 つの画像から、次のことが分かりました。


nyc_green_trips_2022 グラフタブ


nyc_green_trips_2022 リストタブ

① ソース
BigQuery コンソールでは、「2022.csv」というファイル名をソースにしてロードジョブを実行しました。
グラフタブとリストタブの画像両方から、ソースが「2022.csv」という名前で表示されていることが分かります。
Dataflow を介したロードジョブとは異なり、BigQuery コンソールからロードした場合は、具体的なソース名が表示されるところが良いと感じました。

② 宛先
グラフタブとリストタブの画像両方から、「nyc_green_trips_2022」というテーブルがターゲット（宛先）になっていることが分かります。

③ プロセスの種類
グラフタブの画像から、プロセスの種類は読み込み（ロードジョブ）であることが分かります。
「nyc_green_trips_2022」のテーブルには BigQuery のコンソールからロードジョブを実行しましたが、この情報は確認できませんでした。

④ BigQuery ジョブ ID
グラフタブの画像から、BigQuery のジョブ ID が分かります。

続いて、リネージ情報をカラムレベルでも確認します。
多くのカラムがあるため、ここでは例として nyc_green_trips_2021 の vendor_id カラムがどのように生成されたのかをリストタブから見ていきます。
nyc_green_trips_2021 の vendor_id カラムをフィルタリングすると、以下の画像のように「表示する行がありません」という結果になりました。
ここでは代表して vendor_id カラムを表示していますが、他のカラムも同様の結果になります。

これは、CSV ファイルが BigQuery 内ではなく Cloud Storage（BigQuery 外） から読み込まれたものだったため、CSV ファイル内のカラム名までデータリネージで追跡できなかったことが原因であると考えています。

クエリジョブで生成されたテーブルのデータリネージ

続いて、クエリジョブで生成されたテーブルのリネージを確認していきます。

はじめに、テーブルレベルでリネージ情報を確認します。
以下 2 つの画像から、次のことが分かりました。


total_green_trips_22_21 グラフタブ


total_green_trips_22_21 リストタブ

① ソース
グラフタブとリストタブの画像両方から、nyc_green_trips_2021 / nyc_green_trips_2022 テーブルがソースになっていることが分かります。

② 宛先
グラフタブとリストタブの画像両方から、total_green_trips_22_21 テーブルがターゲット（宛先）になっていることが分かります。

③ プロセスの種類
グラフタブの画像から、プロセスの種類はクエリであることが分かります。
また、グラフタブの画像からは実行したクエリも確認できます。

④ BigQuery ジョブ ID
グラフタブの画像から、BigQuery のジョブ ID が分かります。

続いて、カラムレベルでもリネージ情報を確認します。
ここでは、例として total_green_trips_22_21 の vendor_id カラムと driving_time カラムがどのように生成されたのかをリストタブから見ていきます。
total_green_trips_22_21 の vendor_id カラムと driving_time カラムをそれぞれフィルタリングすると、それぞれリネージ情報が表示されました。

vendor_id カラム

  • 新たに作成された vendor_id カラムは、以下画像にある「依存関係のタイプ」から、完全なコピーで作成されたことが分かる
  • コピーの元となるカラムは、「ソース」「ソース列」から、nyc_green_trips_2021 と nyc_green_trips_2022 の vendor_id カラムであることが分かる

driving_time カラム

  • 新たに作成された driving_time カラムは、以下画像にある「依存関係のタイプ」から、データ変換で作成されたことが分かる

  • データ変換の元となるカラムは、「ソース」「ソース列」から、nyc_green_trips_2021 と nyc_green_trips_2022 の dropoff_datetime カラム / pickup_datetime カラムであることが分かる

  • さらにデータ変換の内容は、グラフタブを拡大した以下の画像から、以下であることが分かる（クエリを一部抜粋）
    TIMESTAMP_DIFF(dropoff_datetime,pickup_datetime,minute) AS driving_time

    クエリの詳細

ロードジョブとは異なり、クエリジョブではカラムレベルまでリネージを追跡できました。
これは、このクエリジョブが BigQuery 間で完結するものであったため、リネージの追跡対象内であったことが要因であると考えられます。

筆者が感じたデータリネージのメリット

実際にデータリネージを試してみて次のようなメリットがあると感じました。

  • テーブルレベルのデータリネージでは、データのソースや変換処理を直感的に確認できる
  • 特にカラムレベルのデータリネージでは、前プロセスのカラムからどのように利用されたのかをまで確認できる
  • リネージがグラフ化されることによって、クエリ内容の理解をある程度助長できる

筆者が感じたデータリネージの注意点

実際にデータリネージを試してみて次のような注意点があると感じました。

  • リネージが反映されるまでに約 10 分のタイムラグが発生する
    筆者は 3 回ジョブを実行してリネージ結果を確認しましたが、いずれも 10 分後にリネージグラフが表示されました。
    （最初はデータリネージの使い方を間違えたと思い、心配な 10 分間を過ごしました。）

  • 外部ファイルのロードジョブなど、一部はカラムレベルまでジョブの詳細が表示されないものがある

  • リネージ情報は 30 日間のみ保存される

  • カラムレベルのデータリネージは、申請時に登録したメールアドレス単位で有効化される
    公式ドキュメントでは以下の記載があります。

    データリネージは、プロジェクトごとに有効になります。

    一方で、カラムレベルのデータリネージを申請した結果、今回利用したプロジェクトだけではなく別のプロジェクトでも利用できることを確認しました。
    おそらくユーザー（登録メールアドレス）単位で有効化されるようです。

    つまり、そのメールアドレスがリネージ情報を閲覧できるロールを持っているプロジェクトすべてで、カラムレベルのリネージ情報まで閲覧できるようになります。
    「このメールアドレスのユーザーにはカラムレベルのリネージ情報を見られたくない」というプロジェクトがあった場合でも、それを禁ずることはできないため、ご留意ください。

    なお、データリネージに関連する API を有効化しなければ、データリネージ機能は使用できません。
    そのため、そもそもデータリネージ機能が不要な場合は、関連する API を有効化しないことをお勧めいたします。

まとめ

今回は BigQuery で利用できるデータリネージ機能を、カラムレベルまで範囲を広げて試してみました。
「どのテーブルのどのカラムから、どのような処理を経た結果作成されたものなのか」が視覚的に表示される点が便利ですね。
カラムレベルのデータリネージはプレビュー段階で、BigQuery 外でのジョブはカラムまでリネージ情報が追跡されないようです。
GA になった際は、BigQuery 外でのジョブもカラムレベルまでリネージ情報が追跡できるようになることに期待しています。

最後まで読んでいただきありがとうございました。

Discussion