认识 Apache Ossie：开放语义交换标准落户 ASF

---

写在前面

2026 年 6 月，一个项目悄悄进入了 Apache 孵化器。我敢说，它对未来十年数据领域的影响，会和 Iceberg 对上一个十年一样重大。

这个项目叫 Apache Ossie，以前叫 Open Semantic Interchange（开放语义交换）。它的使命是标准化一个数据行业从未真正标准化过的东西：我们的数据到底意味着什么。

我得先交代清楚我的立场——老读者都知道我一贯的做法。这个提案的发起人 Jean-Baptiste Onofré 是我在 Dremio 的同事，而 Dremio 是这个项目的三个核心开发公司之一，另外两个是 Snowflake 和 dbt Labs。我从 OSI 刚发布就开始写它，还在之前关于 Apache Polaris 和 AI Agent 标准的文章里预测过它的走向。现在看着它进入 Apache 基金会，感觉就像看着自己的预言比预期更快成真。所以没错，我不中立。

但我能提供的一直都是：证据、坦诚的警告，以及让任何人都能看懂的说明。

Ossie 活在数据世界里一个特别模糊的角落——语义层、指标定义、本体论——这些词连资深工程师都觉得云里雾里。大多数相关文章都假设你已经懂这些行话了。我想反过来。读完这篇文章，你应该能理解：

• Ossie 要解决什么问题
• 项目里面到底有什么
• 为什么它需要一个厂商中立的家
• ASF 孵化意味着什么
• 为什么它出现在 AI Agent 浪潮的中间不是巧合

不需要任何语义层知识储备，我们从头开始。

---

问题：一个所有人都经历过的故事

先别想技术，想象一个普通公司的周一早晨。

市场总监走进领导层会议，放出一张幻灯片：月活跃用户增长了 12%。产品总监跟着展示她的仪表盘：月活跃用户持平。CFO 基于财务团队的数据仓库查询，给出的是：下降了 3%。

三个聪明的团队，三份仔细的分析，同一个简单的指标，三个不同的数字。

接下来 40 分钟，会议不是在决策，而是在争论谁的数是对的。

这里有个让人不舒服的事实：会议室里没有人是错的。

• 市场部把打开过应用的人都算上了
• 产品部只算执行了有意义操作的用户，并且排除了内部测试账号
• 财务部算的是付费席位，而且他们的数据管道有 1 周的延迟

每个定义都有道理。问题在于：公司从来没有用一种所有工具都能共享的格式，把到底哪个是真正的定义写下来。所以每个工具、每个团队都悄悄发明了自己的版本。

行业给这个病起了个名字：语义漂移（semantic drift）。同一个业务概念，在组织内的不同系统里定义不一致，每加一个新工具、每来一个新员工、每建一个新仪表盘，漂移就更严重一点。

每一个数据从业者都经历过某种版本的这种会议。

但 2026 年的新情况是：谁来参加这个会议变了。

现在公司正在把 AI Agent 指向他们的数据，用自然语言提问：我们的流失率是多少？这次营销活动效果如何？哪些客户有风险？

一个 Agent 被要求计算流失率，它看数据仓库，发现有三张表可能相关，有好几个看似合理的公式，但没有办法知道业务部门认为哪个才是对的。人类分析师遇到这种情况会走到隔壁问问同事。Agent 只是选一个，自信地算出来，结果是一个看起来合理但未经任何人认可的逻辑算出的数字。

把这个场景乘以每个 Agent 每天回答的每个问题，语义漂移就从长期困扰升级成了急性风险。

旧有的漂移成本——会议争吵、工程师花数周手动协调系统间定义、迁移项目因为业务逻辑困在一个厂商的工具里而卡住——已经够糟糕了，但行业忍受了几十年。AI 带来的成本是最终迫使这个问题必须解决的那个。

这就是 Open Semantic Interchange 诞生的背景，也是它变成 Apache Ossie 的背景。

---

语义模型到底是什么？用大白话说

在解释 Ossie 之前，我得先讲清楚它要标准化的东西。因为"语义模型"这个说法听起来比实际要玄乎得多。

语义模型就是公司的数据字典，但写得足够精确，让软件也能用。

它捕获几类东西：

指标（Metrics）

公司运营所依赖的有名字的数字：收入、流失率、月活跃用户。每个指标都有精确的公式、适用的过滤条件、以及它在什么粒度上测量。

维度（Dimensions）

你切分这些数字的方式：按地区、按月、按产品线、按客户群。

实体和关系（Entities & Relationships）

业务的"名词"：客户、订单、订阅，以及它们之间怎么连接。包括那些不性感但至关重要的事实，比如"销售系统的 Customer_Code 和计费系统的 Account_UID 指向同一个客户"。

具体来说，一个语义模型条目对于那个让我们头疼的指标，可能会用结构化的、机器可读的形式写成这样：

metric:
  name: monthly_active_users
  description: 在过去30天内执行了至少一个合格操作的不同用户数，排除内部账号
  formula: count(distinct user_id)
  filters:
    - event_type in [qualifying_action_list]
    - is_internal = false
  grain: user_id
  source: analytics.events

像这样写下来，定义就不再是口口相传的"传说"了。

• BI 工具可以读它，直接构建仪表盘
• 数据工程师可以针对它做测试
• AI Agent 可以引用它，并基于它计算
• 当业务决定改定义时，在一个地方改，所有消费者自动跟着变

这些都不是新想法。BI 厂商卖语义层卖了十几年，dbt 之类的工具让指标定义成了现代数据栈的一等公民。问题从来不是语义模型不存在，而是每个工具说自己的方言。

你的 BI 工具语义层里的定义、dbt 项目里的定义、数据目录里的词汇表、CRM 系统里的配置——都是用不兼容的格式写的，互相读不懂，于是各自漂移，结果就是我们又回到了那个周一早上的会议。

更糟的是，因为你的业务逻辑困在每个工具的专有格式里，离开任何一个工具，就意味着要重写你公司的"大脑"——这种锁定比任何数据格式锁定都更致命。

如果你看过我其他的文章，这个问题的模式应该很眼熟：

• 数据文件在 Parquet 之前有这个问题
• 数据表在 Iceberg 之前有这个问题
• 数据目录在 Iceberg REST 协议和 Polaris 之前有这个问题

每次的解法都一样：别标准化工具，标准化交换格式。

Ossie 就是把这个解法应用到"意义"本身。

---

Apache Ossie 到底是什么

现在说项目本身。因为 Ossie 对于带"语义"这个词的东西来说，出奇地具体和实在。

打开 GitHub 仓库 github.com/apache/ossie，你会发现这些内容：

核心规范（Core Specification）

最核心的部分是一个厂商中立的格式，用 YAML 和 JSON 表达，用来写语义模型——就是我们刚说的指标、维度、实体和关系——让任何工具都能无损地读写。

这个规范以人类可读的文档加上机器可读的 schema 一起发布。工具开发者可以验证一个模型是否符合规范。

这是项目的核心：不是你要运行的软件，而是一个关于如何表达"意义"的协议。

具体结构长什么样

一个典型的 Ossie 模型文件大概是这样：

# ossie-model.yaml
version: 1.0
name: retail_analytics

metrics:
  - name: revenue
    description: 总销售收入，不含退款
    formula: sum(amount)
    filters:
      - transaction_type = 'sale'
    grain: transaction_id
    source: sales.transactions

  - name: churn_rate
    description: 过去30天内未执行任何操作的活跃用户占比
    formula: churned_users / total_active_users
    dimensions: [region, plan_type]

dimensions:
  - name: region
    description: 客户所在地区
    type: string
    values: [NA, EMEA, APAC, LATAM]

entities:
  - name: customer
    description: 付费客户
    attributes:
      - name: customer_id
        type: string
        primary_key: true
      - name: region
        type: string
    relationships:
      - target: subscription
        type: one_to_many

这不是在展示一个随意的例子。这就是 Ossie 要标准化的东西：一套通用的骨架，让任何工具都能理解你的业务逻辑。

为什么需要 Apache 基金会

你可能想问：为什么不能直接发布一个格式，让大家用就行了？

答案是：信任和治理。

如果这个格式归 Dremio、Snowflake 或者 dbt Labs 任何一家公司所有，其他厂商凭什么相信它不会在某天被用来偏袒某个供应商？语义模型定义了业务的核心逻辑——谁控制了语义模型格式，谁就控制了数据生态系统的中心。

放到 Apache 基金会意味着：

1. 厂商中立：没有一家公司能单方面改变规范
2. 社区治理：决策由贡献者共同做出，不是由一家公司的产品路线图驱动
3. 知识产权保障：所有贡献都以 Apache 2.0 许可发布，任何人都可以自由使用
4. 长期稳定性：Apache 项目不会因为某家公司被收购或改变战略方向而突然消失

这正是 Iceberg 走过的路，也是 Polaris 走过的路。标准必须独立于任何单一供应商才能成为真正的标准。

孵化意味着什么

进入 Apache 孵化器（Incubator）不是终点，而是起点。它意味着：

• 项目被 ASF 认可为有潜力的顶级项目
• 需要建立健康的社区、足够的代码贡献、清晰的治理流程
• 通常需要几个月到几年才能毕业成为顶级项目

但更重要的是，孵化阶段的 Ossie 已经是可以用的。规范已经写好了，schema 已经发布了，工具厂商已经开始集成了。孵化只是让这个标准有了一个中立的家，让更多人放心地参与。

---

时机：为什么是现在

你可能注意到了，Ossie 进入 Apache 的时间点——2026 年中——恰好是 AI Agent 疯狂涌入企业数据场景的时间。这不是巧合。

AI Agent 放大了语义问题

在 AI Agent 出现之前，语义漂移主要是人类的问题：

• 分析师花时间协调定义
• 会议争吵
• 迁移项目卡住

这些都是"慢速"问题。公司可以忍受，因为成本是渐进的。

但 AI Agent 改变了这个局面：

• Agent 以机器速度运行
• Agent 同时回答成百上千个问题
• Agent 不会主动问"你确定这个定义对吗？"
• Agent 会自信地给出错误答案

一个自信的错误比一个不确定的错误更危险。

从"人找数据"到"数据被找"

传统的 BI 流程是：人提出问题 → 人找到数据 → 人理解含义 → 人构建查询 → 人解读结果。

AI Agent 的流程是：人提出问题 → Agent 找到数据 → Agent 理解含义 → Agent 构建查询 → Agent 解读结果 → 人被告知答案。

在这个新流程里，语义理解从人的责任变成了 Agent 的责任。如果语义模型不存在或者不标准，Agent 就只能猜。猜的结果就是那个周一早上的会议，但这次没有人来争论，因为没人知道 Agent 用了什么定义。

标准化是 Agent 时代的"语法"

想想看：我们不会让一个 Agent 随意解析 CSV 文件而不指定 schema。我们也不会让它随意连接数据库而不提供连接信息。

但我们现在却让 Agent 随意解释业务指标的含义，而不提供标准化的语义模型。

这就是 Ossie 要填补的空白。它给 AI Agent 提供了一本"业务词典"——不是自然语言写的，而是机器可读的、精确的、可验证的词典。

---

实际用例：谁在用，怎么用

场景 1：BI 工具之间的语义共享

假设你的公司同时使用 Tableau 和 Power BI。两个工具都有自己的语义层，但定义是独立的。

用 Ossie：

1. 在 dbt 中定义指标，导出为 Ossie 格式
2. Tableau 读取 Ossie 模型，自动构建仪表盘
3. Power BI 读取同一个 Ossie 模型，得到完全一致的定义

同一个指标，两个工具，一个真相。

场景 2：AI Agent 的"业务上下文"

你部署了一个 AI Agent 回答业务问题。

没有 Ossie：

用户：我们的月活跃用户是多少？
Agent：找到 events 表，count(distinct user_id)，返回 1,234,567
（但 Agent 不知道要排除内部账号，也不知道要过滤合格事件）

有 Ossie：

用户：我们的月活跃用户是多少？
Agent：读取 Ossie 模型，找到 monthly_active_users 定义
- 公式：count(distinct user_id)
- 过滤：排除内部账号，只算合格事件
- 来源：analytics.events
Agent：正确计算，返回 987,654

差了一个定义，差了 25% 的差距。

场景 3：数据迁移时的"业务逻辑保留"

当你从 Snowflake 迁移到 Databricks，或者从 Redshift 迁移到 BigQuery：

没有 Ossie：你需要在新平台上重新定义所有指标，过程痛苦且容易出错

有 Ossie：语义模型是平台无关的，迁移计算引擎但不迁移业务逻辑

---

项目现状和路线图

截至 2026 年 6 月，Apache Ossie 在孵化器中的状态：

• 规范 v1.0：已发布，定义了核心语义模型格式
• 参考实现：Java 和 Python 的参考实现正在开发中
• 集成：Dremio、Snowflake、dbt Labs 已经开始集成
• 社区：正在招募贡献者，包括规范编写、工具开发、文档和测试

接下来的方向：

• 版本管理：语义模型本身也需要版本控制，当业务定义改变时，历史查询需要能回溯
• 发现协议：如何让工具自动发现可用的语义模型
• 联邦查询：如何跨多个语义模型（比如不同业务部门）进行联合查询
• AI 原生集成：如何让 LLM 直接理解和利用 Ossie 模型

---

我的看法：为什么这很重要

我已经跟踪这个项目从它还是"Open Semantic Interchange"的时候就开始写了。说实话，我没想到它会这么快进入 Apache。

但仔细想想，这其实很合理：

1. Iceberg 证明了标准化数据格式的价值——现在每个云数据平台都支持 Iceberg
2. Polaris 证明了标准化目录协议的价值——现在多个厂商在实现 REST 协议
3. Ossie 是下一个逻辑步骤——标准化"意义"本身

没有语义标准化，AI Agent 就像是瞎子摸象——看起来在回答问题，实际上不知道自己在说什么。

Ossie 给 AI 提供了一副眼镜，让它真正"看到"业务数据的含义。

这不是一个"锦上添花"的项目。在 AI Agent 大规模部署的时代，语义标准化是安全的必要条件。

---

一些坦诚的提醒

我不想把 Ossie 说得完美无缺。任何标准在早期都会面临挑战：

• 采用速度：标准的价值取决于采用。需要足够多的工具厂商支持才能形成网络效应
• 治理平衡：三个核心公司（Dremio、Snowflake、dbt Labs）之间需要保持健康的张力，避免任何一方主导
• 复杂性管理：语义模型可以非常复杂，需要平衡表达力和易用性
• 与现有标准的竞争：不是所有人都认为需要另一个标准，有些人会坚持用现有的专有方案

但话说回来，Iceberg 早期也面临同样的质疑。真正的标准不是靠权威赢得的，而是靠解决实际问题的能力赢得的。

---

总结

Apache Ossie 本质上在做一个很简单但极其重要的事：让"数据意味着什么"这件事，不再是一个秘密。

它把藏在 BI 工具里的指标定义、散落在 dbt 项目里的业务逻辑、记录在 Wiki 上的数据字典，统一成一个开放的、厂商中立的、机器可读的格式。

在 AI Agent 时代，这不再是"好要有"的功能，而是"必须有"的基础设施。

如果你想深入了解：

• 项目主页：Apache Ossie（孵化中）
• GitHub 仓库：github.com/apache/ossie
• 规范文档：包含在仓库中，从 v1.0 开始看起

我还会继续跟踪这个项目。如果它走的路和 Iceberg 一样，未来几年你会看到每一个主流数据工具都支持它。当那天到来时，那个周一早上的会议终于可以变成真正的决策会议，而不是定义辩论会。

---

一如既往，我欢迎你的反馈。有什么想法、问题、或者你已经在尝试集成 Ossie，随时告诉我。