を導入した組織で 1 年後によく見る失敗パターンを 10 個。それぞれ「こうなったら危険」というシグナルと処方箋セットで。
AP1: 全モデルが table materialization
model 数 500 で `dbt run` が 2 時間。 月額が想定の 5 倍。staging も全部 table、誰も再考していない。
処方箋: staging は view、intermediate は ephemeral or view、marts のうち重いものだけ table か incremental (EP.05)。
AP2: source() を staging 以外で使う
marts や intermediate で `source('raw', 'orders')` を直接使っている model が複数。同じソーステーブルから複数の型変換が走り、結果が食い違う。
処方箋: 1 source = 1 staging model = この staging を `ref()` でしか参照しない。CI で `dbt run-operation` を書いて違反を弾く。
AP3: テスト 0 個で本番運用
`dbt test` でテスト 3 件 (全部 stg__customers の unique のみ)。本番で 顧客重複・FK 不整合・NULL 流入 が頻発。
処方箋: 全 model の主キーに `unique + not_null` 必須化を CI で。最低限 EP.06 の 4 種を組込み、リリース前に 0 件は弾く。
AP4: dbt おじさん化 (1 人依存)
「dbt の事は田中さんに」が定型句。田中さんが休むと PR レビューが止まる。スキーマ変更の影響範囲を聞ける人が 1 人。
処方箋: schema.yml に owner を明記 (EP.07)、Group 制度で複数人 owner (EP.13)、ペアレビューを必須化、月 1 のナレッジ共有会。
AP5: depth 10 のモデル依存チェーン
lineage グラフで「`stg → int → int → int → fct → fct → fct → mart`」のような長鎖。1 個のスキーマ変更で 7 段のリビルドが必要、CI が 30 分かかる。
処方箋: intermediate を 1 段に抑える、共通計算は ephemeral or -friendly な関数化。深さは `dbt list --select +model_x` で測れる。
AP6: incremental の WHERE 抜け漏れ
incremental だが過去の遅延到着分を再取り込みしていない。月末に「先月分の data が 5% 抜けている」事件発生。
処方箋: WHERE で `MAX(occurred_at) - 24h` のオーバーラップを入れる (EP.11 incremental 編で深掘り予定)。月 1 で `--full-refresh` を強制実行。
AP7: macro 過剰で が読めない
1 model に macro が 8 個展開、Jinja の方が SQL より長い。新人がレビューで何が起きるか分からない。
処方箋: macro は 3 回以上同じパターンが出てから作る。1 model に 3 個まで、複雑な model は plain SQL のまま読みやすく。
AP8: 環境分離なし (`dev` で `prod` を直接触る)
個人の dev 環境が prod と同じスキーマ。手元の `dbt run` で本番テーブルを書き換え て事故。
処方箋: profiles.yml で `dev/ci/prod` を必ず分離 (EP.02)、prod は service account 限定、人手で叩けないよう CI 経由のみ。
AP9: dbt docs を生成しない / 公開しない
`dbt docs generate` を見たことがない。schema.yml の description が空欄だらけ。non-engineer から「これって何のテーブル？」が止まらない。
処方箋: CI で description coverage を必須化 (EP.07)、weekly で `dbt docs generate` し社内に公開、未記入は PR を block。
AP10: コスト無関心
BigQuery 月額が前月比 +200%。誰の model が高いか追えていない。dbt run の bytes_billed を見たことがない。
処方箋: `INFORMATION_SCHEMA.JOBS_*` を別 model で集計、model 別の月次コストダッシュを作る。閾値超過で Slack 通知。`maximum_bytes_billed` をデフォルト設定。
ふくふくの『監査チェックリスト』
受託先の dbt プロジェクト診断時に使うチェックリスト。1 つでも No なら改善余地あり。
- 1全 model の主キーに `unique + not_null` テスト ✅?
- 2全 source に `freshness` 設定 ✅?
- 3staging が view、marts が table or incremental の方針 ✅?
- 4depth が 5 段以下に保たれている ✅?
- 5schema.yml の description coverage 80% 以上 ✅?
- 6PR で Slim CI が走り、変更モデル + 下流をビルド ✅?
- 7PR ごとに隔離スキーマ ✅?
- 8月 1 で `--full-refresh` を実行 ✅?
- 9model 別コスト集計をダッシュ化 ✅?
- 10owner が schema.yml に明記 ✅?
ここまでのまとめ
本シリーズ EP.01〜15 で の入門から本番運用まで一巡しました。続編は読者リアクションに応じて、dbt + 統合、dbt + Iceberg、dbt 多テナント運用、生成 による model 自動生成などのテーマで随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。