プロジェクトが 数千 model を超えると、ビルド時間・PR レビュー・依存把握 すべてが詰まり始めます。dbt Mesh はプロジェクトを 複数に分割し、プロジェクト間で model を「公開・参照」する仕組み。dbt Labs が 2023〜推奨する大規模対応の標準アーキテクチャです。
Mesh の核：3 概念
| 概念 | 設定 | 目的 |
|---|---|---|
| Group | `schema.yml` の group | model を論理グループに括り、所有者を明示 |
| Access | `access: private/protected/public` | 公開範囲制御 (group内/同プロジェクト/他プロジェクト) |
| Versioning | `v1/v2/v3` で同一 model の複数版 | 破壊的変更を後方互換で管理 |
Group ── 所有者を明示
models/marts/_groups.yml
YAML
version: 2
groups: - name: commerce owner: name: Commerce Team email: commerce@hukuhuku.co.jp description: "売上・注文・返品関連のモデル"
- name: marketing owner: name: Marketing Team email: marketing@hukuhuku.co.jp
- name: hr_pii owner: name: HR Team email: hr@hukuhuku.co.jp description: "人事系 (PII 含む、要承認)"
models: - name: fct_orders group: commerce - name: dim_customers group: commerce - name: fct_campaigns group: marketingAccess ── 公開範囲
| access | 意味 |
|---|---|
| `private` | 同じ group 内からのみ ref 可能 |
| `protected` | 同じプロジェクト内からのみ ref 可能 (デフォルト) |
| `public` | 他プロジェクトからも ref 可能 |
access の宣言
YAML
models: - name: dim_customers group: commerce access: public # 他プロジェクトに公開 description: "全社共通の顧客マスタ"
- name: int_orders__cleaned group: commerce access: private # commerce グループ内のみプロジェクト間 ref
marketing プロジェクトの dependencies.yml
YAML
# 別 dbt プロジェクト (commerce) を依存として宣言projects: - name: commerce_analyticsmarketing プロジェクトの model から commerce の dim を参照
SQL
-- models/marts/fct_campaign_orders.sqlSELECT c.campaign_id, c.customer_id, o.amountFROM {{ ref('this_project', 'fct_campaign_attribution') }} cJOIN {{ ref('commerce_analytics', 'dim_customers') }} cust -- ★ Mesh 越し USING (customer_id)JOIN {{ ref('commerce_analytics', 'fct_orders') }} o -- ★ Mesh 越し USING (customer_id)Versioning ── 破壊的変更を安全に
公開している model に breaking change を入れたいとき、v1 と v2 を並行運用できる。下流が移行完了したら v1 を deprecate。
model versioning
YAML
models: - name: dim_customers access: public latest_version: 2 versions: - v: 1 deprecation_date: '2028-12-31' - v: 2 config: contract: enforced: true # スキーマ契約を強制 columns: - name: customer_id - name: name - name: email - name: tier # ★ v2 で追加下流から版指定で参照
SQL
-- 旧版を使い続けたい場合SELECT * FROM {{ ref('dim_customers', v=1) }}
-- latest を使う (v2)SELECT * FROM {{ ref('dim_customers') }}Contract ── スキーマ契約を強制
公開モデルにはスキーマ契約
YAML
models: - name: dim_customers access: public config: contract: enforced: true # 違反するとビルド失敗 columns: - name: customer_id data_type: string constraints: - type: not_null - type: primary_key - name: name data_type: string - name: created_at data_type: timestamp constraints: - type: not_nullContract の効果
「カラム名・型・制約を変更すると、ビルドが失敗する」 ように強制できる。下流プロジェクトに 意図しない breaking change を投げない ための保険。
Mesh プロジェクトの分割パターン
| パターン | 分割軸 | 向く組織 |
|---|---|---|
| ドメイン別 | commerce / marketing / finance / hr 別 | ドメインチームが明確 (50〜数百人) |
| レイヤ別 | core (共通) + domain-specific プロジェクト | 中央チーム + 周辺チーム構造 |
| 製品別 | の各製品ごと | マルチプロダクト企業 |
| 信頼度別 | 公開 marts / 実験 sandbox | 「公式 vs 実験」を分けたい |
導入の現実的な順序
- 1まず group + access: 1 プロジェクト内で grouping を始める (1 ヶ月)
- 2Contract 導入: 公開すべき model だけスキーマ契約 (2 週間)
- 3Mesh 分割: 最も大きいドメインを切り出して別プロジェクト (1〜2 ヶ月)
- 4Versioning: breaking change を入れる時の保険として (継続)
最初から Mesh は overkill
model 数 500 以下、エンジニア 5 人以下なら 1 プロジェクトで十分。Mesh はプロジェクト間調整コストが増えるので、痛みが出てから導入。
次の話
EP.14 では Semantic Layer / Metrics で指標の正本管理を扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。