⚛️ 基本概念とアナロジー
🧪 化学のメタファー
ソースシステムデータ = エネルギーとクォークのスープ
⬇️
ステージング層 = 原子への凝縮・精製
⬇️
より複雑な構造 = 分子、タンパク質、細胞
🎯 ステージング層の役割
複雑で有用なモデルを構築するための個別コンポーネントをプロジェクトに取り込む基盤
複雑で有用なモデルを構築するための個別コンポーネントをプロジェクトに取り込む基盤
📂 ファイル構造の重要性
- データフローの反映
- ナレッジグラフのインターフェース
- dbtセレクター構文での利用
📁 構造とファイル命名規則
models/staging
├── jaffle_shop
│ ├── _jaffle_shop__docs.md
│ ├── _jaffle_shop__models.yml
│ ├── _jaffle_shop__sources.yml
│ ├── base/
│ │ ├── base_jaffle_shop__customers.sql
│ │ └── base_jaffle_shop__deleted_customers.sql
│ ├── stg_jaffle_shop__customers.sql
│ └── stg_jaffle_shop__orders.sql
└── stripe
├── _stripe__models.yml
├── _stripe__sources.yml
└── stg_stripe__payments.sql
├── jaffle_shop
│ ├── _jaffle_shop__docs.md
│ ├── _jaffle_shop__models.yml
│ ├── _jaffle_shop__sources.yml
│ ├── base/
│ │ ├── base_jaffle_shop__customers.sql
│ │ └── base_jaffle_shop__deleted_customers.sql
│ ├── stg_jaffle_shop__customers.sql
│ └── stg_jaffle_shop__orders.sql
└── stripe
├── _stripe__models.yml
├── _stripe__sources.yml
└── stg_stripe__payments.sql
📋 サブディレクトリのグループ化
✅
ソースシステム基準 - 共通の読み込み方法と属性
❌
ローダー基準 - 大規模プロジェクトには広すぎ
❌
ビジネスグループ基準 - 重複と競合する定義を招く
🏷️ ファイル命名パターン
✅
stg_[source]__[entity]s.sql
二重アンダースコアで視覚的に区別
✅
複数形 - SQLが自然な文章のように読める
🔧 モデルと変換パターン
✨ 標準的な変換タイプ
✅
リネーム - カラム名の統一
✅
型キャスト - データ型の変換
✅
基本計算 - セントからドルへの変換など
✅
カテゴリ化 - 条件ロジックでのグループ化
🚫 避けるべき変換
❌
結合 - 重複した計算と混乱する関係を作る
❌
集約 - データの粒度を変更し、ソースデータへのアクセスを失う
-- stg_stripe__payments.sql
with
source as (
select * from {{ source('stripe','payment') }}
),
renamed as (
select
-- ids
id as payment_id,
orderid as order_id,
-- strings
paymentmethod as payment_method,
case
when payment_method in ('stripe', 'paypal')
then 'credit'
else 'cash'
end as payment_type,
-- numerics
amount / 100.0 as amount,
-- timestamps
created::timestamp_ltz as created_at
from source
)
select * from renamed
🎯 DRY原則
「常に必要」な変換は可能な限り上流で実行し、重複したコードを避ける
「常に必要」な変換は可能な限り上流で実行し、重複したコードを避ける
👁️ マテリアライゼーション
📊 ビューとしてマテリアライズ
ステージングモデルはビューとして構成
💡 理由:
最新データ
→
容量節約
→
構成要素
# dbt_project.yml
models:
jaffle_shop:
staging:
+materialized: view
1:1の関係
各ソーステーブルに対して単一のステージングモデル
各ソーステーブルに対して単一のステージングモデル
🏗️ ベースモデルと特殊ケース
🔧 ベースモデルが必要な場合
クリーンでDRYなステージング層を維持するために結合が必要な場合
💼 一般的な使用例
✅
削除テーブルの結合 - 削除レコードのマーク付け
✅
同一構造ソースのユニオン - 複数地域のShopifyデータなど
base_customers
+
base_deleted
→
stg_customers
🤖 自動化ツール
Codegenを使用してステージングテーブル生成を自動化
- ソースYAMLの生成
- ステージングモデルのボイラープレート
- 効率的なプロジェクト開発
🔄 開発プロセスとベストプラクティス
📈 開発フロー
DAGの順序に従うが、開発は非線形的に進む
DAGの順序に従うが、開発は非線形的に進む
スプレッドシート
モックアップ
モックアップ
↓
SQL
ロジック作成
ロジック作成
必要テーブル
特定
特定
↓
ステージング
作成
作成
🎯 ユーティリティフォルダ
models/utilitiesディレクトリ
- マクロから生成される汎用モデル
- モデリング支援ツール
- 日付スパインなど
🧪 リファクタリングと最適化
機能するモデルができたら、ロジックを分割し、部品を上流の中間モデルに移動
⬇️
結果: クリーンで読みやすいモデル、明確なDAGストーリー、包括的なテスト
🎪 単一の真実のソース
すべての人が同じ原子のセットで構築する
すべての人が同じ原子のセットで構築する