テクノロジー本部の yoshikawa です。普段の業務では LIFULLのデータに関するエンジニアリングを行っています。
今回の LIFULL Creators Blog ではデータリネージや(メタ)データカタログの整備など、データの活用を促進するような取り組みについて紹介します。
ここ数年で、LIFULL が保有するデータの活用に関する問題点が顕著になり、その解決に向けて今回紹介する取り組みを実施しました。
社内データ活用に対する課題と要望
問題を明らかにするため、社内のデータアナリストにヒアリングしたところ下記のような課題と要望があると判明しました。
- 機密情報があるテーブル由来のデータを削除したい場合など、機密情報など特定の情報があるテーブルとその派生テーブルを一発で見たい
- データの仕様書がないこともあり、そのときは生データを見るしかデータを知る方法がないので、データの品質を調べたり探索的な調査を実施する工数が大きい
- アドホック分析などでは、利用頻度の高いテーブルであれば利用しても問題ないと判断して使うことが多いので、利用頻度の高いテーブルを簡単に知りたい
総じて、データ間の関係性や派生先が不明瞭であることによる問題と、データの利用方法や利用状況が不明瞭であることに問題があると判断しました。
解決策としてのデータリネージとデータカタログ
課題と要望の解決を実現するために以下を満たすプラットフォーム構築を行うと決定しました。
- データの関連性を明らかにするデータリネージにより、データ間の関係性や派生先を明確にする
- SSOT(Single Source of Truth)としてデータカタログの構築により、データの利用方法や利用状況を明確にする
以下ではそれぞれについて、実現に至るまでの方法と今後の展望を交えて紹介していきます。
データリネージの整備
データの探索コスト緩和のための解決策としてデータリネージの整備を行います。
まず考えたのは実現手段(ツール)についてですが、OSS であるOpenLineageや dbt の docs 機能などの OSS が候補として挙がりました。
他には Google Cloud の下記ソリューションに倣って Data Catalog(Google Cloud)のタグとして表現することも検討しましたが、テキストのみで表現すると全体像が把握しづらいというデメリットもあります。
今回は LIFULL のデータ基盤として利用している BigQuery のメタデータ(INFORMATION_SCHEMA)をもとにして内製データリネージ可視化 Web アプリケーションを作成することでデータリネージを実現しました。
BigQuery の INFORMATION_SCHEMA から情報収集
データリネージの元となる情報は BigQuery の INFORMATION_SCHEMA から収集しています。
具体的な収集方法は単純なもので、INFORMATION_SCHEMA.JOBS_BY_PROJECT から referenced_tables と destination_table を SELECT し、job を実行している service account で絞り込むというのが大枠です。
INFORMATION_SCHEMA は過去 180 日間のジョブの履歴を保持しているため、その間に参照と更新どちらも行われなかったテーブルはリネージ情報として取得されません。
しかし、そのようなテーブルは後述のデータ利用状況と突合することでもはや利用されていない非アクティブなテーブルであると判断できます。
データリネージ情報収集の副産物として、不要なテーブルを発見しコストカットにも寄与できるのは嬉しい点の一つです。
Streamlit と pyvis による可視化
このようにして入手したデータリネージの元情報は、有向グラフとして可視化しインタラクティブにリネージ情報を閲覧できる Web アプリケーションとして提供しています。
有向グラフの作成には pyvis を利用し、Web アプリケーションフレームワークとして手軽にデータ可視化が行える Streamlit を利用しています。
Web アプリケーションとして工夫した点には、
- エッジ(辺)の数は 1000 件近くあるため、UI 上での入力や GET リクエスト時に絞り込めるようにする
- 注目したいノードを選択することで上位・下位の階層(先祖、子孫ノード)も一覧できるようにする
などがあります。
まだ導入して間もないですが、このデータリネージ Web アプリケーションはさまざまな恩恵をもたらすことが期待できます。
たとえば、データアナリストなどデータ利用者は、再利用すべき一次情報は何かといった判断をデータの仕様書からデータの関係性を調査したり有識者へのヒアリングをせずとも判断できるようになります。
また、エンジニアなどデータ運用者は、非依存関係が多く変更による影響の大きいテーブル・ビューが一目瞭然となり調査の工数が減るというメリットがあります。
将来的には SQL を集約してリネージ生成を
BigQuery の INFORMATION_SCHEMA からジョブ実行履歴を収集・加工し可視化するというアプローチでデータリネージの可視化を実現できました。
しかし、このアプローチは多くのジョブ実行履歴の中からリネージ情報のみを抽出するやや遠回しなものであるため、メンテナンス性や費用対効果という面で改善の余地があります。
他の有力なアプローチとしては、BigQuery のジョブとして実行される前の SQL を一ヵ所に集約しパースすることでテーブル・ビュー・データセット間のリネージを生成するというものがあります。
その最たるものとして注目しているのが dbt(data build tool)による dbt docs 機能です。
dbt models(テーブル・ビュー)どうしの関係性を可視化することリネージ情報を生成可能なことに加え、データに関するドキュメンテーション機能という側面もあるため、
カタログ機能も備えた Data Discovery Platform として機能することも期待できます。
そんな dbt ですが社内での利用に際しては、社内の SQL あるいは SQL 実行の基盤を dbt に集約することが必要になると考えています。
社内での dbt 利用は筆者が属するプロジェクトなど一部の業務においてのみ利用されているのが現状ですが、
これまでの開発においてその有用性は実感できているため、データリネージ機能を含め更なるデータ活用の促進を実現するためにも推進していきたいところです。
データカタログの整備
以前、データ利用の現場からどのような課題意識あるか調査し、Datahub というデータカタログ(データディスカバリー)OSS による解決策の PoC を行いました。
PoC が成功したため Datahub を本格運用することも検討しました。
しかし、今回の要件では分析用データベース(BigQuery)のみを対象としたカタログ作成を行うため、Google Cloud(GCP) で完結できるように、Data Catalog を利用することに決定しました。
(今年の夏に Data Catalog は Dataplex に統合されています)
タグテンプレートの作成とタグ付け
Data Catalog では、エンティティ(BigQuery データセット、テーブル、ビューなど)に対してタグ付けを行うことでデータにメタ情報を付与し
GitHub issues の Label のように任意の文字列を付与することでタグ付けするというアプローチとはやや異なり、
Data Catalog では、文字列型や数値型などの型のある複数のフィールドを持ったタグの定義(タグテンプレート)をあらかじめ作成し、
フィールドに値を入れることでタグのインスタンスを生成する、というアプローチでタグ付けを行います。
この特性上、タグテンプレートの定義はかなり自由度が高く GitHub issues ほどベストプラクティスも定まっていませんが、
今回は汎用的なフィールドを持ちビジネスメタデータを表現するデータディスカバリー用タグと、audit logs から取得したクエリの実行履歴を加工しデータの利用状況の統計値をまとめたタグを付与しています。
前者については運用開始後に利用者のニーズを広く受け入れられるように極力汎用的なタグとして設計し、後者のタグはデータアナリストへのヒアリング結果を基に利用状況データをタグとして付与すると決定しました。
データ利用状況の可視化
前述の利用状況の統計値は一定期間内の情報や抜粋した情報をタグとして付与していますが、全期間のデータの推移は Data Studio(Data Portal)上で可視化しています。
SSOT としての機能に期待
タグの整備が実施された Data Catalog ですが、運用やメタデータの集約という点では発展途上な部分もあります。
今後は社内のデータ仕様書を Data Catalog に集約してデータに関する情報源を Data Catalog に集約するという構想を立てています。
その手段として GitHub 上でデータの仕様書のバージョン管理を行い Data Catalog に Push し閲覧できるようにするのが理想的だと考えられます。
しかし、そのためには仕組みの整備や他職種の巻き込みなどの多様な取り組みが必要とされるため、多くのステークホルダーと協力し長期的に実施することになり、実現までは長い道のりとなりそうです。
新バッチ実行基盤の構築と検証
既に社内には Luigi ベースの既存のバッチ実行基盤が存在しています。
しかし、今回構築したデータリネージ Web アプリケーションと Data Catalog、およびデータ利用状況の基となるデータ生成のジョブは、新たにバッチ実行基盤を通じて実行しています。
求められる要件だけを考慮した場合、既存のバッチ実行基盤を利用したり、Cloud Data Fusionを利用して極力コードを書かずに簡易に作成することも有効な選択肢でした。
しかしながら、今後の拡張性を考慮しデータ基盤への投資的な意味も込めて Argo Workflows で dbt や更新用スクリプトを workflow として実行できるように GKE Autopilot による kubernetes cluster の構築を行いました。
まだ数ヶ月ほど運用した所感ですが、Argo Wokrflows については専用 manifest の知識は必要になるもののより多くの用途での運用でも耐え得ると感じています。
既存バッチ基盤のリプレイスなども視野に入れつつ今後も運用していきたいと考えています。
また、現状では toCサービスにあるような急峻な負荷の増加に対応する必要性は無いため、GKE Autopilotによるマネージドなノード管理で間に合っており、kubernetes cluster の運用効率化という恩恵を受けることができています。
まとめ
データ活用を促進するためのデータプラットフォーム開発と題して、Google Cloud(GCP)や OSS など幅広い技術を用いた開発について紹介いたしました。
データ活用のためにソフトウェアエンジニアリングが活かせる余地はまだまだあると考えており、今後も引き続き開発や改善を実施していきます。
最後に、LIFULL ではエンジニア職などの募集しています。 募集中の求人やカジュアル面談のご応募などについては、こちらのページをご覧ください。
