語義層

在實踐中

這個詞的老家是分析領域。dbt Semantic Layer、Cube、AtScale、Looker 的 LookML 解決的是同一個問題：每個看板、notebook 和表格都在用自己的 SQL 重新推導一遍「收入」，於是數字對不上了。把指標定義一次，放在數倉之上、工具之下，共享的東西就從查詢變成了定義本身。2026 年起，同樣這兩個字也被用來指代 agentic AI 底下的那層業務定義——Fabric 和 Foundry 說的就是這個意思——所以現在這個詞的範圍取決於說話的人是誰，值得先講清你說的是哪一個。

對相當大的一類工作來說，語義層確實是對的、而且夠用的工具，這一點應該直說，而不是繞開。如果問題是財務和銷售報出來的收入數字不一樣、自助分析產出互相矛盾的看板、或者一個 AI 助手需要在數倉上穩定地回答問題，那麼數倉之上的一層指標層就解決了它——在下面再墊一個應用平臺，是在回答沒人問過的問題。語義層不是一個弱化版的本體，它是另一種樂器；在分析類問題上，它是更好的那一件。

它沒有承載的是寫的那一半。語義層是一份讀契約：它敲定一個數字是什麼意思，但不管誰有權改動底下的記錄、系統裡到底存在哪些操作、某次變更要不要走審批、以及事後留下什麼證據。ObjectStack 站在這條線的另一側——定義一個物件的型別化應用後設資料，同時宣告它的權限、它的動作和它的審批環節，執行時在每一次呼叫上強制執行全部三者，於是定義治理的是寫，而不只是描述讀。它不替代數倉上的語義層，認真做 BI 的公司仍然需要一個。