dbt 把指標定義收回來了

dbt Semantic Layer 把指標定義集中到 dbt，讓不同工具共用同一套 metric。

說真的，這招很實際。dbt Labs 不想讓指標散在各個儀表板裡。它把 metric 邏輯拉回模型層，讓團隊定義一次，後面到處都能用。

這件事會痛，是因為很多團隊都卡在同一種爛事。營收、活躍用戶、留存率，各自有不同版本。會議一開，大家先吵數字，再談決策。

dbt Semantic Layer 到底在做什麼

dbt Semantic Layer 的重點很直白。它把指標定義放進 dbt 專案本身。不是在 Looker、Tableau，或其他 BI 工具裡各寫一份。

這樣做的好處，是少掉重複邏輯。dbt 用 MetricFlow 處理 joins 和 metric 查詢。你改一次 dbt，後面依賴它的工具就跟著變。

講白了，就是把「誰說了算」收斂到資料模型。Revenue 可以只定義一次。之後應用程式、BI 工具、API，都讀同一份答案。

• 指標邏輯放在模型層，不放在 BI 規則裡。
• 下游工具共用同一個 metric 定義。
• dbt 更新後，相關查詢一起跟著更新。
• MetricFlow 負責把 joins 串起來。

為什麼團隊會在意單一指標定義

分析系統常見的問題，不是資料庫不夠快。是同一個 KPI 被寫成三種版本。財務要一種算法，產品要另一種，成長團隊又自己加料。

dbt 的想法，是把這些分歧壓成一個版本。由資料團隊維護，其他工具只負責取用。這種設計很像把規則寫成程式碼，而不是塞在每個報表角落。

這裡可以直接看出產品思路。dbt Labs 想讓 model layer 管業務邏輯。BI 工具就專心做視覺化和探索，不要再當規則工廠。

“A semantic layer is the missing piece of the modern data stack.” — Tristan Handy, co-founder and CEO of dbt Labs

這句話是 Tristan Handy 說的。意思很明確。dbt 想把語意層變成資料堆疊裡的一層標準零件，不是可有可無的附加品。

文件也提到存取控制。這很重要。指標集中後，如果權限沒處理好，資料外洩風險會一起上來。集中化不是免費午餐。

它怎麼包裝設定、部署和存取

dbt 把流程拆得很清楚。先上手，再設權限，接著部署，最後才是給外部工具使用。這種順序很像真正的導入路線，不是只寫給 demo 看。

要用這功能，你需要 dbt 的 Starter 或 Enterprise 方案。文件也支援 multi-tenant 和 single-tenant。只是 single-tenant 需要聯絡代表開通。

這裡還有一個很實際的點。dbt 提到 exports、scheduled queries、result caching、declarative caching。意思是你可以在新鮮度和速度之間做取捨。不是每次都硬打即時查詢。

• Quickstart 先教你怎麼接起來。
• Build your metrics 說明怎麼定義 metric。
• Administer 講 token 和 credentials。
• Deploy 介紹怎麼把語意層部署出去。

和舊式 BI-first 模式比，差在哪裡

傳統 BI 堆疊常見的做法，是每個工具自己定 metric。短期很方便。長期就很慘。因為每個 dashboard 都可能長出自己的算法。

dbt 的做法，是把 source of truth 拉回資料模型。這樣一來，變更只要修一次。下游工具不用各自補丁式修改，維護成本會低很多。

如果你在看競品，這個差異很重要。dbt 不是只做查詢層。它想把「定義 metric」這件事，變成資料工程流程的一部分。

• 一份 metric 定義，取代多個 BI 工具的重複邏輯。
• 一次修改，傳到所有依賴它的應用。
• 一套權限規則，少掉分散管理。
• 透過 API 和整合層，讓更多系統直接讀 metric。

如果你想看 dbt 的平台方向，可以順手看 dbt Fusion Engine 的脈絡。它和語意層一起看，會更容易懂 dbt 想把開發流程往哪裡收。

這波真正的考驗是採用率

dbt Semantic Layer 的想法很乾淨。把 metric 當成 code 管理。版本化、集中化、共享化。這比讓每個 BI 工具自由發揮，乾淨太多。

但架構漂亮，不代表大家會乖乖用。真正的問題是，團隊會不會放棄在 dashboard 裡重寫指標的老習慣。很多公司不是不懂，而是懶得改流程。

我覺得最務實的做法，是先挑一個高風險指標。像營收、付費轉換、留存率都可以。先在 dbt 裡定義一次，再看它能不能穿過不同工具，還保持同一個數字。

如果同一個 metric 在三個地方都長一樣，這功能就不是裝飾品。它是真的在幫你少吵架。

結論很簡單

dbt 這次不是在賣新名詞。它是在處理一個老問題：數字到底誰說了算。把 metric 收回 dbt，至少能少掉一半的對帳地獄。

下一步很明確。先從一個核心 KPI 開始，別一口氣全搬。你只要能讓一個數字在所有工具裡都一致，就知道這套語意層值不值得繼續推。