Data Lineageについて、調べてみました！
※本稿はテックブログからの転載です。
こんにちは。株式会社JDSCエンジニアリングメンバーの秋山です。
最近、データリネージという言葉を耳にしませんか？
データのリネージ（出自血統）。要するにデータウェアハウジングにおいて、データの生成経路を明らかにして、複雑化するデータパイプラインのマネジメントやガバナンスを強化するというもので、堅牢なデータ基盤を構築するにあたって、これからどんどん深堀りされていくだろうことはわかります。
▲今はまだ明確なトレンドになっていないけど、徐々に右肩上がりになりつつありますね…。
引用元：Google Trends 「data lineage」https://trends.google.co.jp/trends/explore?date=2016-01-01%202021-05-21&q=data%20lineage (参照 2021–05–21)
今回は、そんなデータリネージシステムを調べましたので、ご紹介いたします！
Data Lineageの何が嬉しいの？
例えば、airflowではこのようにパイプラインタスクの依存関係をDAGとして表現できるのですが、実際のデータのエンティティの依存関係には一致していないということがよくあります。(airflow2.0だとまた別の話になりますが）
そんなときにdata lineageが達成され、エンティティの依存関係が明確であれば、エンティティの生成ロジック（SQLなど）を修正する際において、修正するスコープを一目瞭然で限定させることができますね！
また、データ不備が見つかった場合に、その不備のあるのカラムがどうやって生成されたのかという追尾が容易であったり、
後述するBigQuery Data Lineageでは、カラムに付与したポリシータグを後続するテーブルのカラムにも自動的にキャスケーディングし、意図しない情報漏洩も防ぐことができるそうです。
各データリネージシステムについて
そんなデータリネージですが、どういったものが存在するでしょうか？
主にGCPのBigQueryを中心データウェアハウジングすることを想定とした場合、調べたところ以下のようなシステムがありました。
・BigQuery Data Lineage
・Alpha SQL
・Dataform
・DBT
・Cloud Data Fusion
・(Tokern)
順に紹介していきます。
BigQuery Data Lineage
BigQuery 向けにデータリネージ システムを構築 | Google Cloud Blog
BigQueryの Audit Logをもって実行したSQLの構造をパースし、カラムレベルでリネージをLineageテーブルに保存します。
こういった、SQLベースの操作自体から解析してリネージを構成するシステムはパッシブとよばれ、反対に、予めリネージを明示的に構成するシステムについてはアクティブ という種類にあたるそうです。（今回あげた６つのシステムのうち、パッシブなシステムはこのシステムだけです。）
このシステムは以下のようなアーキテクチャで構成されており、技術スタックとして、Dataflow(ZetaSQLによるパース）、pub/sub、Data Catalogが使われていることがわかります。
▲引用元：監査ログ、Pub/Sub、ZetaSQL、Dataflow、Data Catalog を使用した BigQuery データリネージ システムの構築 「アーキテクチャ」https://cloud.google.com/architecture/building-a-bigquery-data-lineage-solution?hl=ja (参照 2021–05–21)
ただ、こちらのシステムを構築すること自体は簡単で、こちらのリポジトリをクローンし、
https://github.com/GoogleCloudPlatform/bigquery-data-lineage.git
java11のmavenをいれた状態で（例えばjava15で行うとサポートされていBないためエラーが起きました）
監査ログ、Pub/Sub、ZetaSQL、Dataflow、Data Catalog を使用した BigQuery データリネージ システムの構築
この手順に沿って行うと、dataflowのストリーミングジョブが立ち上がり、その間はData Lineageが可能となります。（ポリシータグのカスケードいについては下記にあります。）
BigQuery、Data Catalog、Dataflow を使用し、データリネージに基づいて、データアクセス ポリシーを派生テーブルに自動的にカスケードする
注意点として、
・SQL内のテーブル名は全てFQDNでなくてはパースが行えない
・CTEなどもパースが行えない
・ビューには対応していない
と、現時点ではかなり制約が多いです（下２つはissueには上がっているようだけど…)
ただ、audit logからリネージを解析したりする仕組みが面白く、こちらをうまく活用できれば（可視化アプリの実装が待たれる…）、カラムレベルの仔細なリネージも行えそうだと感じました。
Alpha SQL
【BigQuery】 AlphaSQLでスキーマ安全なデータ基盤を構築する
上記では、弊社エンジニアの松井さんがAlpha SQLと呼ばれるSQL静的解析ツールを用いて、BigQuery のクエリファイル群からDAGを生成、可視化する（AirFlowのDAGとして自動生成することも！）手法を載せています。
こちらのDAGはエンティティレベルにはなりますが、既存のSQLの依存関係を一発で出せる（つまり、何を並列実行させるべきか等についても、開発者は考えなくてよくなる）という意味で、手っ取り早く導入したい場合に非常に有用であると考えます。
Dataform
Dataform | Manage data in BigQuery
最近Google Cloudに買収され、もはやBigQuery特化（一応、Redshift,Snowflakeなどの環境に対しても使えます)となりつつあるデータビルドツールです（この呼び方は後述のDBTに合わせて、個人的にそう呼んでおります）。エンティティのリネージだけでなく、カラムに対するテストやテーブルの文書化、定期実行など、やれることが非常に多い印象です。
用いられるのはsqlxと呼ばれる独自のSQLフォーマットで、通常のSQLにconfigと呼ばれるスキーマ情報をセットで記述します。
また、依存関係については、FROM句などに
FROM
${ref("parent_table")}といったように明示的に親テーブルファイルの名前を入れる必要があります。また、dataform用のアカウントを作成し、WebUI上でSQLの作成を行うという点もかなり独特ではありますが、使い勝手が良い印象でした。
▲１つのプロジェクトに接続し、そのデータセット群を管理できる。そして上記にあるようなクエリはgit上で管理される
また、現在(2021年５月21日時点）ではGCPへインテグレーション作業を行なっているらしく、完全導入されればより使いやすくなっていることでしょう。
DBT(Data Build Tool)
こちらは、DataFormよりも拡張性が高いとされているデータビルドOSSツールです。DataForm との具体的な違いにおいて、詳しくはこちらに書かれていますが、DBTはOSSなだけあって対応するデータプラットフォームも多く（SQLだけでなくsparkも操作できる）、どのデータ基盤においても自然に組み入れられたり、より詳細なドキュメントを出力することができたりします（例えば、カラムの型なども追記することができます。とはいえ、実際のエンティティのスキーマには適用することができないので注意！）
▲リネージグラフはローカルから見ることができる。また、dbtにアカウントを登録することでdataformのようなIDEも使うことができる
また、Airflowとも相性がよく、こちらにあるように、dbt_operatorという専用のオペレータがあります。
ちなみに個人的には、Airflowとdbt、Great Expectationsとよばれるデータのテストツールによるベストプラクティスがかなり参考になりました。
[レポート] dbtとAirflowとGreat Expectationsで堅牢なデータパイプラインを構築する #dbtcoalesce | DevelopersIO
Cloud Data Fusion
Cloud Data Fusion | Google Cloud
今までのは、主にクエリベースの、ELTでいえばTrasnformに位置するモジュールのリネージシステムを紹介していましたが、こちらは、Transform以外にELも行えるサービスです。
ノーコードでデータパイプラインを実装できるマネージドサービスで、データのソースもGCP内のcloud storageだけでなく、S3からBigqueryへExtract->Loadも出来たりします。（実際にはDataprocにジョブを送って実行する。そのためDataprocインスタンスが必要)
こちらの優れている点はデータセットのリネージでだけでなく、
フィールドレベルでその関係性などを可視化することができます。
▲公式ドキュメントより抜粋。 引用元：https://cloud.google.com/data-fusion/docs/tutorials/lineage?hl=ja#field_level_lineage
ただし、このサービス、Enterpriseバージョンのみがリネージが使える点に注意してください。
Torkern
Open Source Data Governance Tools | Tokern
最後に紹介するのは、現時点ではBigQueryには対応していませんが、今後GCPサービスに対応するであろうとされるリネージシステムです。
主にデータリネージを、カラムレベルで可視化することができたり、PIIやPHIデータをスキャンすることができます。
グラフの描画にkedro-vizを用いたサーバー上でリネージを閲覧することができたり(demo用のAPPを体験したい場合はこちら）、またpythonのライブラリとしても提供されているので、例えばjupyter notebookなどでアドホック的に分析、可視化を行うこともできます。
▲公式ドキュメントより抜粋。ipynb上ではplotyによって描画。 引用元：Query Parser Example Notebook https://tokern.io/docs/data-lineage/example(参照 2021–05–21)
まとめ
いかがでしたか？今回紹介したデータリネージシステムについては、正直どれも一長一短がありまだ発展途上であるという印象が否めませんが、個人的には、カラムレベルでのリネージの分析を行いたいので（カラムの整合性、妥当性を検証したいといったユースケースはかなりあると考えております。というか、できることならレコードレベルでトラッキングを行いたいのですが、こちらにあるようにそれを実装するコストは最大限に高くメリットを凌駕しがちなので、実際にそれを実現するシステムは今のところありません）、BigQuery Data LineageやTokernにはかなり期待したいところではあります。
いずれにせよ、こちらの技術は日進月歩で発展しますし、より堅牢なデータパイプラインを構築するためにも、今回紹介したシステムの動向を追ってみるのはいかがでしょうか？
参考：
Getting started with Data Lineage https://medium.com/dailymotion/getting-started-with-data-lineage-6307b2b429b3 (参照 2021–05–21)
採用やってます！We’re Hiring!
JDSC社内には各ロールが揃っていますので、他のSIerや自社開発している企業とはレベルが違ったスピード開発が可能になっています。（もちろん、データエンジニアの方も積極的に募集しています）
そういう開発に興味があるエンジニアを絶賛募集中です！