OpenMetadata 1.13重磅发布！开启AI数据治理语义上下文时代

OpenMetadata 1.13 正式发布。

我看完官方发布说明后，觉得这次版本值得单独写一篇。做数据治理、元数据管理、数据目录、知识图谱、企业 AI 应用的人，都建议认真看一下。

因为它不是简单加几个连接器，也不是普通的数据目录功能更新。

如果用一句话概括：

OpenMetadata 1.13 释放出的信号是，AI 时代的数据治理正在从“管理元数据”，继续走向“管理语义上下文”。

过去很多数据治理平台解决的是：

• 有哪些表？
• 有哪些字段？
• 谁负责？
• 血缘从哪里到哪里？
• 质量规则有没有跑？

这些当然重要。但到了企业 AI 阶段，只知道表、字段、血缘、负责人还不够。

AI 真正需要理解的是：

• 这个字段在业务上是什么意思？
• 这个指标和那个指标是什么关系？
• 这个术语在财务、产品、运营三个部门是不是同一个意思？
• 一个业务概念到底由哪些表、字段、报表、管道和规则共同实现？

这就是 OpenMetadata 1.13 这次想补的东西。官方发布说明里有一句话很关键：他们过去在标准化元数据，现在开始标准化意义。

这句话值得单独拿出来看。因为它背后对应的不是一个产品功能，而是整个数据治理方向的变化。

一、先说重点：OpenMetadata 1.13 到底更新了什么

我把这次版本拆成六类来看。

1. Knowledge Graph。

OpenMetadata 1.13 加入了知识图谱能力，把技术元数据和业务语义元数据放到一个统一图里。这里的技术元数据包括 schema、血缘、Owner、数据资产等；业务语义元数据包括业务术语、分类、标签、领域、治理关系等。

这说明 OpenMetadata 不再只想做“数据目录”，而是在往“企业语义上下文层”走。

1. Ontology Explorer。

可以理解为“本体探索”能力。它让数据团队可以可视化地查看业务术语之间的关系，以及这些术语最终落在哪些表、字段、报表、管道和数据资产上。

过去很多企业的数据术语表，只是一张平面清单。现在的问题是，AI 不能只看清单，它需要理解概念之间的结构。

1. Glossary Terms & Relations。

这次 OpenMetadata 允许定义业务术语之间更明确的关系。比如 ARR 是从 Revenue 计算出来的，Customer Tier 包含 Behavioral Segment，Finance 里的 Churn 和 Product 里的 Attrition 可能是等价或近似概念。

这不是文字游戏。对 AI Agent 来说，这类关系决定它是“按治理上下文推理”，还是“自己乱猜”。

1. Columns as Assets。

字段现在被提升为一等资产。过去数据治理里，很多系统以表为核心，但真实治理往往发生在字段层。

客户手机号、身份证号、订单金额、收入确认口径、风险等级、客户分层标签，这些关键对象很多时候不是表，而是字段。OpenMetadata 1.13 把字段作为可搜索、可发现、可关联治理语义的资产，这一点非常关键。

1. 新增连接器。

包括 SSRS、Google Pub/Sub、Airflow REST API、Matillion Data Cloud 等，同时 Google Drive、Microsoft Fabric Database、Microsoft Fabric Pipeline 等能力进入开源版。

这说明元数据采集的边界继续扩大。企业的数据资产已经不只在数据库和数仓里，也在报表、消息队列、调度系统、云数据平台、文档系统和 AI 工具链里。

1. MCP 支持扩展。

原文提到已有 MCP 支持被扩展为完整的服务类别。这点放在 AI 时代看非常重要，因为未来很多 AI Agent 不只是查数据，而是要通过工具接口访问元数据、理解上下文、执行治理动作。

所以 OpenMetadata 1.13 的重点不是“又多了几个功能”。它真正指向的是：

元数据平台要成为 AI Agent 可以理解、查询和推理的语义上下文层。

二、Knowledge Graph：数据目录正在变成语义图谱

先看 Knowledge Graph。

很多人听到知识图谱，会以为这是一个很老的概念。数据治理里也讲知识图谱很多年了，但这次 OpenMetadata 的 Knowledge Graph，重点不是做一个孤立的图谱项目，而是把企业已有的元数据、血缘、Owner、分类、术语、领域、数据资产关系统一放到一个图里。

这件事很重要。

因为过去很多企业的数据治理资产是分散的：

• 数据目录里有表。
• 血缘系统里有链路。
• 质量平台里有规则。
• 指标平台里有口径。
• 权限系统里有授权。
• 业务术语表里有概念。

这些东西单独看都有价值，但 AI 很难真正理解。AI 需要的不是一堆页面，而是一张可查询、可推理、可追溯的上下文网络。

举个例子。如果一个管理者问：“本月收入为什么下降？”一个真正可用的 AI 数据分析助手，不能只会写 SQL。

它至少要知道：

• 收入这个指标的业务定义是什么；
• 收入和订单、合同、发票、回款之间是什么关系；
• 哪个字段代表确认收入；
• 哪个报表是管理层认可的口径；
• 哪些数据源参与了这个指标；
• 数据质量有没有异常；
• 口径最近有没有变更；
• 谁是业务 Owner；
• 哪些分析结果不能越权展示。

这些信息都不是模型自己凭空知道的，它们来自企业的数据治理上下文。

Knowledge Graph 的意义就在这里：把技术元数据和业务语义元数据连起来，让人能看，让 AI 也能用。

这和过去“建一个数据目录给人搜索”不是一回事。数据目录解决的是找得到，知识图谱解决的是看得懂、连得上、解释得清。

三、Ontology Explorer：术语表不能再停留在平面清单

再看 Ontology Explorer。

我觉得这是这次版本里最值得数据治理团队关注的功能之一。很多企业都有业务术语表，但很多术语表最后会变成这样：

• 一列术语。
• 一列定义。
• 一列责任部门。
• 一列更新时间。

看起来很规范，但实际用起来还是很难。

为什么？因为业务概念不是孤立存在的。

• “客户”可能和“会员”“账户”“联系人”“法人主体”有关。
• “收入”可能和“订单金额”“确认收入”“开票金额”“回款金额”有关。
• “流失”可能在运营部门表示不活跃，在财务部门表示收入流失，在产品部门表示取消订阅。

如果术语表只是平面清单，它无法表达这些关系。而 AI 最怕的，恰恰就是这种语义模糊。

它看到“客户”两个字，可能不知道你说的是自然人客户、企业客户、账户主体，还是合同签约方。它看到“收入”，可能不知道你要的是订单收入、会计收入、经营收入，还是分析报表里的业务收入。

Ontology Explorer 的价值，就是把这些关系变成可视化、可治理、可复用的结构。原文里提到，它可以从不同视角看术语之间的关系，也可以追踪某个业务术语最终由哪些数据资产实现。

这对企业很实用。

比如 CDO 问：“哪个 Revenue 定义才是权威口径？”如果只是翻术语表，很难看清楚。但如果能看到 Revenue 和 ARR、MRR、订单、合同、开票、回款、报表、数据集之间的关系，事情就不一样了。

这时数据治理不再只是“填定义”。它开始变成业务语义建模。

四、Glossary Terms & Relations：AI 不应该自己猜业务关系

这次 OpenMetadata 1.13 还强化了业务术语之间的关系定义。

这个点看起来很细，但我认为它很关键。因为很多企业做 AI 问答和智能分析时，最容易忽略一个问题：

AI 回答错，不一定是模型不够强。也可能是企业没有把业务关系教给它。

比如：

• ARR 和 Revenue 是什么关系？
• GMV 和支付金额是什么关系？
• 订单金额和收入确认金额是什么关系？
• 客户等级和客户分群是什么关系？
• 流失、沉默、不活跃、退订是不是同一个概念？

如果这些关系没有被治理系统明确表达，AI 只能根据通用知识猜。它可能猜得像那么回事，但在企业场景里，这种“像”是最危险的。

因为业务口径一旦错，后面的 SQL、图表、分析、汇报都会错。

OpenMetadata 1.13 支持更细的关系类型，比如层级关系、关联关系、等价关系、计算关系、反向关系、跨术语表关系等。这其实是在给 AI 准备一套“业务语义规则”。

不是让 AI 自己发明概念关系，而是让它基于企业治理过的上下文去推理。

这也是我一直强调的：

• 企业 AI 不能只靠大模型。
• 企业 AI 需要被治理过的数据、指标、术语、权限、流程和责任体系。
• 模型负责生成和推理。
• 数据治理负责告诉它什么是可信上下文。

五、Columns as Assets：字段终于被放到台前

我再单独说一下 Columns as Assets。

很多数据治理项目最大的问题，是治理粒度太粗。系统里能看到表，目录里能搜到表，血缘里能追到表，Owner 也经常挂在表上。

但真实问题往往出现在字段层。

比如：

• 同样叫 customer_id，不同系统是不是同一个客户？
• phone_number 是不是敏感字段？
• revenue_amount 到底是哪种收入？
• status 字段有多少枚举值？
• create_time 是业务发生时间，还是数据入库时间？
• risk_level 是人工标注，规则计算，还是模型预测？

这些问题都发生在列级。如果字段不能被单独发现、搜索、打标签、挂术语、挂分类、挂质量规则、关联血缘，那很多治理动作最后都会停留在表级。

而表级治理对 AI 来说远远不够：

• AI 写 SQL 时，真正选的是字段。
• AI 做指标解释时，真正引用的是字段。
• AI 做敏感数据识别时，真正判断的是字段。
• AI 做数据质量规则推荐时，真正分析的也是字段。

所以 OpenMetadata 1.13 把 Columns 作为资产，不只是搜索体验优化，而是数据治理粒度升级。

这对 AI 数据底座非常重要。

六、从 OpenMetadata 1.13 看 AI 时代数据治理的变化

如果把这次版本放到更大的趋势里看，我觉得至少有四个变化。

1. 数据治理从“资产目录”走向“语义上下文”。

过去企业关心的是数据资产在哪里。现在企业更关心的是数据资产是什么意思、和谁有关、能不能被 AI 正确理解。

1. 元数据平台从“给人用”走向“人和 AI 都能用”。

以前数据目录主要服务数据分析师、数据工程师和数据治理人员。现在还要服务 AI Agent。人可以看页面，AI 需要可查询的上下文。

1. 术语治理从“定义管理”走向“关系管理”。

只定义术语不够。企业要把术语之间、术语和字段之间、术语和指标之间、术语和流程之间的关系治理起来。

1. 治理粒度从“表级”继续下沉到“字段级”。

AI 应用越深入，越不能只停留在表。字段级语义、字段级权限、字段级质量、字段级血缘，都会变得越来越重要。

这四个变化合起来，就是我对 OpenMetadata 1.13 的核心判断：

它不是在做一个更漂亮的数据目录。它是在把数据治理平台推向 AI 时代的语义基础设施。

七、和 Data for AI、AI for Data 有什么关系

这篇文章我特别想把 OpenMetadata 1.13 放到两条线里看。

第一条线是 Data for AI，也就是数据如何支撑 AI。

企业要做 RAG、智能问答、AI 数据分析、Agent 工作流，需要的不只是文档和向量库。它需要：

• 标准化的业务术语；
• 可信的指标口径；
• 字段级语义；
• 数据质量状态；
• 血缘和来源；
• 权限和分类分级；
• Owner 和责任边界；
• 业务概念之间的关系。

这些就是 AI 的数据底座。如果没有这些上下文，AI 也许可以回答得很流畅，但不一定可信。

第二条线是 AI for Data，也就是 AI 如何反过来改造数据治理。

当企业有了知识图谱、本体关系、字段资产、术语关系以后，AI 就可以参与更多治理工作。比如：

• 自动推荐字段说明；
• 识别相似字段；
• 发现术语冲突；
• 辅助数据标准映射；
• 解释指标口径差异；
• 生成质量规则建议；
• 辅助血缘影响分析；
• 回答数据资产相关问题；
• 帮助 Data Steward 做治理巡检。

所以 OpenMetadata 1.13 这类更新，不只是 Data for AI。它也在为 AI for Data 铺路。

AI 要想改造数据治理，前提是它能理解企业数据治理对象之间的关系。知识图谱、本体、术语关系、字段资产，都是这个前提的一部分。

八、企业应该怎么看这次更新

如果你是企业管理者，不需要马上纠结某个功能怎么配置。你更应该看方向：

企业的数据治理，是否已经能支撑 AI 理解业务？

如果你的数据治理还停留在“有多少表、谁负责、有没有血缘”，那只是第一阶段。

接下来要补的是：

• 业务术语和指标口径能不能统一；
• 字段级语义能不能治理；
• 术语之间的关系能不能表达；
• 技术元数据和业务元数据能不能连起来；
• 数据质量、血缘、权限、Owner 能不能形成上下文；
• AI 能不能基于这些上下文回答问题，而不是自己猜。

如果你是数据团队，可以重点检查四件事：

1. 你们的数据目录是不是只管理表，还是已经能管理字段？
2. 你们的业务术语表是不是只是清单，还是能表达关系？
3. 你们的指标口径是不是只写在文档里，还是和字段、报表、血缘、Owner 连接起来？
4. 你们准备给 AI 使用的上下文，是不是经过治理、可追溯、可解释、可更新？

如果这四件事没有做，企业 AI 很容易进入一个尴尬状态：

• 看起来能问答，实际上不可信。
• 看起来能分析，实际上口径不稳。
• 看起来能自动化，实际上风险不可控。

九、不要把语义层理解得太玄

最后我想提醒一点。

知识图谱、本体论、语义上下文，这些词听起来容易变玄。但企业落地时，不要一上来就做成很大的理论项目。

你可以从很具体的问题开始：

• 客户到底怎么定义？
• 收入到底用哪个口径？
• 哪些字段是敏感字段？
• 哪些指标可以给 AI 引用？
• 哪个报表是权威报表？
• 某个业务术语最终落在哪些表和字段上？
• 某个字段变更会影响哪些指标和报告？

这些问题都很朴素。但把它们系统治理起来，就是语义层。

AI 时代的数据治理，不是把概念讲得更复杂。恰恰相反，是要把企业内部那些长期说不清、连不上、没人负责的业务语义，变成可以管理、可以查询、可以追溯、可以被 AI 使用的上下文。

这就是 OpenMetadata 1.13 最值得关注的地方。

十、我的判断：数据治理会重新变热，但热的不是老一套

过去几年，很多人觉得数据治理是老话题。元数据、数据质量、数据标准、数据资产，好像都讲过很多遍了。

但 AI 起来以后，数据治理会重新变热。不过这一次，不会只是重复过去那套。

新的重点会变成：

• AI 能不能理解企业业务语义？
• AI 能不能识别可信数据？
• AI 能不能知道字段和指标的真实含义？
• AI 能不能在权限边界内回答问题？
• AI 能不能基于血缘和质量状态判断风险？
• AI 能不能参与治理流程，而不是只做聊天入口？

OpenMetadata 1.13 给我的感觉，就是这些问题正在从概念走向产品能力。

从 Dify 到 OpenMetadata，一个偏 AI 应用编排，一个偏元数据和数据治理。但它们都在往同一个方向走：

企业 AI 不是只拼模型，而是拼协作、权限、流程、数据、语义、治理和工程化。

这也是我接下来会持续写 Dify、OpenMetadata、DataHub、Atlas、Ollama、MCP、RAG 和企业 AI Agent 工程化的原因。我不想只追工具更新。

真正值得看的，是每一次版本更新背后，企业 AI 正在补哪一块能力。

这次 OpenMetadata 1.13 补的，就是 AI 时代数据治理最关键的一层：