MART
細胞
🧬 細胞の形成：完全なエンティティ
🔬 原子→分子→細胞
S
S
+
I
I
→
アイデンティティと目的を持った完全な細胞を形成
🎯 マート層の特徴
特定のエンティティや概念を固有の粒度で表現する「エンティティ層」
特定のエンティティや概念を固有の粒度で表現する「エンティティ層」
🏷️ エンティティの例
注文
顧客
地域
クリック
決済
各行は離散的なインスタンスを表現
セマンティックレイヤー使用時
正規化を維持してMetricFlowに柔軟性を提供
正規化を維持してMetricFlowに柔軟性を提供
💰 モダンデータウェアハウス
ストレージ安価 × コンピュート高価
⬇️
非正規化によるパフォーマンス最適化
📁 ファイル構造と命名規則
models/marts
├── finance
│ ├── _finance__models.yml
│ ├── orders.sql
│ └── payments.sql
└── marketing
├── _marketing__models.yml
└── customers.sql
├── finance
│ ├── _finance__models.yml
│ ├── orders.sql
│ └── payments.sql
└── marketing
├── _marketing__models.yml
└── customers.sql
📋 グループ化の原則
✅
部門・関心領域別 - ビジネス概念でグループ化
✅
エンティティ名 - 平易な英語で概念の粒度を表現
❌
チーム別の同一概念 - `finance_orders`と`marketing_orders`は避ける
🎯 命名の例外
OK: `tax_revenue` と `revenue`
NG: `finance_revenue` と `marketing_revenue`
明確に異なる概念として設計する場合のみ
⚠️ 早期最適化の回避
マート10個未満でサブフォルダは不要
マート10個未満でサブフォルダは不要
🔧 モデル実装パターン
-- orders.sql
with
orders as (
select * from {{ ref('stg_jaffle_shop__orders' )}}
),
order_payments as (
select * from {{ ref('int_payments_pivoted_to_orders') }}
),
orders_and_order_payments_joined as (
select
orders.order_id,
orders.customer_id,
orders.order_date,
coalesce(order_payments.total_amount, 0) as amount,
coalesce(order_payments.gift_card_amount, 0)
as gift_card_amount
from orders
left join order_payments
on orders.order_id = order_payments.order_id
)
select * from orders_and_payments_joined
🧠 結合の複雑さ管理
4-5個以上の概念を結合する場合は中間モデルを検討
3概念の
中間A
+
中間A
3概念の
中間B
→
中間B
読みやすい
マート
マート
✅
他マートの活用 - 計算済みリソースの再利用でコスト削減
⚖️ バランスの考慮
結合モデル数 × ロジック複雑さ = 総複雑度
結合モデル数 × ロジック複雑さ = 総複雑度
💾 マテリアライゼーション戦略
ビュー（開始点）
⬇️ 遅くなったら
テーブル
⬇️ 構築が遅くなったら
インクリメンタル
📈 段階的アプローチ
シンプルから始めて、必要に応じて複雑さを追加
シンプルから始めて、必要に応じて複雑さを追加
🛠️ 開発時のトラブルシューティング
エラーの原因特定が困難な場合：
- 一時的にチェーン全体をテーブル化
- 実際のエラー発生箇所を特定
- 祖先モデルのエラーを発見
📊 非正規化とワイド化
🏗️ モダンデータスタック
ストレージ安価 → コンピュート高価
⬇️
非正規化による最適化
✅
ワイドで非正規化 - 概念に関するすべてを一箇所に
ID
顧客
注文
決済
地域
商品
...
💰 コスト効率
複数箇所でのデータ構築 > 繰り返し結合
- ダッシュボード高速化
- 再計算コスト削減
- エンドユーザー体験向上
🎯 粒度の維持
他エンティティを含んでも、コアエンティティの粒度は保持
他エンティティを含んでも、コアエンティティの粒度は保持
🎯 ベストプラクティス
🎪 エンドユーザー向け設計
マート層は実際の利用を想定した最初の層
マート層は実際の利用を想定した最初の層
📏 粒度の境界
マート: `orders` (注文レベル)
vs
メトリクス: `user_orders_per_day` (集約レベル)
🔄 DAGの柔軟性
マート層では狭いDAGの制約が緩和
- 異なる粒度間での情報受け渡し
- 計算済みリソースの再利用
- 循環依存の回避
✅
有用なデータの包含 - 粒度レベルでの包括的な情報
❌
過度な結合 - 読みにくさとパフォーマンス劣化
セマンティックレイヤー利用時
正規化アプローチを採用し、MetricFlowの柔軟性を最大化
正規化アプローチを採用し、MetricFlowの柔軟性を最大化
🎨 設計哲学
アイデンティティと目的を持った完全なエンティティの作成