语义层

在实践中

这个词的老家是分析领域。dbt Semantic Layer、Cube、AtScale、Looker 的 LookML 解决的是同一个问题：每个看板、notebook 和表格都在用自己的 SQL 重新推导一遍「收入」，于是数字对不上了。把指标定义一次，放在数仓之上、工具之下，共享的东西就从查询变成了定义本身。2026 年起，同样这两个字也被用来指代 agentic AI 底下的那层业务定义——Fabric 和 Foundry 说的就是这个意思——所以现在这个词的范围取决于说话的人是谁，值得先讲清你说的是哪一个。

对相当大的一类工作来说，语义层确实是对的、而且够用的工具，这一点应该直说，而不是绕开。如果问题是财务和销售报出来的收入数字不一样、自助分析产出互相矛盾的看板、或者一个 AI 助手需要在数仓上稳定地回答问题，那么数仓之上的一层指标层就解决了它——在下面再垫一个应用平台，是在回答没人问过的问题。语义层不是一个弱化版的本体，它是另一种乐器；在分析类问题上，它是更好的那一件。

它没有承载的是写的那一半。语义层是一份读契约：它敲定一个数字是什么意思，但不管谁有权改动底下的记录、系统里到底存在哪些操作、某次变更要不要走审批、以及事后留下什么证据。ObjectStack 站在这条线的另一侧——定义一个对象的类型化应用元数据，同时声明它的权限、它的动作和它的审批环节，运行时在每一次调用上强制执行全部三者，于是定义治理的是写，而不只是描述读。它不替代数仓上的语义层，认真做 BI 的公司仍然需要一个。