基于 Data Fabric 构建数据服务

在企业数据建设中，“数据服务”并不是一个新概念。

很多企业早就已经在用各种方式向业务系统、分析人员和外部应用提供数据。业务部门需要客户数据时，数据团队可以导出一份 Excel；管理层需要看经营情况时，BI 团队可以制作一张报表；运营团队需要分析订单时，数据开发人员可以加工一张宽表；业务系统需要调用客户信息时，技术团队也可以开发一个数据 API。

这些方式都在解决同一个问题：如何把数据交付出去。

但随着企业系统越来越多，数据来源越来越复杂，业务对数据实时性、可信度和复用性的要求越来越高，仅仅“把数据交付出去”已经不够了。

过去，一次报表、一次导出、一个接口，可能就能满足一个具体需求。现在，企业更关心的是：同样的数据能力，能不能被多个系统持续调用？同一个指标，能不能保持统一口径？同一类客户数据，能不能在营销、客服、经营分析和 AI 应用中复用？数据在被调用时，权限、脱敏、质量、血缘和审计能不能同步生效？

这也是 Data Fabric 进入数据服务建设的关键原因。

利用 Data Fabric 构建数据服务，并不是简单把数据库表封装成 API，也不是把已有报表换一种方式输出。它真正要做的，是把分散在不同系统、不同平台、不同存储中的数据资产，经过语义封装、虚拟访问、治理绑定、质量校验和服务编排，转化为可以被持续调用、可以被统一治理、可以被解释追溯的数据服务。

图 1  从数据结果到 Data Fabric 数据服务的演进：数据交付从一次性结果，逐步走向可持续调用的数据能力。

一、企业过去交付数据，更多是在交付一次性的“数据结果”

在很多企业中，数据使用最常见的形态并不是数据服务，而是数据结果。

业务人员提出一个需求，数据团队根据需求查询数据、加工数据，然后交付一份结果。这份结果可能是一张 Excel、一张报表、一张宽表、一个查询结果，也可能是一个临时数据集。

例如，运营团队想分析客户复购情况，数据团队可能会导出客户信息、订单记录和消费金额；管理层想看季度经营情况，BI 团队可能会制作销售额、毛利率和渠道贡献报表；风控团队想识别高风险客户，数据人员可能会加工一张包含交易行为、逾期记录和风险标签的宽表。

这些方式并不是没有价值。它们能够快速响应具体需求，也能让业务部门拿到当下需要的数据。问题在于，它们的本质往往还是一次性交付。

所谓一次性交付，是指这次需求来了，就围绕这次需求取数、加工、解释和交付。等到下次另一个团队提出类似需求时，可能又要重新取数、重新拼表、重新解释字段、重新确认口径、重新处理权限和脱敏。

这会带来一系列连锁问题。

首先，数据结果难以复用。同样是客户数据，运营系统要用一次，客服系统要用一次，AI 应用也要用一次，每次都可能重新开发、重新加工。

其次，字段含义依赖人工理解。一个字段叫 customer_id、cust_no、member_id，它究竟代表客户、会员、购买人还是联系人，往往需要依赖文档或数据人员解释。

再次，指标口径容易不一致。同样是“销售额”，不同团队可能使用下单金额、支付金额、开票金额或确认收入金额。结果看起来都叫销售额，但实际上口径并不相同。

更重要的是，治理规则很难随着数据结果一起持续生效。数据一旦被导出成 Excel，权限控制、动态脱敏、质量提示和审计追踪就很容易变弱。结果被复制、转发、二次加工之后，数据来自哪里、经过哪些处理、是否仍然使用最新口径，也会越来越难说清楚。

二、传统数据 API 进一步解决了系统调用问题，但仍然容易形成新的接口烟囱

相比 Excel、报表和宽表，传统数据 API 已经向前走了一步。

数据 API 让系统可以通过接口自动调用数据，不再完全依赖人工导出和手工传递。业务系统可以调用客户信息 API，运营系统可以调用订单 API，外部应用可以调用产品库存 API，BI 系统也可以通过接口获取指标数据。

这确实解决了一个重要问题：系统可以自动拿到数据。

但很多企业在实践中会发现，API 建得越多，问题也越多。

原因在于，传统数据 API 往往仍然是围绕底层系统、数据库表或固定查询开发的。接口文档会说明请求参数、返回字段和调用方式，但字段背后的业务含义、指标口径、数据质量状态、血缘来源和治理规则，未必真正进入接口调用过程。

例如，一个客户信息 API 可以返回客户编号、客户等级、手机号、注册时间和最近购买日期。表面上看，调用方已经拿到了数据。但调用方仍然需要继续理解：客户等级是按什么规则计算的？手机号是否需要脱敏？最近购买日期来自订单系统还是会员系统？数据今天是否已经更新？不同角色调用时是否应该返回同样的数据粒度？

如果这些问题没有被服务本身解决，API 只是把数据从数据库传递到了应用系统，并没有把数据变成真正可复用、可治理、可解释的数据能力。

传统数据 API 还容易形成新的接口烟囱。一个系统需要客户数据，就开发一个客户接口；另一个系统也需要客户数据，又开发一个类似接口；第三个系统需要多几个字段，再开发一个变体接口。时间久了，接口数量越来越多，字段定义不一致，权限规则分散配置，服务治理越来越复杂。

这时，企业虽然看起来已经实现了“数据接口化”，但数据能力并没有真正沉淀下来。

三、基于 Data Fabric 的数据服务，本质上是把数据结果和数据接口升级为数据能力

基于 Data Fabric 的数据服务，不是简单把 SQL 包装成接口，也不是把底层表直接暴露给应用。

它的核心，是把底层数据资产经过语义封装、虚拟访问、治理绑定、质量校验和服务编排之后，形成可以被业务系统、分析工具和 AI 应用持续调用的数据能力。

这里需要解释一个关键概念：什么是可复用数据能力？

可复用数据能力，并不是简单让一份数据被多个系统重复读取，而是指数据已经被组织成稳定的数据服务，并且服务中同时包含业务语义、指标口径、访问路径、权限规则、脱敏策略、质量状态、血缘关系和审计记录。

也就是说，复用的不只是数据本身，还包括围绕数据形成的一整套业务理解、使用规则和治理机制。

图 2  可复用数据能力的组成：复用的不只是数据本身，还包括语义、路径、治理、质量、血缘和反馈机制。

例如，“客户画像服务”就不是简单返回一张客户表。它需要把客户基础信息、订单行为、渠道来源、风险标签、服务记录等数据，按照统一的客户对象组织起来；同时还要绑定访问权限、动态脱敏、质量校验、血缘追踪和调用审计。

这样，营销系统可以调用它做客户分群，客服系统可以调用它了解客户历史，经营分析系统可以调用它分析客户价值，AI Agent 也可以调用它生成客户洞察。

不同系统调用的是同一类客户数据能力，而不是各自重新取数、重新拼表、重新解释字段、重新配置治理规则。

这就是 Data Fabric 数据服务区别于传统数据 API 的关键。

它不只是让数据可以被调用，更重要的是让数据在被调用时具备清晰语义、统一口径、质量保障、权限控制、血缘追踪和审计反馈。

四、传统数据结果、传统数据 API 与 Data Fabric 数据服务的差异，本质上是数据交付层级的差异

要理解 Data Fabric 数据服务，不能只把它和传统 API 做技术层面的比较。更准确地说，传统数据结果、传统数据 API 和 Data Fabric 数据服务，代表了三种不同的数据交付层级。

传统数据结果强调“交付结果”。传统数据 API 强调“交付接口”。Data Fabric 数据服务强调“交付能力”。

传统数据结果通常面向某个具体需求。它的交付形态是报表、Excel、宽表或查询结果。它可以解决眼前问题，但很难持续复用。

传统数据 API 通常面向系统集成。它的交付形态是接口地址、请求参数和返回字段。它可以让系统自动调用数据，但仍然可能依赖接口文档解释字段，治理和质量也经常在服务外部处理。

Data Fabric 数据服务则面向业务对象、指标口径和场景能力。它的交付形态可以是数据 API、指标服务、对象服务、特征服务、知识服务等。它不仅返回数据，还把语义、治理、质量、血缘和审计一起纳入服务过程。

图 3  传统数据结果、传统数据 API 与 Data Fabric 数据服务的差异：三者分别对应结果交付、接口交付和能力交付。

为了进一步说明这种差异，可以从设计起点、复用方式、治理方式和 AI 支撑等维度理解。

从设计起点看，传统数据结果往往从具体取数需求出发，传统数据 API 往往从底层系统或固定查询出发，而 Data Fabric 数据服务应该从业务对象、指标口径和业务场景出发。

从复用方式看，传统数据结果通常靠复制结果或重复加工复用，传统 API 通常靠开发相似接口复用，而 Data Fabric 数据服务是把统一服务沉淀下来，被多个应用、多个系统和多个 AI 工具持续调用。

从治理方式看，传统数据结果常常在使用后补充检查，传统 API 多在接口层做鉴权，而 Data Fabric 数据服务则把权限、脱敏、质量、血缘和审计随服务一起生效。

从 AI 支撑看，传统数据结果会让 AI 难以判断字段含义和数据质量，传统 API 会让 AI 依赖接口文档理解调用方式，而 Data Fabric 数据服务可以让 AI 面向语义化、可治理、可追溯的数据能力进行调用。

五、利用 Data Fabric 构建数据服务，需要完成从数据资产到数据能力的技术转化

利用 Data Fabric 构建数据服务，关键不是多开发几个接口，而是完成一条从数据资产到数据能力的技术转化链路。

在这条链路中，Data Fabric 的多层能力共同发挥作用：虚拟数据层负责跨源访问，语义层负责业务理解，治理与策略层负责安全和可信，数据服务层负责面向应用、BI、AI 和模型服务输出可调用能力。

图 4  基于 Data Fabric 的数据服务总体架构：数据服务层不是孤立接口层，而是由虚拟访问、语义、治理和质量共同支撑。

具体来看，这条技术路径可以概括为：数据资产识别、语义封装、虚拟访问、治理绑定、质量校验、服务编排、服务发布、调用监控和反馈优化。

图 5  利用 Data Fabric 构建数据服务的技术路径：从识别高价值数据资产开始，到服务发布、监控和反馈优化形成闭环。

第一步是数据资产识别。

不是所有数据表都值得服务化，也不是所有字段都应该直接变成接口。Data Fabric 需要识别哪些数据具有较高业务价值，哪些数据被高频访问，哪些指标被多个系统反复使用，哪些字段经常组合出现，哪些数据质量稳定，哪些数据有明确负责人和治理状态。这一步解决的是：哪些数据值得被沉淀为服务。

第二步是语义封装。

数据服务不能只暴露底层字段，而要把字段、表和接口转化为业务对象、指标口径和场景语义。例如，把多个系统中的 cust_id、member_id、buyer_id 统一到客户对象下，把订单金额、支付金额、开票金额、确认收入等不同字段对应到不同指标口径下。这一步解决的是：服务是否能被业务正确理解。

第三步是虚拟访问。

Data Fabric 的数据服务不一定绑定某一张固定表。它可以通过虚拟数据层访问数据库、数据仓库、数据湖、文件系统、API、SaaS 和消息流等多源数据。上层服务看到的是统一逻辑视图，底层数据仍然可以分布在不同系统中。这一步解决的是：服务如何跨源访问数据。

第四步是治理绑定。

数据服务不是只返回数据，还要绑定治理规则。服务需要明确谁可以调用，能看到哪些字段，是否需要脱敏，是否允许导出，是否需要审批，是否记录审计，适用于哪些业务场景。这一步解决的是：服务调用过程是否受控。

第五步是质量校验。

数据服务不能只关注是否返回结果，还要关注结果是否可信。Data Fabric 可以在服务调用前后判断数据是否更新、质量评分是否达标、是否存在异常波动、是否需要提示风险，甚至在质量严重异常时暂停服务输出。这一步解决的是：服务返回的数据是否可靠。

第六步是服务编排。

很多数据服务不是单一查询，而是多个数据能力的组合。例如，客户画像服务可能组合客户基础信息、订单行为、渠道来源、风险标签和服务记录；经营分析服务可能组合销售额、订单量、毛利率、库存和渠道数据；风险识别服务可能组合交易行为、异常规则、黑名单和模型评分。这一步解决的是：数据能力如何面向业务场景组合。

第七步是服务发布。

服务完成封装后，需要进入统一服务目录。服务目录不应该只展示接口地址，还应该展示服务说明、适用场景、输入参数、返回结果、指标口径、质量状态、权限要求、负责人和使用说明。这一步解决的是：服务如何被发现、申请和调用。

第八步是调用监控。

服务发布之后，需要持续监控调用频率、调用性能、失败率、质量异常、用户行为和访问风险。只有持续监控，才能知道哪些服务真正被使用，哪些服务存在性能问题，哪些服务需要优化。这一步解决的是：服务运行是否稳定。

第九步是反馈优化。

Data Fabric 的数据服务不是一次性发布后就结束。主动元数据会持续采集调用日志、用户反馈、质量变化、异常行为和业务使用情况，反向优化服务定义、治理策略、缓存策略、质量规则和服务版本。这一步解决的是：服务能否持续演进。

六、主动元数据让数据服务不是一次性发布，而是持续演进

传统数据 API 发布之后，更多依赖人工维护。

接口是否还被使用，调用频率是否下降，返回字段是否仍然适用，数据质量是否稳定，哪些调用方频繁报错，哪些接口与其他接口高度重复，这些问题往往需要人工巡检，或者在出现问题后才被发现。

Data Fabric 的不同之处在于，它可以通过主动元数据持续感知数据服务的运行状态。

主动元数据可以记录哪些数据被高频访问，哪些指标被多个系统反复调用，哪些字段经常组合出现，哪些服务响应较慢，哪些服务质量不稳定，哪些调用行为异常，哪些服务被多个 AI 应用使用，哪些服务应该缓存、升级、合并或下线。

这些信息会反过来推动数据服务持续优化。

例如，如果某个指标被多个报表和系统反复调用，就可以沉淀为标准指标服务；如果某些字段总是一起被查询，就可以封装为业务对象服务；如果某个服务调用频率很高但响应较慢，就可以优化缓存和查询路由；如果某个数据源质量经常异常，就可以在服务调用时增加质量提示或限制输出。

七、AI 应用需要的不是直接访问原始数据，而是调用可信数据服务

AI 应用的发展，让数据服务的重要性进一步提高。

传统 BI 或报表通常由人来选择数据、理解字段、编写查询和判断结果。而 AI Agent 可能会自动理解问题、选择数据、调用服务、生成分析结论。

这意味着，AI 对数据服务的要求更高。

如果 AI 直接访问原始数据库，它会面临很多问题：不知道应该查哪张表，不知道字段是什么意思，不知道指标口径是否正确，不知道用户是否有权访问，不知道字段是否需要脱敏，不知道数据质量是否可靠，也不知道结果是否可以追溯。

这些问题如果交给 AI 自己判断，风险很高。

基于 Data Fabric 的数据服务，可以把这些问题前置解决。AI 不需要直接面对混乱的底层表结构，而是调用经过语义封装、治理约束、质量校验和审计追踪的数据服务。

例如，AI 可以调用客户画像服务、经营指标服务、订单分析服务、知识检索服务、风险识别服务和模型特征服务。每个服务都已经定义了业务语义、输入输出、权限范围、质量规则和审计要求。

图 6  AI 应用通过 Data Fabric 数据服务调用可信数据能力：服务调用过程同步完成语义解析、权限判断、质量校验、动态脱敏和审计记录。

这样，AI 调用数据时，就不是在自由访问原始数据，而是在治理约束下调用可信数据服务。

这对于企业 AI 非常重要。因为企业 AI 的关键不只是能回答问题，更要保证回答所依据的数据来源清楚、口径一致、权限合规、质量可信、过程可审计。

八、利用 Data Fabric 构建数据服务，最终是把企业数据建设从“交付结果”推向“沉淀能力”

利用 Data Fabric 构建数据服务，本质上是企业数据交付方式的一次升级。

传统数据结果解决的是“这一次把数据拿到”。传统数据 API 解决的是“系统可以通过接口调用数据”。基于 Data Fabric 的数据服务解决的是“数据能力可以被持续、可信、受控、可解释地复用”。

这也是 Data Fabric 在企业数据架构中的重要价值。

主动元数据让 Data Fabric 知道哪些数据值得服务化，虚拟数据层让服务可以跨源访问数据，语义层让服务具备业务含义，治理嵌入让服务调用过程可控可信。

最终，Data Fabric 把数据从表、字段、报表和接口，转化为面向业务、应用和 AI 的可复用数据服务。