はじめに
初めまして。プラットフォーム開発部にてデータ基盤を整備しているkashiraと申します。
ピクシブではデータガバナンス強化のために、Google Cloud Platform(GCP)のDataplexのデータリネージ機能を本番運用で使い始めました。
この記事では、「どのように導入したのか？」「導入によってどんな効果が出たのか？」について話していきます。
データリネージとは？
データリネージとは、データの流れを可視化する機能です。
BIやDWHで分析するデータは、各所に散らばった複数の処理を経て生成されます。
複数の散らばった処理を1つずつ追いかけるのには時間がかかり、何かデータに障害が発生した場合のデバッグや、データ変更をしたい場合の調査に対するコストが大きくなります。
こうした課題を解決するための仕組みの1つがデータリネージです。
具体的には、以下のようにテーブル間の繋がりを線で可視化したものがデータリネージと呼ばれます。
ここではBigQueryのテーブル間の繋がりのみが可視化されていますが、データリネージのプロダクトによって提供される機能は大きく異なります。
例えば、生成元のデータ(MySQLやGoogle Sheetsなど)の依存関係を含めて可視化してくれる、カラムレベルでの依存関係も可視化してくれるといった違いがあります。
導入で解決したい課題
ピクシブでは、データリネージ導入以前に以下のような課題を抱えていました。
- テーブルの変更コストが高い
- 依存関係が複雑なテーブルを変更したい際に、関連するテーブルを洗い出すのが大変
- 障害時の対応に時間がかかる
- 下流のテーブルがどのようなクエリで生成されたかを追うのに、SQLのクエリファイルを追う必要がある
- 信頼できるデータか判断しづらい
テーブルの変更コストが高い
メンテナンスされていない不要なデータを削除したいときに、影響度の大きいテーブルから参照されていないか確認する必要があります。
ただし、その作業は監査ログを何度もクエリする必要がありで作業工数が高いため、削除の優先度が上がらず、使われなくなったテーブルが放置されるケースが多々ありました。
結果として、メンテナンス対象のテーブルが増えて、管理コストやストレージコストの増加、不正確な分析を招きやすくなるといった問題につながっていました。
依存関係が複雑なテーブルを変更したい際に、関連するテーブルを洗い出すのが大変
Airflowを運用しているため、AirflowのDAGである程度テーブルの依存関係を洗い出すことは出来ていました。しかし、DAGの途中でViewが挟まっていたり、単一のtaskで複数のテーブルを更新しているケースもあり、DAG Graphだけを見るのでは不十分なケースも多く、課題に感じていました。
障害時の対応に時間がかかる
データの流れが見えないため、障害が発生したときに、その障害がどのテーブルに影響するかすぐに分からず、その障害が重要かどうかの見極めが難しかったり、インシデント記録の作成に大量の工数を持っていかれるなどの課題がありました。
下流のテーブルがどのようなクエリで生成されたかを追うのに、SQLのクエリファイルを追う必要がある
どのテーブルがどのようなクエリで生成されたかをGUI上で追えていませんでした。そのためテーブルがどのように生成されるのかを確認したい際には、各所に散らばったSQLファイルを愚直に追う必要がありました。
信頼できるデータか判断しづらい
どのソースデータを使っているかパッと見で分からないため、コードを読む必要があり、テーブル変更のコストや、新規にデータパイプラインを管理する社員の学習コストが大きいという課題がありました。
ツールの導入
課題を整理した上で、ツールの導入は以下のような流れで進めました。
- ツール選定
- 試験運用
- 本番運用
ツール選定
ツールを比較した結果、Dataplexのデータリネージを使うことにしました。
Dataplexにした理由は、以下の通りです。
- 導入にかかる時間がとにかく短い
- 別のデータカタログを導入するのはツールの干渉を起こす可能性が高い
- メンテナンスが容易
- Googleのプロダクトと親和性が高い
導入にかかる時間がとにかく短い
データリネージは比較的新しい概念なので、どのような課題をどう解決するのかをデータ基盤の利用者に理解してもらうには、まずは素早くツールを導入して価値を体験してもらうのが一番です。
DataplexであればGCPの１機能なので、既にGCPを利用していればボタン１つで簡単に導入できます。また同様に、ボタン１つで撤退も出来ます。
別のデータカタログを導入するのはツールの干渉を起こす可能性が高い
社内ではGCPのData CatalogとDataplexをデータカタログとして使っていく流れがありました。
別のデータカタログを導入するとツールがバラけることでメンテナンスコストが増える、情報を集約出来ないなどのデメリットが想定されました。
メンテナンスが容易
データ基盤を少人数で運用しているので、メンテナンスコストが重いツールの導入はしたくない事情があり、サーバーレスでインフラ面の管理が必要ないのも良かったです。
Googleのプロダクトと親和性が高い
ピクシブではGoogleのプロダクトをメインで使っているので何もせずともリネージで可視化する範囲が増えていく期待がありました。
現時点では、 以下のような連携がされています。
- GCSのファイルをロードした場合には、そのファイルの元となっているGCSのリソースURIを表示してくれる
- Google SheetsをExternalテーブルとしている場合に、Google SheetsのURLまで追いかけて表示してくれる
- Cloud Composerを使っていてBigQuery関連のOperatorでクエリを実行すると、データリネージにtask_idやdag_idを自動で表示してくれる
Google以外のプロダクトとの相互運用性は低いが、Google系のプロダクトをメインに使っているピクシブでは将来的にもメリットが大きいだろうと考えました。
ツールの比較
ツール選定ではデータカタログを
- GCPのデータカタログによるデータリネージ
- OSSのデータカタログに付随するデータリネージ
- SaaSのデータカタログに付随するデータリネージ
- 独自のツールを構築する
という4つの軸でざっくり整理しました。
dbtやDataformなどのデータモデリングツールでもデータリネージの可視化は出来ますが、dbtやDataformで管理されていないテーブルの依存関係も可視化したいという要件から外れるので比較から外しました。
Dataplexのデータリネージ以外はざっくりドキュメントを眺めたレベルなので、不正確な部分もありますが、自分の調べた限りは以下のような状況であることが分かりました。
試験運用
Dataplexのデータリネージの料金は、以下の3つの使用料に応じて請求されますが、これらを詳細に見積もるのに時間がかかりすぎることが想定されました。
そのため、まずは試験運用をして、ツールの使用感やコスト対効果を測定をしました。
Dataplexのデータリネージでは3つの請求が発生します。
- Dataplex部分の料金
- リネージを生成するために処理したDCUリソース(Dataplex premium processing)
- DataCatalog部分の料金
- APIの呼び出し回数
- 生成されたメタデータのストレージ量
見積もる際に時間がかかりそうだと考えていたのは、リネージを生成するために使用されるDCU使用量と、生成されたメタデータのストレージ使用量の部分です。
APIの使用量は社員のアクセス数などで見積もりが出来ますが、生成されるメタデータのストレージ量、DCUリソースは実験してみないと分かりませんでした。
本番運用
試験運用をしてみた結果、費用対効果も高いことが分かったので本番導入を進めていきました。
2023年7月18日時点で、ピクシブでは以下のような規模感でBigQueryを使っていますが、月に10万円以下で運用しています。
- データ量
- 6.5PiB
- テーブル数
- 約15万テーブル
- ジョブ実行回数
- 160万回/month
料金をざっくり見た感じ、クエリの生成部分(DataplexのDCU)でコストがかかりがちなのでDDL、 DML、copyなどを頻繁に実行するプロジェクトでは高くなります。
使ってみてどうだったのか？
良かった点
データリネージを導入してから課題となっていた部分が解決出来たので満足です。
- 何か障害発生した際に、どのテーブルに影響があるのかをスグに出せるようになった
- テーブルの依存関係が可視化されたことで整備や、共通化する項目を洗い出しやすくなった
- どのソースデータを使っているかが分かりやすくなり、データの信頼性が高くなった
- テーブルを更新する際に使われているクエリをSQLファイルから追わなくても、データリネージで簡単に分かるようになった
また、APIが有効になっていれば、テーブルの依存関係をPythonのスクリプトで呼び出しやすいのも助かっています。
よく使われるテーブルには下流のテーブルが80個くらいあるケースもあり、手動でリストアップするには辛い所があります。これをSDK経由でAPIからテーブル一覧を取得するスクリプトを書けば、コマンドラインでテーブルを指定するだけでJSONや、行形式でリストアップ出来ます。
別の記事になりますが、こちらで具体的なコードを乗せてあるので気になった方はご覧ください。 zenn.dev
運用する上で詰まった点
- リネージが生成されるまでに少しラグがある
- 権限周りが複雑
リネージが生成されるまでに少しラグがある
リネージはジョブが終わってから約10分ほどで生成されます。
ただし大きいプロジェクトでは初回有効時に1日〜2日かかるケースがあり、本当に有効になっているのか不安でした。
権限周りが複雑
BigQueryはクエリを実行する際に、 参照先のテーブルのプロジェクト、 割り当てのプロジェクトの2つを意識する必要があります。
データリネージで権限を付ける際にも、2つのプロジェクトでAPIの有効化とデータリネージの閲覧権限を付けないとデータリネージが見れません。
これはテーブル関連のメタデータは参照先のプロジェクトで権限管理、クエリを生成しているメタデータは割り当てプロジェクトの権限管理しているためです。
例: プロジェクトAのテーブル hogeからプロジェクトAのテーブルfugaを、プロジェクトBの割り当てを使って作成する場合を考えます。
CREATE TABLE `project-A.hoge.hoge` AS SELECT * FROM `project-A.fuga.fuga`
このような場合、プロジェクトAにのみデータリネージの閲覧権限を付与するだけでは不十分で、プロジェクトBにもデータリネージの閲覧権限を付与する必要があります。
データリネージに期待する点(2023年7月18日時点)
個人的に利用する中で、もう少し改善して欲しいと思っているところはユーザー独自で定義しているメタデータがデータリネージで表示出来ないところです。
データリネージではどのような変換処理で、テーブルが生成されるのかをデータリネージで見ることが出来ます。
ここにjob_idや、クエリが入っているのですが追加でクエリのラベル情報も表示できるようになると、どの部署の管轄のクエリか、どのシステムから発行されているクエリか？といった情報も見れるようになり、もっと利便性が高くなりそうだと感じています。
終わりに
BigQueryを使っていてかつ、データリネージを導入したい場合には手戻りも少なく、すぐに導入・撤退できるのでDataplexを検証してみるのはおすすめです。
最後までご覧頂きありがとうございました。
ピクシブでは、一緒にプロダクトを盛り上げてくれる方を大募集しています。 ご興味のある方は、以下のリンクから是非ご応募下さい。
