この記事はときは会アドベントカレンダーの5日目です。
※実際にはまだBigQueryを使っているので「移行」という表現は間違っているかもしれません
概要
私が所属している会社では、データ基盤にBigQueryを利用しています。導入当初BigQueryはとても使いやすく快適に作業できていたのですが、次第にデータの規模やデータを用いてやりたいことが増えるにしたがっていくつか課題が発生したため、Dataformを使用することにしました。その際にやったことや、Dataformを使って良かったことをまとめたものです。
BigQueryを利用したデータ基盤
Dataform導入前の状態
- 集計後のデータを可視化する部分でスプレッドシートのコネクテッドシートやLooker Studio、またチームで開発しているAPI等を利用しています。それらで用いるビューを、配置されたデータから作成するところは全てBigQueryの機能で実現していました。ちなみにデータをBigQueryに配置する部分でCloud Functionsを用いたWorkflows等も利用しています。
- 日々BigQueryに最新のデータが追加されるため、最新のものを可視化する必要がありました。定期的にビューを更新するために、BigQueryのスケジュールされたクエリの機能を使用し、それらはBigQueryの画面から設定していました。
- 一方でクエリを確認する際にBigQueryの画面をいちいち見にいくのはエンジニアにとって不便なので、GitHubにもスケジューリングされたクエリのSQLをコピペして置いていました。
このような状況に対して以下の課題がチームで発生していました。
課題
GitHubにいちいちSQLを置くのが面倒
便宜上GitHubを介さずにBigQuery上のクエリを書き換えるだけでデータ基盤の更新ができてしまうので、GitHubはクエリ共有目的だけでした。そのためクエリ更新時に一手間多くかかっていました。
またスケジューリングされたクエリに分析用SQLを全部書くと膨大な行数になってしまうので、作成したいtableごとにviewを分けて配置していましたが、テーブルの個数が増えるたびに両方に手を加える必要があり、いちいち面倒でした。
レビューがしづらく、属人化している
GitHubにSQLを置いたところでクエリの修正内容が正しいか判断できる人が少なく、レビューが十分に行える状況にありませんでした。それによりさらにデータ基盤の属人化が進むという悪循環に陥っていました。
データ基盤の全体像が分かりづらい
データ基盤の設計書を最低限書いてはいましたが更新があまり行われず、また設計書とコードと実際のテーブルの対応関係が見づらいこともありほとんど使われていませんでした。
上記のような課題を解決する方法を探していました。
Dataformの導入
Dataformとは
BigQueryと同様、GCPのサービスの1つです。
大量のテーブルを取り扱う場合や、テーブル同士の依存関係が複雑な場合に効果を発揮します。
もともとは知名度の高いdbtを導入する気分でしたが、偶然Dataformを発見して試しに使ったところ意外と良かったのでそのまま採用されました。
導入時にやったこと
初期設定
以下の記事を参考に実施しました。
ちなみにDataformの公式ドキュメントは新しく始める人にとっては比較的見やすい印象です。
サービスアカウントの権限設定
DataformでSQLを実行する際、サービスアカウントの権限を用いてクエリを実行します。
そのため以下のようなデータを用いる際は、サービスアカウントに権限を追加する必要があります。
- Dataformを作成したプロジェクト以外に置いてあるデータ
- スプレッドシート等、BigQueryの外部をソースとしているデータ
サービスアカウントの権限が足りないと以下のようなエラーが発生します。
reason:"invalidQuery" location:"query" message:"Access Denied: Table test2-project:test1-schema.test: User does not have permission to query table test2-project:test1-schema.test
3層に分けてコードを配置
以下の記事の内容を実施しました。
後で実施しても良いのですが、BigQueryで既にデータソース、データウェアハウス、データマートの3層に分けていたのでスムーズにできました。
テーブル同士の依存関係の設定
FROM句で他のテーブルを参照する際に、${ref("テーブル名")}) のように指定します。これにより依存関係をグラフで確認できるようになります。
ディレクトリをGit連携
こちらの記事を参考に実施しました。
リリース構成＆ワークフロー構成の設定
リリース構成で対象のGitブランチを指定することで定期的にコンパイルがなされ、ワークフロー構成を設定することでクエリの実行タイミングを設定できます。
導入した結果
上記で挙げた課題が解消に向かいました。
- リリース構成とワークフロー構成でGitHubのブランチを指定すれば定期実行までしてくれるので、クエリの更新箇所がGitHub上だけで済むようになりました。
- Dataformで定期実行する際は、「ALL ACTIONS」を選択すれば全てを対象に実行してくれるので、いちいちスケジューリングの対象テーブルを変更する必要が無くなりました。viewとスケジューリングクエリの両方を管理する手間から開放されました。
- レビューとまではいかないですが、他のメンバーが修正箇所を確認してみようという気になってくれました。ちなみにコードレビューについてはGitHubにCodeRabbitを導入したことで最低限の品質は担保できるようになりました。[1]
- テーブル同士の依存関係を設定しておくことで、関係性がグラフとして表示されるようになります。グラフからBigQueryテーブルにアクセスすることもできるので便利〜。特に普段あまりデータ基盤を触らないメンバーにとってありがたいはずです。
感想
普段からデータ基盤を触っている自分だけでなく、チームメンバーにとっても移行によりかなり使いやすくなりました。今回は課題を解消するためにDataformの機能を様々導入してみましたが、普段からBigQueryを利用していればまずはGitHubと連携するだけでも十分便利な印象です。
なおデータ基盤の属人化を防ぐためにDataformを導入しましたが、開発速度が高まりすぎてデータ基盤の変化にメンバーがついていけず、またしても属人化しつつあります…。使いやすすぎるのも考えものかも？
調査する過程でDataformを扱っているブログ記事が意外と少なかったので、個人的にハマった小ネタなどを別途記事にできればと思っています。
-
CodeRabbitはSQLXファイルにも対応していて、複雑なものもちゃんと見てくれるので結構便利です。 ↩︎
Discussion