Schedulerが起点 — Workflowsでdbt実行を組み立てる
Cloud Run Jobでdbt buildを実行し、その起動・待機・再試行・定期実行をWorkflowsとCloud Schedulerに分離します。
TL;DR
- Cloud Scheduler が時刻に基づく唯一のトリガー。
- 親Workflowは実行モードを決め、子Workflowへ処理単位を委譲する。
- 子WorkflowはCloud Run Jobの完了を待ち、リトライと失敗を制御する。
01実行の本体
本質はコンテナ内でdbt buildを動かすこと。
Artifact Registryのイメージを使うCloud Run Jobが、BigQueryに対してdbtのモデルとテストを実行する。
02Workflowを重ねる理由
Job起動の共通処理を再利用し、実行単位の選択を親へ寄せる。
親Workflowはstaging/snapshotやintermediate/martの目的を選ぶ。子WorkflowはCloud Run Jobを起動して完了を待つテンプレートになる。
要点：Job起動の共通処理を再利用し、実行単位の選択を親へ寄せる。
03スケジュールと再試行
定刻トリガーと失敗制御を、SQL変換から分離する。
Cloud Scheduler → 親Workflow → 子Workflow → Cloud Run Job → dbt build の順。リトライ上限を超えた失敗はWorkflowの失敗として監視対象にする。
結論
- Schedulerはトリガーであり、処理の実体ではない。
- WorkflowはJobを直接叩くだけでなく、待機・再試行・実行履歴を担当する。
- 物理テーブルの定期更新とviewの手動反映を分けると不要なスキャンを減らせる。