dBT 中間層：目的を持った変換ステップ

🧬 分子構造の形成

⚛️ 原子から分子へ

原子

分子

ステージング層の原子を組み合わせて、より複雑で接続された分子形状を作成

🎯 中間層の目的
複雑なタンパク質や細胞（マート）に向けて、特定の目的を持った多様な形を作成

🔄 DAGの矢印形状

多数の
狭い概念

→

少数の
広い概念

ソース準拠 → ビジネス準拠

📐 設計原則

複数の入力、単一の出力

✅ 複数の矢印が入る = 良い
❌ 複数の矢印が出る = 危険信号

📁 構造と命名パターン

models/intermediate
└── finance
├── _int_finance__models.yml
└── int_payments_pivoted_to_orders.sql

📋 ディレクトリ構造

✅ ビジネスグループ基準 - ソースシステムではなく事業領域で分類

🏷️ ファイル命名規則

✅ int_[entity]s_[verb]s.sql

動詞で変換の内容を表現：

pivoted

aggregated_to_user

joined

fanned_out_by_quantity

funnel_created

💡 命名のポイント
SQLを知らない人でも何が起こっているか理解できる明確性を重視

⚠️ 早期最適化の注意

マートモデルが10個未満で問題がない場合は、サブディレクトリは不要

目標： 単一の真実のソース

🔧 変換パターンと用途

✨ 主要な用途

✅ 構造的簡素化 - 4-6個のエンティティを適切に組み合わせ

✅ 粒度の再調整 - ファンアウトや集約で適切な複合粒度に

✅ 複雑な操作の分離 - 理解困難なロジックを独立したモデルに

-- int_payments_pivoted_to_orders.sql
{%- set payment_methods = [
  'bank_transfer','credit_card',
  'coupon','gift_card'
] -%}

with
payments as (
  select * from {{ ref('stg_stripe__payments') }}
),
pivot_and_aggregate_payments_to_order_grain as (
  select
    order_id,
    {% for payment_method in payment_methods -%}
    sum(case
      when payment_method = '{{ payment_method }}'
        and status = 'success'
      then amount else 0
    end) as {{ payment_method }}_amount,
    {%- endfor %}
    sum(case when status = 'success' 
        then amount end) as total_amount
  from payments
  group by 1
)
select * from pivot_and_aggregate_payments_to_order_grain
                

🎪 CTE命名の重要性

pivot_and_aggregate_payments_to_order_grain

SQLを知らないステークホルダーでも目的が理解できる

💾 マテリアライゼーション戦略

❌ エンドユーザーへの公開 - メインプロダクションスキーマには配置しない

💡 推奨オプション

✅ エフェメラル化 - シンプルさを重視、ウェアハウスに不要なモデルを残さない

✅ カスタムスキーマのビュー - より堅牢、トラブルシューティングが容易

🏗️ ウェアハウス出力のUX
スキーマ、テーブル、ビューも重要なユーザーエクスペリエンスの一部

🔍 トラブルシューティング

エフェメラル: 補間されるため表示困難

カスタムスキーマビュー: 独立して確認可能

⚙️ 実装と設計パターン

🎯 変換の例

決済データのピボット

payment_method
別の行

→

order粒度の
カラム

🧮 Jinjaの活用

DRY原則を単一モデル内でも適用

支払方法の動的ループ
保守性の向上
コードの重複削減

📊 具体例の効果
10個の結合を含むマートよりも、2個の中間モデルの結合の方が読みやすい

理想的なDAG形状

▶️ 右向きの矢印

多数・狭い → 少数・広い → マート

🎯 ベストプラクティス

🎪 データガバナンス
適切な権限管理と発見可能性の制御

🔍 3つのインターフェース

DAG - データフローの視覚化
フォルダ構造 - コードベースの組織
ウェアハウス出力 - スキーマとテーブル

🏗️ 複雑さの分散

マートモデルから複雑さを取り除き、中間層で管理

読みやすさ

柔軟性

テスト範囲

コンポーネント
洞察

✅ 粒度の確認 - 他のコンポーネントと混合する前に粒度の正確性を確認

✅ ロジックの分離 - 複雑な変換を独立させてデバッグと改善を容易に

🎨 開発哲学

dbtは常に複雑さにシンプルさをもたらすツール