dbt はデータ可視化基盤のどこにいるのか

Stage 1 — 第2章 | dbt入門カリキュラム推定学習時間：35〜45分 | 難易度：★★☆☆☆

この章で学ぶこと

前章では dbt が Transform 層 であることを整理しました。この章では、もう一段上の視点——データ可視化・BI 全体の中で dbt がどこにいるか——を押さえます。

学習者が混同しやすいのは次の 2 点です。

dbt は BI ツール ではない（グラフは描かない）
BI ツール自身にも DB があるが、それは 分析データのコピーではない

DS Playground を例に、アプリ DB → dbt → mart → BI の流れを図で追います。

この章を終えると、こんなことができるようになります：

アプリ DB、analytics schema、dbt、BI、BI の管理 DB の 責務の違い を説明できる
dbt あり / なし構成の違いを説明できる
ダッシュボードの数字が mart 設計に依存する 理由を説明できる

分析基盤の全体像

Web サービス（ここでは DS Playground）の分析は、ざっくり次の 5 層に分けて考えられます。

flowchart TB subgraph product["1. プロダクト"] APP["DS Playground
Web / API"] end subgraph oltp["2. アプリ DB（OLTP）"] PUB["Supabase public
problem_attempts, consents ..."] end subgraph transform["3. dbt Core"] STG["staging（view）"] INT["intermediate（view）"] MART["marts（table）"] end subgraph analytics["4. 分析用 schema"] AN["analytics スキーマ
（mart の実体）"] end subgraph bi["5. BI"] MB["社内 Metabase"] DASH["ダッシュボード"] end APP --> PUB PUB -->|"source() read-only"| STG STG --> INT --> MART --> AN AN -->|"SELECT"| MB --> DASH

分析データの流れ は、

DS Playground アプリ → Supabase → dbt → analytics mart → Metabase → ダッシュボード

です。dbt は真ん中の 変換・品質管理 を担い、左端の OLTP 書き込みも、右端のグラフ描画も行いません。

各レイヤーの役割

アプリ DB（Operational DB） は、サービス運営のための生データです。会員登録、問題の保存、課金記録などがここにあります。dbt は source('supabase', '...') で 読み取るだけ です。

analytics schema は、分析用オブジェクトを置く場所です。DS Playground では dbt が build した staging / intermediate / marts がここに載ります。

dbt Core は、staging → intermediate → marts という SQL パイプラインと、それに付随する test・docs を Git で管理します。

BI ツール は、接続先（analytics schema）に SQL を投げ、結果を可視化します。Metabase は分析データを丸ごとコピーして持つわけではありません。

BI の application DB（Metabase 自身が持つ DB）は別物です。保存した質問、ダッシュボード、ユーザー権限など BI ツールの設定 が入ります。事業ログや dbt mart のコピーではありません。

分析データ:  Supabase → dbt → analytics mart → Metabase が読む
          管理データ:  Metabase UI → Metabase application DB（質問・権限・レイアウト）

この 2 本の線を混同しないことが、architecture を読むうえでの第一歩です。

dbt なし構成との比較

dbt なし の典型は、アプリ DB から BI へ直接 SQL を書く形です。

Supabase public ──────────────────→ Metabase（ネイティブ SQL）

この構成では、カードごとに似た SQL が増え、「アクティブユーザー」の定義がダッシュボードごとに微妙にずれやすくなります。テストや lineage も弱く、変更の影響が見えにくいです。

dbt あり では、間に Transform 層を置きます。

Supabase public → dbt staging / intermediate / marts → Metabase

指標定義を Git で共有し、mart を SSOT にできます。BI 利用者は 読みやすい mart を見るだけでよく、生テーブルの列名やアプリ都合の JOIN を毎回書き直す必要が減ります。

DS Playground では、production 用 analytics スキーマと CI 用 analytics_ci スキーマを分け、PR では後者だけ build して本番を壊さない、という運用も取っています（詳細は Stage 5）。

BigQuery など別 DWH でも同型

分析 DB が PostgreSQL / Supabase ではなく BigQuery でも、レイヤーの考え方は同じ です。

アプリ DB / イベントログ → BigQuery raw dataset
            → dbt staging / intermediate / marts
            → BigQuery reporting dataset
            → Looker Studio / Tableau / Metabase

製品名が変わるだけで、「Transform を dbt に置く」構図は共通です。

dbt が解決する問題（整理）

アーキテクチャ目線で、dbt を入れる理由を文章でまとめると次のとおりです。

BI 上の SQL が散らばると、同じ指標名でも定義がずれます。生テーブルをそのまま BI に見せると、列名がアプリ都合で読みにくく、JOIN も複雑になります。品質異常は実行して初めて気づきがちで、モデル変更時に どのダッシュボードが壊れるか も追いにくくなります。

dbt は、Transform を コード・test・lineage 付きのプロジェクト として置くことで、これらをまとめて改善する層です。BI はその成果物（mart）を消費する側に徹します。

体系コラム：カリキュラム上の位置づけ

項目	内容
Stage / 章	Stage 1 — 第2章
今回の論点	dbt は可視化基盤の中間層。BI でも OLTP でもない
前章との接続	dbt で信頼できる KPI 定義を作る
次章への伏線	dbt project 構成

まとめ

ダッシュボードの数字は、BI の設定だけで決まるわけではありません。 裏側の mart 設計——その前段の dbt——に依存しています。次章からは、DS Playground の dbt プロジェクトの フォルダと設定ファイル を読んでいきます。

確認問題

問題 1

dbt Core の役割として 最も適切 な説明はどれですか。

A. Web アプリケーションの HTTP サーバー
B. Metabase のグラフ描画エンジン
C. 分析用 mart を SQL で build し、test と docs を付ける Transform 層
D. OLTP へのバックアップツール

正解: C

問題 2

BI ツールの application DB について、正しい説明はどれですか。

A. OLTP の全テーブルを毎日コピーした分析用 DWH
B. ダッシュボード定義・質問・権限など BI ツール自身のメタデータ を保存する DB
C. dbt の build 生成物フォルダ
D. 売上トランザクションの正本

正解: B

問題 3

「OLTP を BI ツールが直接読む」構成の 典型的な問題 として適切なのはどれですか。

A. BI ツールが SQL を発行できない
B. 同じ KPI 名でもカードごとに SQL 定義が微妙に異なる
C. OLTP が必ず PostgreSQL になる
D. dbt docs が自動生成されない