dbt 資格の勉強法: 公式教材と実機ハンズオンで最短合格を狙う

dbt Analytics Engineer 認定は、モデリング設計、テスト戦略、Jinja/マクロ、依存関係の制御、そして dbt Cloud/CI 運用までを横断的に問います。合格だけでなく、実務での再現性を重視した学習計画が必要です。

本ガイドは、公式ドキュメントと dbt Learn を軸に、Snowflake/BigQuery/Databricks いずれでも再現できる最小構成のハンズオンを提示します。前提知識は SQL と基本的なデータモデリングです。

試験の全体像と出題範囲を地図化する

まずは公式シラバスの確認から始めます。dbt Labs の認定ページでは、出題ドメインと学習リソースの方向性が明示されています。数や配点は更新される可能性があるため、最新の試験範囲を参照してください。

安定して問われるトピックは、モデルのマテリアライゼーション、ソース管理、テスト（singular/schema）、スナップショット、Jinja/マクロ、セレクタと依存関係、ドキュメント化（docs generate/exposures）、および dbt Cloud のジョブ・環境・認証です。

• 公式リファレンスの出発点: https://docs.getdbt.com/
• 資格情報とシラバス: https://www.getdbt.com/certifications/analytics-engineer-certification-exam
• ベンダごとの接続は適宜参照: Snowflake/BigQuery/Databricks の接続手順と権限設計

公式教材の使い分け（ドキュメントと dbt Learn）

学習の軸は、リファレンス（仕様）とチュートリアル（手順）の二層です。仕様は正確さ、チュートリアルは実装の手触りを補完します。両方を往復し、用語とコマンドの定義に常に立ち戻るのが近道です。

ドキュメントでは、materializations、tests、snapshots、selection syntax、adapter 特有の制約など、バージョンに依存しづらい概念を優先的に読み込みます。dbt Learn は Fundamentals を完走し、余力があればアドバンスドのセクション（マクロやパッケージ）へ進みます。

• 仕様系: Models/Materializations、Testing、Snapshots、Docs、Selection Syntax
• 手順系: dbt Learn Fundamentals（プロジェクト作成〜ビルド〜ドキュメント化）
• 更新に注意: コマンドやオプションは v1.x 安定系の記述を基準に確認する

実機ハンズオン計画：最小構成で全領域をカバーする

ベースとなる演習プロジェクトを一つ作り、同一の論理構成を任意の DWH（Snowflake/BigQuery/Databricks）で再現できるように設計します。スコープは staging → intermediate → marts の三層とし、sources、tests、snapshots、docs、selectors を必ず含めます。

CI/ジョブ運用はローカルから開始し、可能なら dbt Cloud に移行してパイプラインを再現します。初回はサンプル CSV(seed) と小さな実データを混在させると、依存関係と差分ビルドの癖を一度に体験できます。

• ローカル: dbt Core（venv/poetry など）で begin → run → test → build の基本サイクル
• DWH 接続: Snowflake/BigQuery/Databricks の最小権限で dev スキーマを分離
• 必須アーティファクト: manifest.json、run_results.json（state 比較とトラブルシュートに活用）

最小構成の dbt プロジェクト依存関係

モデル・テスト・ソース・スナップショットの要点

モデルはマテリアライゼーションの選択（view/table/incremental/ephemeral）とスキーマ戦略（dev スキーマ分離、target 名称）をまず固めます。incremental はユニークキーと差分条件、スキーマ変更時の挙動を明示するのが安全です。

テストは schema.yml 中心に、not_null/unique/relationships を最初に配置します。singular テストは複雑なビジネスロジックに限定し、まずは標準テストで土台を作るのが合格最短です。

• sources: freshness と loaded_at_field を設定し、ソースの健全性を可視化
• snapshots: updated_at または timestamp 戦略を選び、主キーの安定性を確認
• docs: description と column-level docs を早い段階で記述し、catalog で整合を確認

incremental モデルとテスト/snapshot の最小例

-- models/marts/fct_orders.sql
{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',
    on_schema_change='append_new_columns'
) }}

with src as (
  select * from {{ ref('int_orders_enriched') }}
  {% if is_incremental() %}
    where updated_at > (select coalesce(max(updated_at), '1970-01-01') from {{ this }})
  {% endif %}
)
select
  order_id,
  customer_id,
  total_amount,
  updated_at
from src;

# models/marts/schema.yml
version: 2
models:
  - name: fct_orders
    description: 受注のファクトテーブル。増分は updated_at で評価。
    columns:
      - name: order_id
        tests: [not_null, unique]
      - name: customer_id
        tests:
          - relationships:
              to: ref('dim_customers')
              field: customer_id

# snapshots/customers.sql
{% snapshot customers_snapshot %}
{{ config(
  target_schema=target.schema,
  unique_key='customer_id',
  strategy='timestamp',
  updated_at='updated_at'
) }}
select * from {{ source('src', 'customers') }}
{% endsnapshot %}

セレクタとビルド戦略：速く・安全に回す

本番を想定した差分実行では、selectors（state:modified、resource_type:...、tags、+ 依存）を組み合わせて、最小単位のビルドを行います。state 比較には直近の manifest.json を --state で渡す必要があります。

dbt build は run/test/docs/seed/snapshot の一貫実行を扱えます。合格の鍵は、どの場合に build を使い、どの単位で run や test を分割するかを文脈で判断できることです。

• 差分: dbt build --select state:modified+ --state path/to/artifacts
• 影響範囲: dbt build --select +tag:critical
• 限定: dbt test --select fct_orders dim_customers

仕上げ：模試の作り方と当日リスクの削減

模試は自作で十分です。仕様の空欄補充（コマンド/フラグ/セレクタ）、ベストプラクティスの○×、ケース型の手順選択（どの順に run/test/docs を打つか）を混在させて作り、誤答の根拠を全て docs に戻して検証します。

当日は環境差異の知識に依存しすぎないのが安全です。アダプタ差異（例: 一部の incremental オプション）は存在しますが、試験は概念と dbt の標準 API に基づく判断が中心です。

• 暗記カード: materialization と config の対応、選択子、テスト種別の適用場面
• ランブック: 失敗時の再実行順序、state ディレクトリの更新手順
• 見直し観点: 用語の定義を自分の言葉で説明できるか（モデル・リソース・ノード・リレーションシップ）

問題で確認

よくある質問