語義層 (或稱指標層) 不僅僅是一個概念，
它更是人們在商業情境中思考和推論分析資料方式的整體典範轉移 [1]
❏ 引言
歡迎回到《非正式寫作》— 理解複雜世界，前往那尚未被命名的自己。
暑假結束啦 ～ 我也從新手村的試用期階段畢業了！這段時間因為通勤以及趕著讓自己快點進入狀況，電子報的更新落了好幾拍，希望各位朋朋們見諒 (期望工作慢慢進入軌道以後可以回復產能)。
前期《數據平台演進: 從數據倉儲到數據經緯》和《湖倉救不了你: 真正卡住數據孤島的是人性》我們聊了組織在 管理 複雜的數據協作時會遭遇到的挑戰以及可能的應對方案。
這次，我們往數據的 應用 靠近一些，來聊聊一個最近又再次回到聚光燈下卻又難以捉摸的概念：語義層 (semantic layer)。
「語義層」是一個被過度使用的詞彙，不同的供應商可能會有不同的定義。可以確定的是，它在資料架構中扮演著關鍵的中間層角色，它位於：
原始資料來源 與 商業智慧(BI)/分析工具之間。這些原始資料來源包括複雜的資料庫管理系統、資料倉儲、資料湖或營運資料庫。
資料的複雜性 與 業務可用性之間。它將複雜的技術資料結構轉化為廣泛可理解的業務術語和概念。
資料倉儲 與 AI agent 之間。它不儲存額外資料，而是賦予資料情境。
軟體世界裡所有的意義與概念都是抽象。今天就讓我們抽絲剝繭來看看「語義層」到底抽象了什麼 ~
.
📚 目錄 & 關鍵字
1. 語義層對你來說是什麼？
2. 語義層的蛻變
3. 將指標(metric)從維度(dimension)解耦
4. 語義層到底抽象了什麼
Keywords: 語義層 | Semantic Layer | Metrics Layer | dbt | Data Modeling🔍 工人智慧猜你也喜歡
《非正式寫作》探索並理解當代世界的多面向特質。
每週更新。馬上訂閱，與 1500+ 位讀者一同升級 ⬆️
❏ 語義層對你來說是什麼？
在 survey 的過程中，在 Reddit 上發現一則蠻有趣的討論串《What does “Semantic Layer” mean to you?》[2]，對於身在推行語義層的組織中的我，不禁嘴角失守：
初始問題是：
在概念和功能上，我發現很多人對語義層的定義略有不同，或者語義層產品採取了不同的方法。
你認為語義層是什麼？你想像中的語義層產品應該做些什麼來促進這一點？
另外，你認為資料產品和語義層之間的關係是什麼？ 以下節錄一些有點憤世嫉俗的回答：
這意味著某個高層去參加了一場會議，然後就抓住了這個詞，他們的上司覺得這是個好主意，然後就推行下來了。他們自己也不知道這到底是什麼意思。語義層與本體論工作有所重疊，而技術人員不喜歡與業務單位密切合作來幫助他們定義業務對象。他們寧願點讚「語義層是一種特定技術實作」這個錯誤觀念，然後就這樣了。我們剛買了一個很貴的 BI 工具。
我們付了很多錢給顧問，他們拿著一份用了這個詞的 PPT 來。有些回覆則別具洞見：
語義層有兩種（嚴格來說是三種）常見的含義：
從概念上來說，它就是連結業務概念（實體、屬性、指標）和實體資料模型的「字典」。我們的業務銷售產品，這是我們銷售的所有產品的表格。我們的銷售人員負責特定區域，這是將銷售人員對應到區域的表格。我們運送貨物，這是記錄我們運送貨物的表格。
這種語義層的版本不與特定技術綁定——事實上，它可以寫在紙上。從根本上說，它只是文字和數學。它是業務和資料團隊之間共享理解的工具。
技術上來說，它是一個介於你的資料倉儲和終端使用者工具（如資料應用程式、BI 工具或試算表）之間的工具。有些 BI 工具內建了語義層（例如 Power BI），有些語義層工具是真正獨立的（例如 AtScale、Cube），有些則只是在資料倉儲之上定義的語義層（例如 dbt Semantic Layer）。
之所以會有這三種意義，是因為你實際上需要同時理解這兩種意義，才能成功建立語義層。所以第三種意義是一個實際的過程，它始於業務及其流程、指標和問題，最終形成一個模型，用於表示這些內容以供使用。
但大多數人只專注於技術層面，特別是它通常帶有快取/OLAP 層，以幫助處理大型分析資料集的查詢效能。他們或多或少完全忽略（或只是口頭上說說）概念定義。
所以很多人在語義層中「建模」，但卻完全脫離了業務如何看待他們的數據或他們提出的問題類型，然後他們面不改色地說：「是的，我們有一個語義層」，但卻沒有人使用他們的儀表板。「語義層」本身的語義可以引起如此廣泛且分歧的討論，頗有一種悖論般的幽默感 (語義層本身語義不明)。
當一個符號能夠指涉的物件眾多，像是上面提到的「業務概念和實體資料模型間的字典」、「介於資料倉儲和終端使用者之間的工具」以及連結上述兩者的「一個實際的過程」，受眾自然有更大的機率傾向用自己熟悉的經驗對其進行解釋。
「微服務」、「AI agent」、「Vibe coding」這些 buzzword 也都有這種特性。但，恰恰也是因為這種特性，這些概念才能引起廣泛的討論，推動著理性世界的前進。
那麼，語義層究竟想解決什麼樣的問題呢？
.
❏ 語義層的蛻變
✔ 集中化之後的新難題
以前，企業談論大數據、數據中台，煩惱的是數據分散，難以集中分析與管理。於是， 數據倉儲 (Data Warehouse)、數據網格 (Data Mesh)、數據經緯 (Data Fabric) 等方法不斷演進。
如今，數據總算集中起來了，我們可以在一個地方看見全貌 (摸到完整的大象)。
但新的難題隨之而來：每個人對這頭大象都有不同的解讀。
有人看到的是身軀的龐大，有人專注於鼻子的長度，有人則在意皮膚的粗糙。當異質資料被整合關聯，開始嘗試回答更高層次的問題時，我們發現 — 問題已經不是「有沒有數據」，而是「如何詮釋數據」。
以「客戶留存率」為例，即使資料全集中在同一個系統裡，不同分析師的計算結果往往仍不一致。即使他們共享相同的數據，但是他們並不共享同樣的語義。
.
✔ 語義層的假象
既然感知與理解存在落差，那是不是只要統一定義就能解決呢？
比方說，「活躍用戶」就定義為過去 90 天內至少有一筆交易的客戶。
這樣一來，當大老闆喊出「活躍用戶數提升 10%」的目標時，行銷、業務、技術等單位聽到的應該就是一致的語言。
可惜，事情往往沒這麼簡單。不同系統或團隊在實作時依舊會有差異：有人只計算成功的交易，有人則包含退款，有人採用不同的時間視窗，等等…。這些差異之所以持續存在，是因為傳統語義層只管理「定義」（中繼資料），卻沒有落實到「執行邏輯」。
於是，我們得到的只是定義上的一致，而非行動上的一致。語義層成了一層「和諧的假象」：大家口頭上都講同一個詞，實際卻各自計算。
結果是重複的工作、矛盾的報表，以及對數據系統日漸加深的不信任。
.
✔ 真正的難題: 信任與治理
語義層的問題並不單單只是「定義是否一致」。即使有了共同定義，如果沒有對計算邏輯、數據來源、適用場景的共識，最後還是會落到「各自解釋」。
它更像是一種 信任協定。只有當跨部門之間願意共享邏輯、協調差異，並透過治理機制持續維護，語義層才能真正發揮作用。否則，它就只是一份貼在牆上的文件，沒有人會在日常決策裡拿它當依據。
會議上，行銷、業務和財務部門同時把「客戶留存率」秀出來，三份報告 三種數字，每個部門都在解釋自己為什麼是對的。討論到最後，焦點已經不在如何提升留存，而是誰的數字才是真的正確？
.
✔ 新的舞台: AI 代理的催化
如果說過去語義層的挑戰在於人與人之間的分歧，那麼 AI 的出現，無疑讓這個挑戰更加嚴峻。
生成式 AI 就像一個能力極強、但不懂內部業務邏輯的新員工。雖能快速讀取企業裡的龐大數據，卻缺乏對上下文的理解。當語義不清時，它給出的答案很可能聽起來有道理，實際卻錯得離譜。
因此，語義層在 AI 時代不再只是簡化存取的工具，更是一個 上下文的速成班，幫助 AI 快速掌握組織內獨特的語言、邏輯和規則。只有這樣，AI 代理才能真正成為可靠的夥伴，協助我們跨領域推理、保持一致，產出有價值的洞見。
.
✔ 從工具到資產
過去，我們常把語義層視為 BI 報表的附屬品，好像只是多了一個方便查詢、方便對齊的工具。到了 AI 時代，語義層的角色正在徹底翻轉。
它不再只是資料平台中的一個技術層，而是 資料堆疊的關鍵隘口：決定了資料能不能被正確地理解、能不能跨部門共享、能不能支撐 AI 的可信推理。
換句話說，語義層既是企業語言的「標準化協定」，也是數據治理的「信任契約」。它左右著一個組織能否在數據洪流中建立共同語言，能否讓 AI 產出可信的結果，最終把數據轉化為真正的競爭力。
.
❏ 將指標(metric)從維度(dimension)解耦
語義層應該如何落地？在我翻閱了一些資料以後，我認為這部影片當中的這個核心概念，最能切中我心：「將指標從維度中解耦」。
在多數組織中，我們經常能看到同一個指標在不同報表裡被反覆定義。
以「營收」為例，在財務部門的報表裡，它依時間維度被拆解成月營收、季營收；在業務團隊的報表裡，則依地區、產品線進行分類；而在高層的 KPI 儀表板裡，營收又和其他指標糾纏在一起。每一次分析，都需要重新把度量 (公式、邏輯) 和維度 (時間、地區、產品) 耦合在查詢之中。導致邏輯被複製貼上、四處散落，帶來不一致的風險。
語義層的第一個實質任務，就是把 度量抽離出來，讓它成為獨立存在的邏輯單元。
所謂「活躍用戶」、「留存率」、「ARPU」，都應該在語義層中被定義成清晰、可重用的 度量，而不是藏在某份 SQL 或某個 Tableau 報表的計算欄位裡。維度 則是觀察的角度： 時間、地區、產品。它們可以掛在度量之上，但不應與其糾纏。
落實「度量從維度解耦」，有三個要素：
定義 (Definition)：度量需要有清晰的定義，並且能夠被版本化、重用。
邏輯層 (Logic Layer)：定義不能只是文件，而是可程式化、可調用的邏輯 (不論透過 SQL、API，或專用語義層工具像是 dbt)。
治理 (Governance)：誰能創建新的度量？誰能修改現有的？如何審核？這些都需要流程與機制來維護，否則很快會退回到混亂狀態。
當度量被解耦後，不同維度下的查詢將自然保持一致，重複的工作和矛盾的報表會顯著減少。更重要的是，這樣的語義層能 為 AI 提供結構化且高信任度的數據語境，避免它一本正經說幹話。
.
❏ 語義層到底抽象了什麼
意義與概念皆是抽象
抽象的本質，就是 隱藏某些「細節」，提供更簡潔的「介面」。變數隱藏了記憶體位址，函數隱藏了重複的計算邏輯，API 隱藏了跨網路的通訊細節。語義層也不例外，它遵循同樣的原則，只是把抽象的對象換成了「數據」。
1. 技術細節 → 商業語言
在底層，數據存在於表格、欄位、日誌與 SQL 查詢之中。這些細節對工程師很重要，卻對商務決策沒有太大的意義。
語義層的第一個任務，就是把這些技術細節隱藏起來，轉換成業務可理解的詞彙，例如「活躍用戶」、「客戶留存率」、「平均每位用戶貢獻收入」，等等 …。
它就像一位翻譯官，讓技術團隊與業務團隊能用同一種語言進行對話。
.
2. 重複邏輯 → 可重用定義
在沒有語義層的情況下，計算邏輯往往散落在各種報表與 SQL 中。一個「營收」指標，可能在不同查詢裡被複製貼上一段 SQL 十幾次，每次都有些微差異。這種模式不僅容易出錯，也讓組織很難維護一致性 (就像寫程式不寫 function 一樣)。
語義層把這些重複的邏輯抽象出來，定義成獨立的度量 (Metric)，成為可以被呼叫和重用的標準元件。像程式設計中的 function，避免冗餘。
.
3. 歸屬分歧 → 治理協作
語義層還抽象了另一個更棘手的細節：跨部門對指標解釋的分歧。沒有語義層時，不同部門各自拿著「自己的數字」出現在會議上，討論的重點往往不是如何解決問題，而是誰的數字才算對。
將度量與維度解耦以後，治理機制得以在比較具體的邊界上施行：「誰能定義」、「誰能修改」與「如何進行審核」。在度量的這個尺度上，ownership 更容易劃分與歸屬。
.
4. 雜亂的上下文 → 組織專屬語境
進入 AI 時代，語義層還承擔了一個新的抽象：它補充了組織專屬的語境。
AI 可以處理大量數據，但它不知道「這家公司怎麼定義活躍用戶」或是「這個產業如何計算流失率」。
語義層就像一本濃縮精煉的文化教材，隱藏掉 AI 不需要理解的背景細節，提供一份準確、可執行的符號與規則。
這樣一來，AI 才能避免一本正經地說幹話，成為真正理解 domain know-how 的助手。
~
語義層並不是一個新的概念 (早在資料倉儲的概念出現的時候，它就已經萌芽)，而是對數據的抽象需求隨著時代的不斷演進。
它隱藏了技術細節、重複邏輯、歸屬分歧 與 雜亂的上下文，並提供了更簡潔的介面 (定義、邏輯與治理的介面)。
讓數據能夠在跨部門、跨角色、甚至跨環境中被正確理解和使用。這就是語義層存在的真正價值。
❏ 結語
語義層不是一個產品或一組工具，而是一種持續的協作過程。
它的挑戰不只是技術，更關乎組織內如何建立信任、形成共識。當數據越來越多、AI 越來越強，我們越需要語義層這樣的「隱形基礎設施」，讓人與機器都能在一致的語境下思考與行動。
很多組織會說自己已經有了語義層，但如果在會議上，大家仍在為「誰的數字才對」爭論不休，那麼語義層就還停留在簡報之上，而不是活在決策裡。
語義層，不該只是語義模糊的名詞，而是能真正成為共享語境、可信邏輯，以及治理契約的起點。
如果這篇文章對您有所啟發，您可以透過以下方式支援我的寫作：
請我喝杯咖啡 ☕
將其轉發給可能也會欣賞它的同伴。
留言告訴我什麼讓你印象深刻，分享你的想法，或只是打個招呼。
💡 我也提供各種諮詢服務。如果您想探討合作方式，請透過我的社群媒體聯絡我，或回覆此郵件。
❏ 本週好讀 🛋️
🦥 parting thoughts 🦥
[1] The Semantic Layer: What It Is and How Should It Be? - https://iamhuy.medium.com/the-semantic-layer-what-it-is-and-how-should-it-be-419904b24e3f
[2] What does “Semantic Layer” mean to you? - https://www.reddit.com/r/dataengineering/comments/1e8bn9v/what_does_semantic_layer_mean_to_you/