Leverages データ戦略ブログ

インハウスデータ組織のあたまのなか

【Google Cloud活用事例】データマート更新~BIツールデータ更新までを自動化!

はじめに

こんにちは。レバレジーズデータ戦略室の辰野です。
前回は、昨年の10月頃にDataformを利用したデータ分析基盤の構築について*1お話しましたが、そこにも記載がある通り、レバレジーズではDWHとしてBigQueryを使用しているため、データ利活用に関わる開発はGoogle Cloudのサービスを使用することが多いです。
というわけで今回は、私がこれまでにGoogle Cloudのサービスを活用した業務の中から「WorkflowsとCloud Functionsを使ったデータマート更新~BIツールのデータソース更新事例」についてご紹介できればと思います。
Google Cloudのサービスでどんなことができるのか?」「どんなデータ更新ワークフローの設計例があるのか?」などを思われている方にとって、少しでも参考になれば幸いです。

Google Cloudで行うことにした背景

元々、Dataformを導入する前から、データマートの更新~BIツール(Tableau)のデータソース更新は、Digdagでワークフローが動的に実行されていました。
ざっくりと説明すると、下記のような流れです。

  • digファイルでSQLファイルを複数個に分割して順番に実行
  • 完了後、Pythonファイルを呼び出し、BIツールのデータソース更新を実行*2

しかし、Digdagはある程度の専門知識が必要になることから、データ更新不備時に即対応できる人員が少ないと、データ利活用に影響が出てしまうことが問題に上がっていました。
また、Digdagでデータマートの更新を行っていた際は、下記のような辛い点がありました。

  • DigdagではSQLファイルを実行しているだけだったので、Dataformでは可能なconfigの設定ができず、スキーマの説明欄を更新することができなかった
  • SQL間の依存関係を考えてワークフローを組む必要があった

これらを解消すべく、Google CloudのDataformに移管したのですが、結果、下記のようなメリットがありました。

  • configの設定を行えるようになったので、データマートのスキーマ情報を充実させることができるようになった
  • 依存関係を考える必要がなくなり、かつ最も効率的な順番でSQLを実行できるようになった
  • テーブル間の依存関係を可視化できるようになり、影響範囲の調査が容易になった

DataformがDigdagの管理外に移ったことを機に、将来的にDigdagを廃止しようと考えていたこともありDataform以降をDigdag管理外にしようという話になりました。
さらに、マネージドサービスに移管したかったので、Google CloudのWorkflowsに移管することになりました。

改修後のワークフロー

新しいワークフローはこのようなアーキテクチャとなりました。
※今回、全体設計はデータエンジニアのメンバーが担当し、私はその中でデータマートとTableauデータソースを更新するWorkflowsとCloud Functionsのコード作成を担当しました

改修後のワークフロー

呼び出し元は、データレイクのデータ更新の処理からワークフローに組み込まれていることもありDigdagから変わりませんが、その後の処理はすべてGoogle Cloudのサービス内で行うようになっています。

改修後の処理の流れは、ざっくり下記のようになっています。

改修後の処理の流れ

実装する中で困ったこと、分かったこと

特に困ったことは、「WorkflowsとCloud Functionsの実行制限時間」です。
Workflows自体の実行時間の上限は1年*3となっていますが、DataformやCloud Functionsを実行したり情報を取得するhttp.postやhttp.getには1,800秒のタイムアウト*4が設定されています。

Dataformの更新自体は実装した時点では数分で完了していたので問題なかったのですが、BIツールのデータソース更新において、同時実行数上限やデータ量の大きいデータソースは更新時間がかかるなど、BIツール側の制御事項の壁にぶち当たりました。
当初は全てWorkflows上で完結させようと考えていましたが、Workflows側の1,800秒の制限時間内には終わらないことが明白であったため、今回はWorkflowsではCloud Functionsの実行のみを行い、BIツールの更新の成功と失敗の通知処理は、最大60分*5実行できるCloud Functions側で行うこととしました。

また、実装してみて分かったことは、Workflowsだと繰り返し処理・並列処理・try-catchのエラーハンドリングを実装することができますが、全てを組み込むとyamlファイルのネストが非常に深くなってしまい、可読性が下がるということです。マネージド実行環境なのは非常に便利ですが、今回ご紹介した処理より複雑なものを載せることには向いていなさそうです。

今後の課題

先ほど困ったこととして記載した内容に付随しますが、現状はTableauのデータソース更新は60分あれば問題ないものの、今後データソースやデータ量が増えた場合に耐えられなくなることは分かっているため、Cloud Composerへの移管を検討しています。
また機会があれば、移管したあとのお話もできればと思います。