📝 YAML設定戦略

一元化
設定の統合
⚖️
ファイルサイズ
発見しやすさ

📁 推奨パターン

✅ フォルダ毎の設定 - `_[directory]__models.yml`

🎯 命名規則の利点

  • 先頭アンダースコア - フォルダトップにソート
  • ディレクトリ名含む - ファジーファインドを高速化
  • 辞書名ベース - 内容が明確
❌ プロジェクト単位 - 巨大ファイルで発見困難
⚠️ モデル単位 - 開発効率が低下する場合あり
🎪 カスケード設定
`dbt_project.yml`でディレクトリレベルのデフォルトを定義
-- dbt_project.yml models: jaffle_shop: staging: +materialized: view intermediate: +materialized: ephemeral marts: +materialized: table finance: +schema: finance marketing: +schema: marketing

📂 その他フォルダの活用

🌱 seeds
🔍 analyses
🧪 tests
📸 snapshots
⚙️ macros

🌱 Seeds

✅ ルックアップテーブル - 郵便番号→州、UTM→キャンペーン
❌ ソースデータ読み込み - 適切なELツールを使用

🔍 Analyses

監査クエリの保存

  • Jinjaを使用したバージョン管理
  • audit helperパッケージ活用
  • システム移行時の差異発見

🧪 Tests

単体テスト vs 統合テスト

Generic tests = 単体テスト

Singular tests = 統合テスト

複数モデルの相互作用テストに最適

🔗 プロジェクト分割戦略

🌐 Mesh アプローチ

プロジェクト
A
プロジェクト
B
プロジェクト
C

モノリシックプロジェクトから接続された小規模プロジェクトへ

✅ 分割の適切な理由

ビジネスグループ
部門別のデータ製品所有
データガバナンス
セキュリティ・アクセス制御
プロジェクトサイズ
1000s モデルでの開発体験
ML vs レポート
単一真実ソースを阻害
🎯 基本方針
ほとんどのチーム、特に初心者はMeshの使用を推奨

🔒 ガバナンス例

医療会社のケース

  • PII生データアクセス限定チーム
  • ステージングモデルを独立プロジェクト
  • プライベートパッケージとしてインポート

⬇️ 設定カスケードの活用

🎯 階層的設定

プロジェクトレベル: 全体デフォルト
ディレクトリレベル: フォルダ別設定
モデルレベル: 例外のみ
🏗️ DRY原則の実践
フォルダ構造を活用して設定の重複を排除

🏷️ タグ vs フォルダ

推奨: `dbt build --select marts.marketing`

非推奨: `dbt build --select tag:marketing`

  • フォルダを主要セレクター
  • タグは例外グループのみ
  • 開発者の記憶に依存しない

🎪 スコープ優先度

dbtのカスケード優先度を活用して、ベースライン動作を定義

スキーマ
マテリアライゼーション
バリエーション

⚙️ マクロとドキュメント

⚙️ Macros フォルダ

目的: 繰り返し変換のDRY化

  • 共通ロジックの再利用
  • 保守性の向上
  • 一貫性の確保
📚 マクロドキュメント
`_macros.yml`で目的と引数を文書化
-- macros/cents_to_dollars.sql {% macro cents_to_dollars(column_name) %} ({{ column_name }} / 100.0)::numeric(16,2) {% endmacro %}

📸 Snapshots

Type 2 SCD作成

Type 1（破壊的更新）データから履歴保持テーブルを生成

📖 Documentation blocks

`_[directory]__docs.md`パターンに従い、フォルダ毎にドキュメントブロックを整理

🎯 最終考慮事項

🎪 一貫性が最重要
特定の規約よりも一貫性を重視

📝 カスタマイズ指針

構造を変更する場合：

  1. 理由を深く考える
  2. チームに文書化
  3. 規約からの逸脱を説明

🔄 進化する文書

このガイドはリビングドキュメント

  • dbtの進化と共に変化
  • コミュニティからの貢献歓迎
  • ディスカッションと改善
✅ ガイドのフォーク - プロジェクトREADME・wikiに追加