sourceからGoldまで — SQLを資産として育てる流れ
dbtは BigQuery 上でモデルを依存順に実行し、データ品質を検証しながら分析用のマートへ変換します。
TL;DR
- source は生データの入口、staging は型・名前・粒度を整える境界。
- Silver / intermediate は再利用する業務ロジック、Gold は分析者が直接使うFactとDimension。
- dbt build はモデルとテストを依存順に実行し、壊れたデータを下流へ進ませない。
01レイヤーを分ける理由
「生の事実」と「分析で使う意味」を同じSQLに詰め込まない。
source/Bronze を宣言して起点を固定し、stagingで正規化、Silver・Intermediateで結合や派生、GoldでFact/Dimensionに再構成する。
02lineageを実行順にする
ref() が依存関係を明示し、dbtは正しい順番を組み立てる。
上流モデルを変えると下流へ影響が追跡できる。GoldのテーブルはダッシュボードSQLではなく、BIが使う部品である。
要点：ref() が依存関係を明示し、dbtは正しい順番を組み立てる。
03品質をパイプラインに含める
dbt test は「今日のデータが壊れていないか」をDWH上で確かめる。
unique / not_null / accepted_values / relationships をモデルの契約として置く。dbt buildは上流の失敗で下流のビルドを止める。
結論
- dbtの中心はSQLそのものより依存関係とデータ契約。
- Goldは利用者のために作り、レポートSQLを混ぜない。
- テストをbuildに含めて、異常データの伝播を早く止める。