dbt 試験の問題例: ドメイン別サンプル問題集（Analytics Engineer 対応）

本稿は dbt Analytics Engineer 試験に備える受験者向けのドメイン別ミニ問題集です。範囲はモデリングとDAG、マテリアライゼーション、テスト、スナップショット、Jinja/マクロとパッケージ、実行とデプロイの6領域に分け、各領域で頻出の判断ポイントを短く確認できるようにしました。

問題設定は公式ドキュメントの挙動を前提にしており、バージョンに左右されにくい基本機能を中心に扱います。個別の UI 仕様やクラウド固有機能は細部が変わり得るため、コマンドや YAML 設定などのコア概念に注目してください。

ドメイン1: モデリングとDAG（ref と source の正しい使い分け）

dbt の DAG は、ref と source による依存関係定義から自動生成されます。ref は dbt 管理下のモデル間依存、source は外部テーブルの宣言とマッピングです。分析業務では、stg 層で命名規約に沿って正規化し、marts 層でビジネス粒度に集約するのが定石です。

試験では、DAG 一貫性、命名規約、依存の向き（上流→下流）、そして exposure による下流可視化の理解が問われがちです。ref を文字列連結で動的に作らない、source はソース定義の YAML と一致させる、などの基本を押さえます。

• ref はコンパイル時解決。ハードコードしたスキーマ/DB名ではなく、アダプタに委ねる。
• source は sources: で宣言し、source freshness を併用すると上流遅延の検知が可能。
• exposures は BI ダッシュボード等の下流アセットを DAG に載せ、オーナーや成熟度を文書化。
• 階層設計の基本: sources → staging → intermediate（任意） → marts（dim/fact）。
• 試験での落とし穴: ref で循環依存を作らない。models 層をまたいだ命名不整合は避ける。

代表的な dbt DAG（sources→staging→marts）

ref と source の基本例

with src as (
  select * from {{ source('raw', 'orders') }}
)
select
  order_id,
  cast(order_ts as timestamp) as order_ts,
  customer_id
from src

ドメイン2: マテリアライゼーションとパフォーマンス選択

マテリアライゼーションはパフォーマンスとコストのバランスを決定します。view は低コストで即時反映、table は安定した参照、incremental は大規模テーブルの更新負荷を抑制、ephemeral は一時サブクエリで最適化余地を残します。

試験では、データ量・更新頻度・再計算コストの組み合わせから適切な選択を判断させる設問が多いです。特に incremental の unique_key と on_schema_change の理解は得点源です。

• 小規模・高頻度更新の参照に view、安定配信用に table。
• 増分更新は unique_key 必須。更新戦略は adapter に依存（例えば MERGE）。
• on_schema_change のデフォルト動作は ignore。要件に応じて append_new_columns 等を設定。
• ephemeral はコンパイル時にインライン化されるため、巨大クエリの複雑化には注意。

incremental モデルの基本パターン

{{ config(
  materialized='incremental',
  unique_key='order_id',
  on_schema_change='append_new_columns'
) }}

with src as (
  select * from {{ ref('stg_orders') }}
  {% if is_incremental() %}
    where updated_at > (select coalesce(max(updated_at), '1900-01-01') from {{ this }})
  {% endif %}
)
select * from src

ドメイン3: テストと検証（generic/custom、source freshness）

dbt のテストは generic（not_null, unique, relationships 等）と custom（SQL ベース）に大別されます。schema.yml に宣言した generic テストはメンテが容易で、失敗時にどの列・どのルールが崩れたかが即時に分かります。

source freshness は上流の遅延検知に有効です。error_after や warn_after を minutes/hours などで閾値設定し、dbt source freshness で評価します。

• unique + not_null の組合せで自然キーの完全性を担保。
• relationships で外部キー整合をモデル間で検証。
• accepted_values はサロゲートコードや状態列の管理に有効。
• custom test は失敗行を返す SQL を書く。

schema.yml での generic テストと source freshness

version: 2

sources:
  - name: raw
    tables:
      - name: orders
        freshness:
          warn_after: {count: 60, period: minute}
          error_after: {count: 120, period: minute}

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: customer_id
        tests:
          - relationships:
              to: ref('dim_customer')
              field: customer_id
      - name: status
        tests:
          - accepted_values:
              values: ['placed','shipped','delivered','returned']

ドメイン4: スナップショット（SCD 管理の基礎）

スナップショットは履歴管理に用います。check strategy は特定列の値変化を検知、timestamp strategy は更新時刻列の前進で検知します。主キーはビジネスキー、updated_at は信頼できる時刻列を選定します。

試験では、dimension の遅延到着や再処理に関する設問が出ます。ソースが履歴を持たない場合は snapshot、持つ場合は単純な増分で十分か、の判断がポイントです。

• strategy=check は値比較。変更列の列挙漏れに注意。
• strategy=timestamp は更新列の単調増加が前提。
• スナップショットはテーブルとして永続化される（管理・再構築の計画が必要）。

顧客ディメンションの snapshot 例

{% snapshot customer_scd %}
{{ config(
  target_schema='snapshots',
  strategy='check',
  unique_key='customer_id',
  check_cols=['name','email','status']
) }}

select * from {{ source('raw','customers') }}

{% endsnapshot %}

ドメイン5: マクロ、Jinja、パッケージの要点

共通ロジックはマクロ化し再利用します。引数で挙動を変えることでモデルの重複を抑制できます。環境差異がある場合は adapter.dispatch によるアダプタ依存実装の切替も有効です。

パッケージは packages.yml に宣言します。セマンティックバージョニングの範囲指定（例: >=, <）で互換性を維持しつつアップデートを管理します。

• set, default, env_var でコンパイル時に値を注入。
• macros/ ディレクトリに配置し、{{ my_macro() }} で呼び出し。
• パッケージ更新は dbt deps。バージョン範囲を明示。

単純なマクロと呼び出し、packages.yml

-- macros/safe_divide.sql
{% macro safe_divide(numerator, denominator, default=0) %}
  case when {{ denominator }} = 0 or {{ denominator }} is null then {{ default }}
       else {{ numerator }} / {{ denominator }} end
{% endmacro %}

-- models/fct_orders_rate.sql
select
  date_trunc('day', order_ts) as day,
  {{ safe_divide('sum(revenue)','nullif(count(*),0)', 0) }} as avg_rev_per_order
from {{ ref('stg_orders') }}
group by 1

# packages.yml
packages:
  - package: dbt-labs/codegen
    version: ">=0.12.0,<0.13.0"

ドメイン6: 実行・選択・デプロイ（run/build/test と選択子）

dbt build はモデル・シード・スナップショットの実行とテストを包括的に行います。単体実行は dbt run、検証のみは dbt test を使います。選択子（--select, --exclude）で対象を絞り、タグやパス、状態比較を活用します。

本番データセットを参照してステージングで下流を解決したい場合は --defer と --state を組み合わせます。state:modified+parents は差分開発で有効です。

• dbt build は順序制御とテスト実行が一体化。初回配信や CI に向く。
• state:modified+parents で修正モデルとその親をまとめて再実行。
• --selector は selectors.yml の論理名を参照できる。
• --defer は解決不能な参照を既存環境の成果物にフォールバック。

selectors.yml と CLI 例

# selectors.yml
selectors:
  - name: ci_changed
    definition:
      method: state
      value: modified+parents
  - name: marts_only
    definition: tag:marts

# 直近変更と親をビルド（既存本番に defer）
# 事前に state を指す manifest.json を用意
# dbt build --selector ci_changed --defer --state path/to/artifacts

# タグ指定で実行
# dbt run --selector marts_only

問題で確認

よくある質問