dbt Semantic Layer の全体像: メトリクス統一の考え方

同じ「売上」「アクティブユーザー」でも、部門やツールごとに集計条件が違えば意思決定はぶれます。dbt Semantic Layer は、このズレをなくすためにメトリクス定義をコードとして一元管理し、データ基盤全体で再利用できるようにする仕組みです。

本記事では、Analytics Engineer の実務と試験の両方で問われやすい「メトリクス統一」の設計指針、YAML 定義例、変更管理とテストのコツを、公式ドキュメントの安定的な振る舞いに基づいて解説します。

なぜメトリクスを Semantic Layer で統一するのか

BI ツールごとに売上定義やフィルタ条件が違うと、同じ問いに複数の答えが並びます。現場は検証作業に追われ、経営は意思決定を遅らせます。根本原因は、メトリクスが可視化ツールやスプレッドシートなど散在する場所で別々に定義されることです。

dbt Semantic Layer は、メトリクスを YAML で宣言的に定義し、変換後のデータモデルと密に結び付けます。定義はバージョン管理され、レビュー・テスト・デプロイのパイプラインに載せられます。実行時は SQL にコンパイルされ、Snowflake や BigQuery、Databricks、Redshift などの DWH 上で評価されます（実行は各 DWH の権限モデルに従います。詳細は各 DWH 公式ドキュメントを参照）。

資格対策の観点では、メトリクスの一貫性確保、データモデルとの依存関係管理、テストとドキュメンテーションの自動化が重要論点です。Semantic Layer を使うと、これらをプロジェクトの標準運用に組み込めます。

• 定義をコード化し、レビュー可能にする
• 集計条件・フィルタ・時間粒度を明示する
• 変更影響範囲を把握し、段階的リリースを可能にする
• DWH 権限と整合した実行でガバナンスを保つ

dbt Semantic Layer の構成要素

Semantic Layer は、変換済みのファクト/ディメンションモデルの上に「意味」を与えるレイヤーです。YAML で semantic_model（エンティティ・ディメンション・メジャー）を定義し、それを材料に metrics（ビジネス指標）を宣言します。定義は SQL にコンパイルされ、DWH 上で集計が実行されます。

実務で安定的に使われる概念は以下です。記法や詳細オプションは公式ドキュメントを参照してください（docs.getdbt.com）。API 連携やクエリ提供の仕組みは dbt Cloud の機能として提供されます。

• semantic_model: 1つのテーブル/ビューを表現。主キーや外部キーに相当する entity、集計対象の measure、絞り込み軸となる dimension を持つ
• measure: sum、count、count_distinct などの集計。集計対象列や条件を宣言
• dimension: 時間型（日・週・月などの粒度）とカテゴリ型（状態、地域など）を宣言
• entity: join に使う識別子（primary/foreign）を明示し、モデル間の結合経路を安定化
• metric: simple（単一 measure の集計）と derived（他 metric の式合成）を宣言。共通フィルタやデフォルト粒度を付与

モデル設計パターンとデータフロー

基本はスター・スキーマ思考です。ファクトモデル（例: fct_orders）に対して、注文日の時間ディメンションや顧客ディメンションをマート層で整備し、その上に semantic_model を定義します。モデル間の結合は entity で宣言したキーに基づきます。

可視化やノートブックは、Semantic Layer が生成する正規化された SQL を通してメトリクスを取得します。時間粒度やフィルタの差異はクエリ引数として与えられるため、同じ定義から複数のビューを安定的に作れます。

• stg 層でクレンジング、marts 層で分析用整形
• semantic_model は marts を参照（ref）して定義
• entity により多表間の安全な join パスを固定
• 時間ディメンションのデフォルト粒度を明示
• BI/ノートブックは同一メトリクスを再利用

Semantic Layer を中心にしたデータフロー

定義の具体例（YAML）

以下は、受注ファクト fct_orders を対象にした semantic_model と、その上で定義するメトリクスの例です。実際のフィールド名やオプションはプロジェクトに合わせて調整してください。YAML はバージョン管理され、レビューとテストの対象になります。

simple metric で合計売上を、derived metric で平均注文額を定義しています。時間粒度は day をデフォルトにし、共通フィルタとしてキャンセルを除外しています。

• defaults.agg_time_dimension により標準の時間軸を指定
• measure は集計関数と式（列）を宣言
• metric は simple/derived と依存関係を明示
• 共通フィルタで「定義の揺れ」を抑止

semantic_model と metrics の YAML 例

semantic_models:
  - name: orders
    model: ref('fct_orders')
    defaults:
      agg_time_dimension: order_date
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: order_revenue
        agg: sum
        expr: amount
      - name: orders
        agg: count_distinct
        expr: order_id
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: order_status
        type: categorical

metrics:
  - name: total_revenue
    type: simple
    label: Total Revenue
    type_params:
      measure: order_revenue
    filter:
      - {expr: "order_status != 'canceled'"}

  - name: order_count
    type: simple
    label: Order Count
    type_params:
      measure: orders
    filter:
      - {expr: "order_status != 'canceled'"}

  - name: average_order_value
    type: derived
    label: Average Order Value
    type_params:
      expr: total_revenue / order_count
      metrics: [total_revenue, order_count]

運用・ガバナンス: テスト、リリース、変更管理

メトリクスを統一しても、運用で崩れては意味がありません。dbt ではモデルやソース同様に、Semantic Layer の定義を Pull Request でレビューし、CI でテストし、環境ごとにデプロイします。実行は DWH 上で行われ、既存の権限・監査の枠組みに乗ります。

後方互換性のない変更（例: フィルタ条件の変更や式の変更）は、メトリクスをバージョン分岐させ、段階的な切り替えを行います。ドキュメントとカタログで参照先を可視化し、影響範囲を事前に把握します。

• テスト例: null/負値の禁止、カーディナリティ、時間粒度の欠損検知
• ドキュメントでメトリクスの定義・依存関係を公開
• exposure を使ってダッシュボード依存をトラッキング
• リリースブランチと環境（dev/stg/prod）で段階展開
• 非互換変更は新メトリクス名を用意して移行期間を確保

比較: BI 内定義 vs SQL ビュー vs dbt Semantic Layer

メトリクスをどこに置くかで、再利用性や変更影響が大きく変わります。日々の運用と監査を考えると、定義がコードとして一箇所に集約され、DWH 上で一貫して実行される形が扱いやすくなります。

• BI 内定義は手軽だがスケール時に不整合が増えやすい
• SQL ビューは再利用できるが派生メトリクスの管理が複雑化しやすい
• Semantic Layer は依存関係とテストを前提に統治しやすい

問題で確認

よくある質問