dbt 関連資格の全体像：Analytics Engineer 資格の位置付け

dbt Analytics Engineer 認定は、データウェアハウス上での変換（T）を設計・実装・品質保証するスキルを測る、ベンダ非依存の実務寄り資格だ。SQL とモデリング、テスト、自動化を横断的に問う。

本稿では、周辺ベンダ資格との位置関係、頻出トピック、学習計画、設計と運用の要点、試験テクニックまでを、実務の視点で整理する。

dbt Analytics Engineer の位置付けと周辺資格マップ

dbt Analytics Engineer 認定は、データ変換パイプラインの中心で「再現可能なモデリング」「信頼できるテスト」「ドキュメンテーションと運用の仕組み化」を実践できる人を想定している。対象はアナリティクスエンジニア、データアナリスト上級者、あるいは DWH 上の T を担当するデータエンジニアだ。

Snowflake や Databricks のようなプラットフォーム資格は基盤機能・運用を深掘りする。一方 dbt は“変換の作法”が主題であり、複数の DWH 上で通用する。現場では、プラットフォーム資格で基盤理解を押さえつつ、dbt 資格で変換の設計・品質・運用を担保する組み合わせが堅い。

• 再現可能なスキーマ変換（モデル階層）を設計・実装する
• tests とドキュメントでデータの“契約”を明確化する
• CI/CD とジョブ実行で健全にデプロイ・運用する
• ソースの鮮度・スナップショットで履歴と品質を管理する

Analytics Engineer の居場所（責務の重なり）

• データエンジニア: EL、スケーリング、セキュリティ
• アナリティクスエンジニア: 変換(T)、品質、運用
• アナリスト: マート消費、意思決定

出題範囲の実務マッピング

試験はコマンド丸暗記よりも、設計判断とベストプラクティスを重視する。実務の作業単位に落として覚えると定着が早い。

特に、モデルの依存関係管理、テスト設計、スナップショットと鮮度、ドキュメントとカタログ、そしてジョブ運用の要点は頻出だ。

• プロジェクト基礎: プロファイル/ターゲット、ref/source、パッケージと再利用
• モデリング: レイヤリング（stg/intermediate/marts）、命名、粒度の一貫性
• マテリアライゼーション: view/table/incremental/ephemeral の使い分け
• テスト: not_null/unique/relationships/accepted_values、severity と運用
• ソース管理: source と freshness、カタログ化、ドキュメント生成
• 履歴管理: スナップショットの用途と戦略（変更検知の考え方）

実務と試験を両立する学習計画（4週間）

用途不問の軽量DWH（DuckDB/SQLite でも可）でミニプロジェクトを1つ作り、各週で成果物を増やす。試験用メモは「判断理由」を書き残すことがポイント。

既存のDWH（Snowflake/Databricks）を使えるなら、権限やコストに注意しつつ本番に近い構成で練習する。

• Week1: プロジェクト雛形、stg モデル、ref/source、基本 tests を導入
• Week2: 中間層とマート層を分離、ドキュメントとエンティティの粒度を決定
• Week3: incremental モデル1本と snapshot1本を追加、freshness を設定
• Week4: 選択子（state:modified+ 等）で CI を構成、ジョブを本番/開発で分離
• 毎週: 失敗例を収集（依存のループ、粒度不一致、テスト抜け）→ 改善メモ化

モデリングとマテリアライゼーションの要点

レイヤリングは試験でも実務でも基盤。stg は生ソースの正規化・軽整形、中間層は結合・集約・ビジネスロジック、marts は消費最適化（ディメンション/ファクト）に徹する。

materialized は目的で選ぶ。view は軽量・即時反映、table は安定供給、incremental は大規模での再計算回避、ephemeral は一時的なサブクエリで依存を増やさない。

incremental では、一意キーで更新を識別し、変更分のみを取り込む。遅延到着の扱いとデータ品質テストの併用まで含めて設計できるかが評価される。

• レイヤの粒度を混在させない（中間層でビジネスロジックを完結させる）
• view と table の切り替えは依存先のSLAを基準に決める
• incremental は一意キーと更新条件を明示。全面再計算の手段も用意
• ephemeral は小規模サブクエリに限定し、複雑化を避ける

incremental モデルの最小パターン（概念例）

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

with src as (
    select
        order_id,
        customer_id,
        amount,
        updated_at
    from {{ source('app', 'orders') }}
)

select *
from src
{% if is_incremental() %}
  -- 変更検知の一例（概念）。更新時刻で増分取得。
  where updated_at > (
    select coalesce(max(updated_at), '1970-01-01') from {{ this }}
  )
{% endif %}

品質保証と運用設計：テスト、鮮度、スナップショット、ジョブ

tests はデータ契約。not_null/unique/relationships/accepted_values を中心に、重大度(severity)で運用の振る舞い（警告か失敗か）を制御する。スキーマの安定性に合わせて配置（stg で構文的、marts でビジネス制約）を分ける。

source と freshness は上流の健全性を監視する仕組み。遅延到着が常態なら閾値を適切に設定し、失敗時の通知と再実行をジョブで一貫化する。

スナップショットは履歴保持の標準手段。行の同一性キーと変更検知方針（例：列値の変化を検知）を決め、履歴列の自動付与で有効期間を管理する。

• tests: not_null + unique の組み合わせで主キー制約を表現
• relationships: 外部キー整合性を marts 境界で担保
• freshness: 上流 SLA に合わせた warn/error のしきい値
• snapshot: 履歴列の自動管理で SCD Type2 を簡潔化
• ジョブ: state ベースの選択子で差分実行、失敗時は再試行を短周期で

試験テクニックと落とし穴の回避

設問は“何を作るか”ではなく“どう判断するか”を問う。要件（SLA、粒度、履歴、品質、運用）に対し、最小の仕組みで満たす選択肢を選ぶのが基本。

ひっかけは、粒度不一致、ref/source の取り違え、incremental の誤用（キー不在/全件上書き）、tests の不足や severity 誤設定など。

• ref はモデル依存、source は外部テーブル参照。混同しない
• スナップショットは履歴保持、incremental は更新効率化。目的で選ぶ
• ephemeral は大規模結合に不向き。テーブル化で安定供給へ
• tests は“失敗時の行動”まで設計（通知・再実行・抑止）
• 時間配分: 一巡で消去法→フラグ、二巡で難問へ。最後に用語問題を回収

問題で確認

よくある質問