过去几年，数据团队一直在追一个目标：让业务指标有统一口径。
但现实往往不太理想。
同一个「收入」，在财务报表里是一种算法，在 BI 看板里是另一种算法，在数据科学 notebook 里又变成第三种算法。到了 AI Agent 时代，问题更复杂：大模型要回答业务问题，必须理解数据表、字段、关系、指标、时间口径和业务同义词。如果这些定义分散在不同工具里，AI 看起来很聪明，实际很容易答出一套「听起来合理但口径错误」的结果。
Apache Ossie 正是在这个背景下出现的。
它不是要再做一个 BI 工具，也不是要替代 dbt、Snowflake、Databricks、Salesforce、GoodData 或其他语义层产品。它要解决的是更底层的一件事：给语义模型一个开放、中立、可交换的表示格式。
简单说，Ossie 想成为 AI、BI、数据目录和语义层工具之间的「语义交换标准」。
如果放到国内数据团队更熟悉的语境里，它和 OneData、指标体系、数据资产目录、企业 Wiki 其实在回答同一个问题：
组织里的业务语义，应该沉淀在哪里，又如何被系统真正使用？
一、真正的问题不是没有语义层，而是语义层彼此不通
今天的数据栈已经非常丰富。
数据仓库有自己的建模方式，BI 工具有自己的语义层，数据目录有自己的资产描述，AI 分析工具又需要额外的业务上下文。每个系统都在努力描述「业务数据是什么意思」，但它们的描述方式并不统一。
这会带来四类典型问题。
第一，指标漂移。
一个 KPI 在不同工具里重复定义。只要一个地方改了，其他地方没有同步，数字就会慢慢分叉。最后会议上大家争论的不是业务本身，而是「为什么你那边的收入和我这边不一样」。
第二，人工翻译成本高。
当团队要从一个平台迁移到另一个平台，或者让多个工具共享同一套语义定义时，通常需要工程师手动翻译字段、指标、关系和权限上下文。这类工作繁琐、容易出错，而且很难长期维护。
第三，AI 缺少可靠 grounding。
AI Agent 做数据分析时，不应该直接猜表名和字段含义。它需要知道哪些字段是维度，哪些指标可以聚合，哪些表之间可以关联，「GMV」「销售额」「收入」这些业务词到底指向哪个指标。如果语义定义互相冲突，AI 不是没有答案，而是会给出不可信的答案。
第四，集成债越来越重。
假设有 N 个语义层或分析工具，如果每两个工具之间都做点对点转换，理论上需要 N × (N - 1) 条转换路径。工具越多，连接越复杂，维护成本越高。
Ossie 的判断是：与其让每个工具两两互通，不如先定义一个共同格式。每个工具只需要能导入和导出 Ossie，就可以通过它和其他工具交换语义模型。
这就是典型的 hub-and-spoke 模式：Ossie 是 hub，各个工具是 spoke。
二、Ossie 到底定义了什么
从项目结构看，Apache Ossie 的核心是一套 JSON / YAML 格式的语义模型规范。
它关心的不是数据怎么存，也不是 SQL 怎么执行，而是把业务语义抽象成一组可以被工具读取、验证、转换的结构。
Ossie 的核心模型主要包含几类对象。
Semantic Model 是最顶层的容器，用来描述一个完整语义模型。
Datasets 表示逻辑数据集，可以理解为业务实体或事实表、维度表，例如 orders、customers、store_sales。它们会指向底层物理表、视图或查询来源，并声明主键、唯一键和字段。
Fields 表示数据集内的行级字段，可以是简单列引用，也可以是计算表达式。字段可以标注数据类型，也可以标注是否是时间维度。
Relationships 描述数据集之间如何关联，支持简单外键，也支持复合键。
Metrics 表示业务指标，例如 total_revenue、average_order_value、customer_lifetime_value。指标定义在模型级别，可以引用多个数据集。
AI Context 是一个很值得注意的设计。Ossie 允许在模型、数据集、字段、关系和指标等层级添加 AI 上下文，例如业务说明、同义词、示例问题和使用指令。这说明它不是只面向传统 BI，也是在为 AI Agent 使用语义模型做准备。
Custom Extensions 则负责保留厂商特有信息。不同平台一定会有自己的额外配置，Ossie 不试图把所有厂商能力都塞进核心规范，而是允许通过 vendor_name + JSON data 的方式保留扩展信息。
这点很关键。
一个开放标准如果只追求最小公约数，很容易丢失实际生产系统里的重要信息；如果什么都标准化，又会变得庞大而迟缓。Ossie 的做法是：核心语义尽量统一，厂商差异通过扩展携带，并在转换过程中尽量保留。
换句话说，Ossie 不是一份给人看的说明书，而是一份给系统看的语义契约。
三、一个简单的 Ossie 模型长什么样
Ossie 使用 YAML 会比较直观。一个简化后的模型大概像这样：
version: "
semantic_model:
- name: sales_analytics
description: Sales and customer analytics model
ai_context:
instructions: "Use this model for sales analysis"
datasets:
- name: orders
source: sales.public.orders
primary_key: [order_id]
fields:
- name: order_date
expression:
dialects:
- dialect: ANSI_SQL
expression: order_date
datatype: Date
dimension:
is_time: true
- name: amount
expression:
dialects:
- dialect: ANSI_SQL
expression: amount
datatype: Decimal
metrics:
- name: total_revenue
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(orders.amount)
datatype: Decimal
ai_context:
synonyms:
- "revenue"
- "total sales"
这段 YAML 里有几个细节值得看。
首先，字段和指标的表达式支持 dialects。也就是说，同一个字段可以同时携带 ANSI_SQL、SNOWFLAKE、DATABRICKS、BIGQUERY 等不同方言的表达式。目标平台转换器可以优先选择自己的方言，如果没有，再回退到 ANSI_SQL。
其次，datatype 和 dimension.is_time 被分开处理。一个字段的数据类型是 Date，不代表它一定应该在分析界面里作为时间轴使用；一个 Integer 类型的年份字段，也可能被显式标记为时间维度。这种「类型」和「角色」的分离，对跨工具转换很重要。
再次，ai_context 不是只放在顶层，而是可以放在多个层级。对 AI 来说，字段名 ss_ext_sales_price 本身没有太多业务意义；但如果它带有 description 和 synonyms，Agent 就更容易把用户说的「销售额」「line total」映射到正确字段。
四、Ossie 和 Wiki 的区别
很多团队已经有 Wiki、指标口径文档、数据地图、字段说明和数据资产目录。
那为什么还需要 Ossie？
我的理解是：Wiki 解决的是「人如何理解语义」，Ossie 解决的是「系统如何交换语义」。
Wiki 很适合写背景、写解释、写判断过程。
比如「GMV 为什么不等于收入」「退款订单如何处理」「新老用户口径为什么在 2024 年调整过」，这些内容放在 Wiki 里非常自然。它有上下文，有讨论，有历史说明，也方便业务和数据团队一起维护。
但 Wiki 有几个天然限制。
第一，它通常不是强结构化的。
一篇指标文档里可以写很多有价值的信息，但系统很难稳定判断：哪个是指标名，哪个是计算表达式，哪个是可用维度，哪个是过滤条件，哪个是废弃口径。
第二，它通常不能直接校验。
文档里写了「收入 = 支付金额 - 退款金额」，并不代表 BI 工具、SQL 模板、AI Agent 和指标平台里的实现都真的一致。Wiki 可以告诉人应该怎么做，但很难自动证明系统已经这么做了。
第三，它很难跨工具同步。
Wiki 里的口径变了，Snowflake 里的语义模型不会自动变，dbt 的 metric 不会自动变，BI 平台的字段描述也不会自动变。最后还是要靠人去搬运。
Ossie 更像是 Wiki 旁边的一层机器可读语义模型。
Wiki 负责解释为什么。
Ossie 负责描述是什么。
Wiki 记录业务背景和决策过程。
Ossie 记录数据集、字段、关系、指标、表达式、SQL 方言和 AI 上下文。
Wiki 面向人协作。
Ossie 面向工具交换、自动验证和自动转换。
两者不是替代关系，而是互补关系。
真正理想的状态是：一个指标在 Wiki 里有业务解释，在 Ossie 里有结构化定义，在数据仓库和 BI 工具里有可执行实现，在 AI Agent 里有可检索、可引用、可约束的语义上下文。
这才是业务语义从「写在文档里」走向「进入系统运行时」。
五、放到 OneData 体系里看
如果用 OneData 的视角看，Ossie 的位置会更清楚。
OneData 强调统一数据规范、统一指标口径、统一维度建模、统一数据资产管理。很多企业会围绕数据域、主题域、业务过程、维度、事实表、原子指标、派生指标、复合指标建立一套方法论。
这套方法论本身是对的。
问题在于，OneData 的落地经常停在三个地方。
第一，停在数仓建模层。
团队把 ODS、DWD、DWS、ADS 分层做好，把事实表和维表建好，把公共维度和汇总表沉淀出来。数仓内部有秩序了，但一旦到了 BI、数据应用、AI Agent，不同工具还是会重新定义一遍语义。
第二，停在指标管理平台。
指标平台可以管理指标名称、口径、负责人、生命周期，也可以生成一部分 SQL。但真实分析场景里，指标还要和维度、过滤条件、数据集关系、工具方言、权限上下文结合。指标平台如果不能和下游工具互通，还是容易变成另一个孤岛。
第三，停在文档治理层。
很多企业有很完整的数据标准文档和指标字典，但文档和执行系统之间没有强约束。文档说的是一套，查询跑的是另一套，AI Agent 看到的又是第三套。
Ossie 能补的是「语义交换层」。
它不替代 OneData 的方法论，也不替代数仓分层，更不替代指标治理流程。它更像是在 OneData 和具体工具之间增加一个中间表示，让 OneData 沉淀出来的语义能够被更多系统消费。
可以这样理解：
数据域、主题域，帮助组织业务范围。
事实表、维表，帮助组织数据结构。
指标体系，帮助组织计算口径。
数据资产目录，帮助组织发现和治理。
Wiki，帮助组织解释和协作。
Ossie，则帮助这些语义被机器读取、校验、转换和交换。
举个例子。
在 OneData 里，「支付金额」可能是交易域下的原子指标，「净收入」可能是财务域下的派生指标，「用户」「商品」「门店」「日期」是公共维度。
这些定义写在指标平台或 Wiki 里当然有价值。但如果要让 AI Agent 正确回答「华东地区上个月新用户带来的净收入是多少」，系统还需要知道：
净收入 对应哪个 metric。
新用户 是一个标签、维度值，还是一个可计算条件。
华东地区 应该走用户地区、门店地区，还是订单履约地区。
上个月 应该使用支付时间、下单时间，还是确认收入时间。
这些指标和维度来自哪些 dataset。
跨 dataset 分析时应该使用哪些 relationship。
目标平台是 Snowflake、Databricks 还是别的引擎，表达式方言怎么选。
这些信息如果只靠 Wiki，AI 很难稳定执行；如果只靠数仓表结构，AI 又缺少业务含义；如果只靠某一个 BI 语义层，又很难跨平台共享。
Ossie 的价值就在这里：它把 OneData 里那些原本分散在指标平台、维表设计、字段说明、SQL 片段和业务文档里的语义，组织成一个可交换的模型。
六、转换器是 Ossie 落地的关键
标准本身只是第一步。真正决定 Ossie 能不能被用起来的是转换器。
当前仓库里已经包含多个方向的 converter，包括 Snowflake、dbt、Databricks、GoodData、Omni、WisdomAI、NVIDIA GSF、Honeydew、OrionBelt、Salesforce、Polaris 等相关实现或目录。它们的共同方向很明确：把 Ossie 作为中间格式。
典型流程是这样的：
- 1. 一个语义模型可以先在 dbt、Snowflake 或其他平台中创建。
- 2. Import converter 把平台原生模型转换成 Ossie YAML。
- 3. Ossie 模型通过 JSON Schema 或验证脚本检查结构正确性。
- 4. 模型进入 Git、数据目录、CI/CD 或内部语义服务。
- 5. Export converter 再把 Ossie 模型转换到其他目标平台。
- 6. 如果下游平台产生了变更，再尽可能 round-trip 回 Ossie，并通过 custom_extensions 保留无法映射到核心规范的信息。
这个模式的价值不只是减少转换器数量。
更重要的是，它让企业有机会把语义模型当作一种可治理、可版本化、可审查的资产，而不是散落在各个工具 UI 里的隐性配置。
对数据团队来说，这很像当年把数据管道从手工脚本推进到 dbt / Git / CI 的过程。语义定义一旦变成可读、可 diff、可验证的文本文件，协作方式就会发生变化。
七、为什么 AI 让 Ossie 这类标准更重要
如果只看传统 BI，语义层互通已经是一个老问题。
但 AI 把这个问题放大了。
过去，一个指标口径错了，通常是某个 dashboard 出错。现在，一个 Agent 可能会根据错误语义生成 SQL、解释趋势、写经营分析、触发后续动作。错误不再停留在一张图表里，而是可能沿着自动化链路扩散。
这也是 Ossie 里 ai_context 设计值得关注的原因。
AI 需要的不只是表结构。它还需要知道：
「客户」在这个业务里有哪些同义词。
「收入」应该使用哪个指标，而不是直接 sum 某个看起来像金额的字段。
某些字段是否只用于审计，不应该作为业务时间维度。
跨数据集指标需要走哪些关系。
面对歧义问题时，应该遵循哪些业务说明。
这些信息过去可能藏在数据分析师的经验里，藏在 BI 字段描述里，藏在 Confluence 文档里，或者干脆只存在于 Slack 讨论里。AI Agent 如果拿不到这些上下文，就只能靠猜。
Ossie 的意义在于，它试图把这些语义和上下文结构化，让 AI、BI 和数据平台能够共享同一套业务定义。
这不是为了让 AI 更会「编 SQL」，而是为了让 AI 更少误解业务。
八、它解决了哪些问题
把 Ossie 放在 OneData、Wiki、BI 和 AI Agent 的完整链路里看，它主要解决五类问题。
第一，让指标口径从「文档约定」变成「结构化契约」。
Wiki 和指标平台可以说明一个指标，但 Ossie 可以把指标表达式、引用字段、数据类型、同义词和 AI 上下文放在同一个模型里。它让口径不只是可阅读，而是可解析。
第二，让语义模型可以进入工程流程。
YAML / JSON 形式的语义模型可以放进 Git，可以 code review，可以做 schema 校验，可以在 CI 里检查字段引用和关系引用是否正确。这比只维护一批页面文档更容易形成工程约束。
第三，减少不同工具之间的重复定义。
如果一个指标在 dbt 定义一次，在 Snowflake 定义一次，在 BI 工具定义一次，在 AI 分析系统里再定义一次，漂移几乎不可避免。Ossie 的 hub-and-spoke 思路，是让各工具围绕同一个中间模型导入导出，减少点对点翻译。
第四，为 AI Agent 提供更可靠的语义 grounding。
AI 不应该只看到表结构，也不应该只读几段文档片段。它需要结构化知道：有哪些 dataset、哪些 field、哪些 metric、哪些 relationship、哪些 synonym、哪些 instruction。Ossie 的 ai_context 让这些信息有机会和模型结构一起传递。
第五，保留平台差异，而不是假装差异不存在。
现实里的语义层工具一定有差异。Snowflake、Databricks、dbt、GoodData、Salesforce 各自都有自己的能力和元数据。Ossie 通过 custom_extensions 保留这些信息，目标不是把所有平台抹平，而是在核心语义统一的前提下尽量不丢信息。
这五点放在一起看，Ossie 解决的不是「怎么建数仓」的问题，而是「建好的数仓语义如何被不同工具一致理解」的问题。
它也不是「怎么写指标文档」的问题，而是「文档里的业务定义如何变成系统可执行的语义资产」的问题。
九、它没有替代什么
说到这里，也要避免把 Ossie 神化。
它不替代数仓建模。事实表、维表、数据分层、主题域划分，这些仍然是 OneData 的基础工作。
它不替代指标治理。指标是否合理、口径是否被业务认可、负责人是谁、变更如何审批，这些还是组织治理问题。
它不替代 Wiki。复杂业务背景、历史决策过程、例外情况和口径争议，仍然需要文档承载。
它也不直接替代查询引擎。Ossie 描述语义模型，但具体怎么生成 SQL、怎么执行、怎么做权限控制，还需要和具体平台结合。
所以更合理的落地方式，是把 Ossie 放在语义资产链路中间。
上游连接 OneData 的指标体系、维度体系、数据模型和业务文档。
中间形成机器可读的语义模型。
下游连接 BI、AI Agent、数据目录、语义服务和不同厂商平台。
这才是它的位置。
参考项目：
Apache Ossie GitHub[1]
粤ICP备14082021号
免费POC，
零成本试错
