dbt Exposures でダウンストリームを管理する: BI・アプリ・MLの参照整理

dbtのExposuresはダッシュボード、アプリケーション、MLジョブなどの“データの利用側”をdbtプロジェクトに明示的に登録する仕組みです。

Exposuresは実行対象ではなくメタデータですが、系譜図、ドキュメントサイト、選択子による再構築の起点として強力に機能します。本稿では実装パターンと試験で問われやすい要点を整理します。

Exposuresの役割とユースケース

Exposuresは、dbtモデルやソースを消費する外部資産（BIダッシュボード、業務アプリ、バッチ/ストリーミングMLなど）をYAMLで宣言し、系譜に参加させるためのリソース種別です。宣言後はdbt docsの系譜図で上流・下流がつながり、選択子で上流の再実行をトリガできます。

代表的な効果は3つ。影響範囲可視化（どのダッシュボードが壊れ得るか）、変更駆動の再構築（+exposure選択で必要最小限を再実行）、責任の明確化（ownerフィールドで連絡先を一元管理）です。

• 試験観点：Exposures自体は“実行されない”メタデータである点を混同しない
• 実務観点：owner.emailの記載はインシデント時の一次連絡に必須
• 可観測性：docsサイトと系譜を通じて影響範囲レビューを定例化

Exposureの型と定義要素

typeはダウンストリームの性質を表します。一般的にdashboard、analysis、application、mlを用います。どの型でもdepends_onでref/sourceを列挙し、owner（name/email）とmaturity（low/medium/highなど）を指定します。urlとdescriptionは運用で価値が高いので省略しない方がよいです。

Exposuresは系譜上のシンクとして振る舞い、depends_onに列挙した上流ノードを境に影響範囲が閉じます。モデル追加・差し替えの際は、ダッシュボードが参照する派生マートが必ず列挙されているかをレビューします。

• 必須級: name, type, owner.name, owner.email, depends_on
• 推奨: maturity, url, description, tags, meta
• 型の使い分け: dashboardはBI、applicationは外部プロダクト、mlは学習/推論パイプライン、analysisは随時解析物

モデルから下流資産（Exposure）への系譜

実装手順とYAML例、比較で理解する位置づけ

実装はシンプルで、プロジェクト配下の任意のschema.ymlにexposuresセクションを追加します。depends_onにはrefとsourceを混在させられます。例ではLookerのダッシュボードを対象に、経営KPIマートと顧客ディメンション、そして生イベントのソースを紐づけています。

比較表で、Exposuresがモデルやソースとどう役割分担しているかを確認します。

• exposuresは複数定義可。命名は利用者視点で一意に
• depends_onは実際の参照粒度（マートや集計テーブル）に合わせる
• PRレビューではownerとurlの妥当性を必ずチェック

exposuresのYAML定義例

version: 2

exposures:
  - name: weekly_kpi_dashboard
    type: dashboard
    maturity: high
    url: https://bi.example.com/dashboards/123
    description: 経営KPIダッシュボード（週次更新）
    owner:
      name: BI Team
      email: [email protected]
    depends_on:
      - ref('mart_kpi_summary')
      - ref('dim_customer')
      - source('app', 'events_raw')
    tags: ['bi', 'executive']
    meta:
      tool: looker
      schedule_cron: '0 7 * * 1'

運用のコツ: オーナー情報・説明・タグとメタ

owner.emailはインシデントの一次連絡先として重要です。maturityは変更リスクの優先度付けに活用できます。urlはダッシュボードやアプリの実体に必ずリンクさせます。説明文には更新頻度、SLO、主要指標の定義などを短く入れておくと、docsサイトからの一次情報で十分に判断できます。

tagsとmetaは統制に効きます。tagsで領域や重要度をラベルし、metaには外部ツール識別子（例: tool=looker, tableau, superset）や運用スケジュール、所有部署コードを入れてクエリ可能にしておくと、棚卸し・影響分析が容易です。

• 命名規則: {domain}_{artifact}_{granularity} などで一意性と探索性を担保
• maturity=highのExposureは変更時のレビューと通知を厳格化
• metaは組織固有フィールドを許容。レポジトリ横断の横串管理に便利

選択子とCI/CD・スケジューラ連携

Exposuresは選択子と組み合わせると真価を発揮します。+exposure:名前 で“Exposureの上流”を選び、必要最小限の再構築を実現できます。これはダッシュボードの健全性チェックや、特定アプリへの影響を限定した回帰テストに有効です。

変更差分に基づく再構築ではstate:modifiedと組み合わせ、変更のあったモデルから影響するmaturity=highのExposures上流のみをビルドする、といったガードレールを設計できます。スケジューラやCIでは、ビジネスクリティカルなExposure単位のジョブを用意しておくと運用が安定します。

• 上流を再構築: dbt build --select +exposure:weekly_kpi_dashboard
• 全Exposureを列挙: dbt ls --select exposure:*
• 差分駆動: dbt build --select +state:modified,exposure:* --defer --state path/to/artifacts

CIの例: クリティカルExposureの健全性ジョブ

dbt build --select +exposure:weekly_kpi_dashboard --warn-error --fail-fast

試験対策チェックポイント（Analytics Engineer向け）

Exposuresは実行対象ではない。YAMLで宣言し、系譜とdocsに表れる。上流の再構築は選択子（+exposure:...）で実現する。この3点は頻出です。

depends_onにはrefとsourceを混在できる。owner.emailは連絡先としてdocsに表示される。typeはダッシュボード等の種別で、挙動を変える設定ではなく分類目的である。これらは細かい設問として出やすいポイントです。

• 用語整理: Exposureは“下流利用資産”、Modelは“変換”、Sourceは“生データ宣言”
• 選択子: exposure:パターンは選択に使えるが、Exposure自体は実行されない
• ドキュメント: dbt docs generateでExposuresもサイトに反映される

問題で確認

よくある質問