はじめに
この記事では、dbt を Cloud Run Jobs で定期実行する方法について紹介します。
dbt の実行をスケジュール化することで、データパイプライン処理を自動化することができます。
Google Cloud 上で dbt をスケジュール実行する方法
まず、Google Cloud 上で dbt をスケジュール実行する際に利用するサービスとしては以下が挙げられます。
それぞれのサービスのメリットとデメリットをまとめてみました。
Cloud Composer
- メリット
- dbt を定期実行させるだけなら DAG を airflow にデプロイしてスケジュールするだけで済む
- デメリット
- Cloud Composer のアーキテクチャは様々なリソースを使用しているためコストが高い
- 起動のオーバーヘッドが大きい
- composer と airflow のバージョン管理が面倒
Batch
- メリット
- GPU を使用できる
- コンテナだけでなくスクリプトを使用してジョブを定義できる
- デメリット
- 実行環境として GCE が使用されているため軽量なジョブにはオーバースペック
Cloud Run Jobs
- メリット
- Cloud Run 単体でジョブを完結させられるため学習コストが低い
- 低コスト
- デメリット
Cloud Run Jobs を使って dbt をスケジュール実行する
今回は dbt の定期実行が目的であり複雑な処理は行わないので、Cloud Run Jobs を使って実装していきます。
構成図
今回作成する環境の構成図です。
処理の流れとしては以下の通りです。
- Github Actions で Docker イメージを GCR へ push
- Github Actions で Cloud Run Jobs をデプロイ
- Cloud Scheduler で Cloud Run Jobs を定期実行
- Cloud Run Jobs がサービスアカウントの権限を使用して BigQuery へ dbt 実行

コード
ここでは実装に使用するコードを紹介します。
Dockerfile
Cloud Run Jobs では Docker イメージを使用する必要があります。
以下はサンプルの Dockerfile です。requirements.txt に dbt 実行に必要なライブラリを記載します。
Github Actions
Github Actions から Cloud Run Jobs をデプロイするため、Github Actions と Google Cloud を連携する必要があります。
Github Actions と Google Cloud の連携方法については、Workload Identity を使った GitHub Actions と Google Cloud の連携方法を参照してください。
上記リンクで紹介している yaml ファイルのcloud auth login by workload identity
より後の処理を、以下の様に書き換えます。
これで Docker イメージを GCR へ push し、Coud Run Jobs を更新する Actions が作成できます。

備考
実装時のポイント
- Github Actions で Cloud Run Jobs を更新する際は、create や update ではなく deploy(create or update)を使うことで新規作成と更新の両方に対応できます。
- Dockerfile 側に
dbt run
を定義せず、gcloud beta run jobs deploy
の--command
オプションでdbt run
を定義することで、他の処理を行う job が必要になった際も共通の Dockerfile で対応できます。
Terraform では以下のリソースを作成します。
- Cloud Run Jobs にアタッチするサービスアカウント
- Cloud Run Jobs を定期実行するための Cloud Scheduler
まとめ
この記事では、dbt を Cloud Run Jobs で定期実行する方法について紹介しました。
これにより、dbt のジョブを自動的にスケジュールし、管理コストを抑えつつ、データパイプライン処理を自動化することが可能になります。
参考

備考
Hakky ではエンジニアを募集中です!まずは話してみたいなどでも構いませんので、ぜひお気軽に採用ページからお問い合わせくださいませ。
