Apache Ossie 如何尝试将分析师和开发者结合在一起

一个常见的故事：市场部在 Excel 中用一种公式计算客户获取成本，BI 工具给出不同的数字，而在 dbt 项目中，分析师又用了第三套逻辑。当业务部门询问为什么数据“对不上”时，一个漫长的排查过程就开始了，要找出公式出错的确切位置。

这个问题被称为语义碎片化。数据栈中的每个工具——无论是 Tableau、Superset 还是 AI 代理——都生活在自己的气泡中，以自己的方式解释元数据。Apache 软件基金会的人决定是时候终结这个问题了，于是推出了 Ossie 项目（前身为 Open Semantic Interchange）。

为什么还需要另一个标准

简而言之：这样你就可以一次性定义“收入”或“活跃用户”的含义，然后在任何地方使用这个定义。目前，如果你从一个 BI 工具切换到另一个，就必须从头重写所有业务逻辑。Ossie 提供了一种厂商中立的格式，应该成为分析领域的某种“世界语”。

该项目目前处于 Apache 孵化器阶段。这意味着它仍在成型中，但已经有了坚实的社区支持。这个想法是创建一个单一的真实来源，让 SQL 引擎和花哨的 LLM 机器人都能理解。

仓库里有什么

没有需要编译数小时的复杂二进制软件。从本质上讲，这是一组规范和处理这些规范的辅助工具。

规范核心

文件夹 core-spec 包含语义层应该是什么样子的描述。这些是常规的 JSON 和 YAML 文件。机器可读的 schema 允许你自动验证你的指标定义没有搞砸。

转换器

这可能是对实践者最有用的部分。文件夹 converters 包含从 Ossie 格式转换到其他流行系统的工具。目前有针对 dbt、GoodData、Polaris 甚至 Salesforce 的实现。这让你不仅能把规范“束之高阁”，还能实际将其推入你的工作工具中。

示例与验证

对于不想阅读枯燥文档的人来说，有文件夹 examples。它包含一个完整的 TPC-DS 模型——这是分析系统的标准基准。你可以直接看复杂的关联和聚合是如何用真实数据描述的。

实际工作原理

想象一下在 YAML 文件中描述你的数据模型。你指定表、它们之间的关系，最重要的是计算出的指标。

之后，你把这个文件通过转换器运行。输出是针对你的 BI 工具的配置。如果业务部门决定明天切换工具，你不需要记住旧报表中用了哪些过滤器。你只需要运行不同的转换器。

这对于 AI 代理尤其重要。对于神经网络来说，要充分回答关于数据库的问题，它需要上下文。Ossie 以结构化格式提供这种上下文，消除了关于“如何计算平均订单价值”的幻觉。

现在应该采用吗

该项目处于孵化阶段，这也很明显。目前还没有数千个 GitHub star（撰写本文时约 700 个），文档有时会让你不得不深入源代码。不过，Apache 在背后支持该项目，而且贡献者名单中出现了主要分析公司的身影。

谁绝对应该仔细看看 Ossie：

1. 受够了 dbt 指标与经理在 BI 工具中看到的不一致的团队。
2. 想要添加模型导入/导出支持的分析平台开发者。
3. 使用 LLM 构建复杂系统、想要给神经网络提供清晰数据结构的人。

如果你在一家只有几个数据库和几张图表的小型创业公司工作，Ossie 可能看起来过于复杂。但一旦你有两个以上的工具，“同名不同义”的问题就会全面爆发。

你可以在官方仓库中试用这个项目。还有一个 Slack 社区的链接，那里的开发者对规范相关问题的响应相当迅速。越多供应商采用这个标准，我们在迁移和分析设置上就会越少头疼。