Apache Ossie 进入 Apache 孵化器：50+ 企业支持的语义数据标准来了，AI 离不开它

一、引子：数据团队的"周一噩梦"

每个数据团队的周一上午都在上演同一个剧本。

营销部晨会：月活跃用户数环比增长12%，Campaign 效果显著。产品部例会：月活跃用户数持平，最近改版没什么影响。财务部报告：月活跃用户数下降3%，需要控制营销预算。

三个人说的都是"月活"，数字一个比一个好看------但三个都对。因为每个部门对"月活跃用户"的计算口径不一样：营销算的是登录过任意页面的 UV，产品算的是完成了核心操作的用户，财务算的是有付费行为且登录超过 7 天的用户。

这个场景在数据领域有个专门的名词：语义漂移（Semantic Drift）。同一个商业概念，在不同系统和团队中被定义得不一样，没有一份机器可读的共享定义来结束争论。

而这就是 Apache Ossie 想要解决的问题。

二、Apache Ossie 是什么？

Apache Ossie 是一个行业级的开放规范，定义了**业务语义层（Semantic Layer）和本体（Ontology）**的标准化格式。它的核心思想很简单：用一份供应商中立的 YAML 文件，把你公司里所有关键指标（metrics）、维度（dimensions）和它们的业务关系写下来，让 BI 工具、数据平台和 AI Agent 都能读懂。

Ossie 其实不是从零开始的新项目。它前身叫 Open Semantic Interchange（OSI），2025 年 9 月由 Snowflake 联合 Salesforce、dbt Labs 发起，2026 年 6 月正式进入 Apache 孵化器，更名为 Apache Ossie。

Ossie 的 GitHub 仓库中包含三部分：

核心规范：YAML/JSON 格式的语义模型定义，包括指标公式、维度枚举、实体关系和业务规则
转换器：与 dbt、GoodData、Salesforce、Apache Polaris 等平台的双向转换工具
本体与校验工具：共享词汇表、Schema 校验和完整的 TPC-DS 示例模型

Ossie 的设计目标是去中心化的：每个系统直接从数据源头读取语义元数据，而不是在每对工具之间维护脆弱的点对点映射。有一份 .ossie.yaml，全家桶都能看懂。

三、快速上手：Ossie 的 YAML 长什么样

Ossie 语法的核心是一个 semantic_model 定义，通过 YAML 描述数据集、指标和维度。以下是一个简化的电商分析模型：

yaml 复制代码

semantic_model:
  - name: ecommerce_analytics
    description: 电商销售与客户分析模型
    ai_context:
      instructions: "用于销售分析和客户行为洞察"
    datasets:
      - name: orders
        source: sales.public.orders
        primary_key: [order_id]
        fields:
          - name: order_date
            dimension:
              is_time: true
          - name: amount
            type: decimal
    metrics:
      - name: total_revenue
        description: 总营收
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: SUM(orders.amount)
      - name: monthly_active_users
        description: 月活跃用户（有付费行为且登录超过7天）
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: >
                COUNT(DISTINCT CASE WHEN users.login_days > 7
                AND users.has_payment = true
                THEN users.user_id END)

关键点在于 monthly_active_users 这个指标的定义是精确且机器可读的。任何一个 BI 工具、查询引擎或 AI Agent 拿到这个 YAML 文件，都能算出与财务部完全一致的月活数字。

Ossie 文件的后缀名为 .ossie.yaml，通常存放在版本控制系统中，像代码一样做 Review 和审计。

四、9 个月从发起提案到 Apache 孵化

Ossie 的发展速度让人印象深刻：

时间	里程碑
2025 年 9 月	Snowflake 联合 Salesforce、dbt Labs 发起 OSI 倡议
2025 年 11 月	仓库开源，开放社区参与
2026 年 1 月	v0.1 规范发布（Apache 2.0 许可证）
2026 年 3 月	Denodo 加入，50+ 组织参与
2026 年 6 月	正式进入 Apache 孵化器，更名为 Apache Ossie
2026 年 7 月	GitHub Trending #2，持续贡献中

Ossie 的参与阵容是对其价值最有力的背书。从 17 家发起组织增长到超过 50 家，包括 Databricks、Dremio、ThoughtSpot、Collibra、Salesforce、Oracle、Mistral AI 等------甚至包含了直接竞争对手。当竞争对手愿意坐到一张桌子上定义标准时，说明所有人都意识到碎片化比竞争更烧钱。

项目的孵化提案由 Dremio 工程师、Apache 基金会成员 Jean-Baptiste Onofré 推进------他也是 Apache Polaris 的"破门人"。仓库目前已有超过 100 次提交、35 个合并的 PR，贡献者来自十几家公司，五个 Working Group 正并行推进。

五、AI Agent 的语义底座：Ossie 在栈中的位置

最近 AI 圈都在聊 MCP（Model Context Protocol）和 A2A（Agent-to-Agent），但很多人忽略了一个问题：Agent 能调工具了、能协作通信了------但它怎么理解业务语义？

一个 LLM 被问到"本月营收是多少"，它可能找到 3 张相关的表、多个候选计算公式。它没有办法确定哪一个是公司财务认可的。人类分析师会去问财务总监，但 AI 只能猜。结果是自信满满的错误答案------"自信的错误"是企业 AI 最大的杀手。

看看 Agent 基础设施现在长什么样：

层	协议/标准	解决的核心问题
工具访问	MCP	Agent 如何发现和调用工具
Agent 协作	A2A	Agent 之间如何通信和交接
语义理解	Apache Ossie	Agent 如何理解业务含义
身份权限	OAuth / RBAC	Agent 能做什么不能做什么

有了 Ossie，一个理想的 Agent 工作流是这样的：

Agent 通过 MCP 服务器连接到数据湖仓
Catalog（如 Apache Polaris）验证角色权限，下发短期凭据
查询数据的同时，Agent 拉取 Ossie 定义的指标语义
使用精确的 SQL 公式而非模型猜测来计算营收
最终答案和 CFO 看板上的数字完全一致

Dremio 把这种架构称为 Agentic Lakehouse。它的每一块拼图都已经在开发或孵化中------阿里云、华为云也在跟进类似的能力。这个方向不是科幻，而是未来 6-12 个月就能落地的事情。

六、作为开发者，你现在能做什么？

Ossie 目前是 Podling 阶段，v0.1 规范已稳定。三件值得做的事：

盘清家底。 检查你公司的"月活跃用户""营收""转化率"到底有多少个定义？把它们写下来放进版本控制。语义债务每天在复利增长，早一天还清早一天受益。

上手试试格式。 Clone apache/ossie 仓库，读核心规范，看 TPC-DS 示例模型。如果你在用 dbt，Ossie 的 dbt 转换器已经合并，可以直接试试互转。

参与社区。 孵化器项目是进入 Apache 世界最好的入口。项目有新手友好的 first issue、开放的 Working Group 和每周社区会议。订阅开发者邮件列表 dev@ossie.apache.org 是第一步。

七、结语

从 Apache Arrow（内存格式）到 Apache Iceberg（表格式）到 Apache Polaris（目录），再到现在的 Apache Ossie（语义层），开放标准正在一层一层覆盖数据基础设施的每一块拼图。

Ossie 的真正价值也许不是它今天的能力，而是它背后的信号：当 50+ 家竞争公司能坐下来共同定义一个标准，说明整个行业已经意识到------语义碎片化是一笔所有人都在付、但谁也不该付的债。

让你的数据说同一种语言，让 AI 不再靠猜。

Ossie 的 Working Group 架构

Ossie 目前有五个活跃的 Working Group，每个聚焦一个方向：

高级指标与表达式语言：定义复杂的指标计算和可移植的表达式语法，让一个指标公式在 PostgreSQL、Spark SQL 和 ClickHouse 上都能正确计算。目前这个 WG 正在设计一个类似 dbt Jinja 但更轻量的表达式 DSL。

可组合性（Composability）：让一个语义模型可以引用和扩展另一个模型。比如你定义了一个核心的"客户"模型，业务线模型可以直接继承它并增加特定指标，不用从头写。

目录集成（Catalog Integration）：把 Ossie 模型和数据目录平台（如 Apache Polaris、DataHub、Alation）打通。目标是把语义模型放在 Catalog 里，像管理表一样管理指标。

本体表示：把 Ossie 的概念映射到正式的本体标准（OWL、RDF），让知识图谱和语义层共享同一个词汇表。

模型转换器与开发者工具：构建从 dbt、MetricFlow、LookML 等现有语义格式到 Ossie 的双向转换器，降低迁移成本。