数据中台把数据接进来、加工好，只完成了前半段。业务系统要用数时，如果仍然各自连库、各写一套 SQL，权限、口径和变更影响就会重新散落。数据中台数据服务建设，可以按服务清单、契约设计、API发布、权限控制、复用运营五个环节推进，让加工好的数据以标准接口提供给业务系统，并且做到可发布、可授权、可追踪、可复用。
这篇文章按建设顺序拆开三件事，API 怎么发布，权限怎么控制，服务怎么复用。最后给出一套上线验收和日常运营的检查清单，方便对照现有平台查缺补漏。
图1：数据服务建设流程
一、数据服务在数据中台里承担什么角色
1. 数据从可查走向可调用
数据服务层位于数据资产和业务应用之间。它把表、指标、标签或 SQL 查询封装成 RESTful API，调用方按约定传参，拿到结构化结果。华为云 DataArts Studio 文档把这类能力概括为统一的数据服务总线，用来统一管理对内对外的 API，减少上层应用重复对接，并把数据逻辑与存储计算下沉到数据平台。
2026 年 7 月 1 日实施的 GB/T 36073-2025 将数据应用域调整为数据应用流通，数据开放与服务化被放进更完整的能力框架。中国日报网在标准报道中提到，新版标准强调数据供给要精准支撑业务创新和人工智能应用。这对数据服务建设的直接含义是，服务不只供人查数，也要能被业务系统和 Agent 稳定调用。
这层能力适合小批量、需要快速响应的交互式查询，比如订单详情、用户画像、库存状态、指标查询。大批量离线数据交换，更适合走数据共享交换或批量文件通道。把两类场景分开，后面的服务设计和网关选型会清晰很多。
2. 和直接连库、BI、数据共享的边界
| 使用方式 | 适合场景 | 主要风险 |
|---|---|---|
| 直接连库 | 临时分析、内部小范围 | 权限粒度粗，SQL 质量不可控，表结构变更影响多个系统 |
| BI 报表 | 分析展示、固定看板 | 面向人看，难以嵌入业务系统和流程 |
| 数据服务 API | 系统集成、按次查询、权限随调用方变化 | 需要治理服务目录、版本、限流和审计 |
| 数据共享交换 | 批量、跨组织、离线交付 | 实时性弱，不适合高频交互 |
一个简单的判断方法是，看数据是否需要嵌进业务系统、按次调用，并且对不同调用方返回不同范围。如果答案是肯定的，数据服务会比开放数据库或给一张表更合适。
二、首批数据服务如何选择
1. 从高频取数需求倒推首批服务
比较稳妥的顺序，是先盘点最近三到六个月反复出现的取数需求、接口需求和重复报表，找出高频、口径相对稳定、变更不频繁的场景。
首批服务可以优先选客户或用户信息、订单详情、库存状态、组织与权限、核心指标查询。这些服务被多个系统调用的概率高，契约也相对稳定。营销玩法、临时活动分析这类变化快的需求，可以先保留在分析环境，等模式稳定后再服务化。
2. 一项服务要定义哪些契约
接口能复用，前提是契约写得足够清楚。至少要把下面这些内容定下来。
| 契约项 | 要写清楚的内容 | 示例 |
|---|---|---|
| 服务名称与业务含义 | 一句话说明返回什么业务对象 | 按用户 ID 查询基础画像 |
| 数据来源与粒度 | 来自哪张表或哪个指标，按什么粒度返回 | 用户日粒度画像表 |
| 请求参数 | 必填项、类型、默认值、边界 | 用户 ID 必填，日期可选 |
| 返回字段 | 字段名、类型、含义、是否脱敏 | 昵称、等级、最近登录时间 |
| 更新频率与延迟 | 实时、准实时或 T+1 | T+1，每日 08:00 前更新 |
| 服务级别 | 可用性、响应时间、限流阈值 | 99.9%，P95 小于 500ms |
| 责任人与变更方式 | 谁维护、怎么通知、怎么回滚 | 数据产品经理为 Owner |
表中的99.9%可用性、P95小于500ms等数值只用于说明契约字段，应按真实场景测试和约定，不能视为统一服务标准。
参数设计直接影响复用。按业务主键、时间范围、分页和必要筛选条件设计，避免把某个页面的展示逻辑写死在接口里。返回字段遵循最小必要原则，敏感字段默认不返回，需要时再单独授权。
3. 服务目录怎么分类和分级
服务目录承担三个动作，找得到、看得懂、申请得到。分类可以按业务域或主题域组织，比如用户、交易、商品、营销、财务，下面再按对象或场景分二级目录。每个服务补充标签，包括开放级别、更新频率、负责人和适用系统。
开放级别建议与数据分级挂钩。公开或一般数据、内部数据、敏感数据、核心数据，对应不同的授权方式、脱敏要求和审计强度。服务目录不做文件柜，目录里每个条目都要能直接看到契约、示例、负责人和申请入口。
三、数据服务API如何发布
1. 创建：生成API与注册API
数据服务平台通常提供两种创建方式。生成 API 基于数据库表、数据集或 SQL 查询配置，适合中台内已经加工好的结果表。注册 API 把存量系统里已有的接口纳入统一管理，适合历史接口多、短期无法重写的企业。华为云和阿里云的数据服务文档都提供了生成与注册两类能力。
创建时要配置请求方式、请求参数、返回字段、超时和缓存策略。接口文档由平台自动生成时，示例值要用脱敏后的真实结构，避免文档和实际返回不一致。
2. 测试：发布前验证四件事
测试环节决定接口能不能放心交付。至少验证四类问题。
- 参数是否生效，包括必填校验、默认值、时间范围和分页边界。
- 返回字段、类型、排序和分页结构是否符合契约。
- 数据权限是否按调用方生效，同一个接口换一个应用身份调用，返回的行和字段是否不同。
- 异常路径是否可控，包括无数据、超时、限流、鉴权失败和下游数据库异常。
测试数据和生产数据要隔离。涉及个人信息或敏感字段的测试，使用脱敏数据或构造数据。
3. 审批与发布：谁有权上线
API 发布不建议由开发者一个人完成。比较常见的分工是，服务 Owner 对契约和业务含义负责，数据 Owner 对数据来源和口径负责，安全或合规角色检查敏感字段、授权范围和审计要求。
发布前的检查项包括契约完整、测试通过、权限配置、脱敏规则、限流策略、监控告警和调用文档。检查通过后发布到 API 网关，调用方从统一入口访问。发布完成后，把服务登记到服务目录，并通知已授权的调用方。
4. 版本管理与变更
接口一旦被调用，就会形成依赖。变更管理要区分兼容和不兼容两种情况。
新增可选字段、放宽参数范围可能是兼容变更，但仍需检查客户端校验和反序列化方式。增加枚举值也可能影响使用封闭枚举的调用方，不能直接判为兼容；应通过契约测试确认是否需要新版本。不兼容变更通过新版本发布，让新旧版本共存一段时间。不兼容变更包括删除字段、修改字段含义、改变鉴权方式、调整返回结构。
版本号可以放在路径里，比如 /v1、/v2，也可以在请求头或参数中携带。成熟的数据服务平台通常提供版本管理，支持按版本调试、发布和对比。无论用哪种方式，都要提前通知调用方，给出迁移窗口和回滚方案。
5. 下线：让不用的服务退出
接口只增不减，时间一长就会出现大量无人调用的服务。下线应该成为常规动作。
先看监控数据，把长期零调用或调用量持续下降的接口标记出来。确认没有业务依赖后，通知已授权的调用方，设置缓冲期，再执行下线。阿里云 DataWorks 文档说明，API 下线或删除后，已授权的工作空间无法继续调用；已授权的 API 被下线或修改后重新发布，需要负责人重新授权。这个机制提醒我们，下线前要把调用方迁移安排好。
四、数据服务权限如何控制
1. 三层权限：身份、服务、数据
数据服务的权限可以拆成身份、服务、数据三层权限，逐层收口。
- 身份认证，解决调用方是谁。常见方式包括应用身份加密钥、Token、OAuth 2.0、AK/SK 签名。服务间调用要避免使用个人账号，应用身份更利于轮换、审计和离职交接。
- 服务授权，解决哪个应用能调用哪个 API。可以由服务方主动授权，也可以由调用方申请、审批通过后授权。授权要设置有效期，到期回收。
- 数据权限，解决同一个 API 对不同调用方返回什么范围，包括行级权限、列级权限和字段脱敏。
管理权限也要分开。谁能创建、谁能修改、谁能授权、谁下线，尽量不要集中在一个人身上。部分平台会拆成使用权限、管理权限和授权权限三级，这种拆分值得借鉴。
图2：数据服务的三层权限
2. 行级权限：用条件限定范围
行级权限控制的是数据范围，实现上可以理解为给查询加一组过滤条件。按组织、区域、门店、客户归属或业务线限定，调用方只能看到自己范围内的数据。
比较常见的实现方式是在服务层拦截查询，根据调用方身份改写 SQL，再交给执行层返回结果。规则字段必须来自数据集模型，不能引用模型外的字段。多层规则要注意 AND 和 OR 的优先级，避免出现预期之外的放大范围。
行级权限要覆盖所有入口。如果某个报表、导出或临时查询绕过了服务层，行级权限就会出现缺口。
3. 列级权限与脱敏：控制看到什么状态
列级权限控制的是字段状态，通常有两种处理，禁止查看和脱敏查看。禁止查看适合与业务无关的敏感字段，脱敏查看适合业务需要但不宜展示原文的字段。
可结合场景使用掩码、替换、截断或哈希等处理。哈希、加密不自动等于匿名化，密钥、关联信息和重识别风险仍需管理。手机号、身份证号、地址、薪酬等字段，可以按敏感级别配置不同规则。动态脱敏的好处是同一份数据对不同调用方呈现不同结果，不需要在每个应用里重复实现。
字段级最小返回仍然是第一道防线。接口设计时默认不返回敏感字段，确有业务需要时再单独开字段权限，比先返回全量再让调用方自己脱敏更可控。
4. 网关与运行时控制
API 网关承担统一入口和运行时防护。常见能力包括限流、熔断、超时、IP 或应用黑白名单、请求大小限制和全链路审计。
限流要分服务级和应用级。一个调用方异常高频调用，不应该拖垮整个数据服务。审计日志至少记录调用方、调用时间、接口、参数摘要、返回行数、耗时和结果状态。失败和拒绝的调用也要记录，否则越权尝试和配置错误很难发现。
传输层使用 TLS。对特别敏感的报文，可以增加报文加密或字段加密。加密解决传输和存储安全，权限解决访问范围，两者不能互相替代。
5. 权限治理的常见坑
- 只做接口授权，不做行级和列级权限，导致同一接口对所有调用方返回同一份数据。
- 身份体系分散，应用、账号、密钥各自维护，离职或系统下线后权限没有回收。
- 授权没有有效期，临时权限变成长期权限。
- 测试环境使用生产数据且未脱敏。
- 审计只记录成功调用，不记录拒绝、异常和高频访问。
- 权限规则写在应用代码里，服务层没有统一拦截，接口一多就失控。
五、数据服务如何复用
1. 先查后建，把复用写进流程
复用需要机制，不能只靠开发人员自觉。新需求进来时，先做服务目录检索，再评估现有接口能不能覆盖。
评估可以看五个维度，输入参数、输出字段、数据源、业务逻辑和数据粒度。现有接口能覆盖新增要求，就直接复用。部分覆盖的，可以扩展参数或增加可选字段。不能覆盖的，再新建服务。一个实用的原则是，现有接口能覆盖新增要求，一律复用，把这条原则写进需求受理流程。
2. 用服务编排减少重复开发
有些需求需要组合多个服务，比如先查用户，再查订单，最后汇总指标。每次都在调用方写一遍组合逻辑，复用会打折扣。
API 编排可以把已经发布的服务按业务逻辑串行或并行组合，通过一个入口 API 返回结果。适合放在编排层的是跨域组合、字段映射、格式转换和轻量业务规则，复杂计算仍然应该沉淀到数据加工层。编排本身也要测试、发布和版本管理，不能成为新的黑盒。
3. 复用需要契约稳定
接口能被多个系统长期调用，前提是契约稳定。字段含义、指标口径、枚举值和错误码不要随意改。新增字段尽量可选，旧字段保留，版本共存。命名、分页、时间格式和错误码风格统一，调用方接入成本会低很多。
服务 Owner 要对变更负责。变更前通知调用方，说明影响范围、迁移方式和时间窗口。没有 Owner 的接口，最后很容易变成无人维护的孤儿接口。
4. 怎么衡量复用
复用指标不要只看一个数字。可以组合看以下几类。
| 指标 | 口径 | 用途 |
|---|---|---|
| 服务目录完备度 | 有契约、Owner、示例和申请入口的服务占已发布服务的比例 | 判断目录能不能支撑查找和申请 |
| 多应用调用服务占比 | 被两个及以上应用调用的服务数除以已发布服务数 | 观察跨系统复用情况 |
| 重复接口减少数 | 通过复用或合并下线的重复接口数量 | 判断治理是否减少重复建设 |
| 申请到首次调用时长 | 从申请提交到首次成功调用的时间 | 判断服务是否易用 |
| 零调用服务数 | 统计周期内无调用的已发布服务 | 推动下线或重新评估 |
| 调用成功率与 P95 响应时间 | 按服务和调用方统计 | 判断服务质量和稳定性 |
复用率高不一定代表价值高。一个服务被很多应用调用，可能只是因为它是通用查询；一个服务只被两个核心系统调用，也可能支撑了关键流程。指标要和业务覆盖、重复建设减少、故障收敛一起看。
六、数据服务如何验收与运营
1. 上线验收清单
一个新服务上线前，可以按功能、安全、稳定、文档、运营五组检查。
- 功能组，参数、返回字段、分页、排序、空结果和异常提示是否符合契约。
- 安全组，身份认证、服务授权、行级权限、列级权限、脱敏、限流和审计是否配置完成。
- 稳定组，是否做过压测，超时、缓存、降级和重试策略是否明确。
- 文档组，接口文档、调用示例、错误码、版本记录和变更通知是否齐全。
- 运营组，Owner、SLA、监控告警、权限回收和下线计划是否确定。
这五组检查不需要很复杂的工具，一张清单加上责任人签字，就能挡住大部分低级问题。
2. 日常运营机制
数据服务上线后进入运营期。建议固定三类动作。
- 服务评审。新服务准入时检查是否和现有服务重复，命名和契约是否符合规范。
- 定期盘点。按月度或季度看调用量、成功率、响应时间、零调用服务和权限回收情况。
- 变更管理。接口变更提前通知，必要时灰度发布，保留回滚方案。
调用方反馈也要有闭环。接入慢、文档不清、参数不合理、错误码难排查，这些问题看起来琐碎，却直接影响复用意愿。
3. 数据服务与Agent的协作
Agent 取数同样需要标准入口、权限和审计。数据服务可以作为 Agent 调用企业数据的工具层，Agent 通过接口获取指标、标签或业务对象，权限仍然按调用身份控制，调用过程仍然留痕。
ThinkingAI 已服务全球超过1500家企业、接入产品超过 8000 款，其 Agentic Engine 支持私有化部署，企业可以在自有环境中创建和管理 Agent，并进行多 Agent 协作。其企业级知识库通过统一接口对外提供检索与查询，知识更新、版本追溯与回滚能力应按实际部署版本核对。对于正在同时推进数据中台和 Agent 落地的企业，可以把数据服务与知识服务放在同一套权限和审计框架下规划，减少两套体系各自维护权限的成本。
如果现阶段还没有完整的数据服务层，可以先从三到五个高频场景做试点，把服务目录、契约、授权和监控跑通，再逐步扩展。想了解调用方式与责任边界，可以阅读AI Agent与数据中台如何协作。
理解企业智能体的能力与责任边界，可参阅什么是企业级AI Agent。
常见问题
1. 数据服务一定要先建API网关吗
不一定。调用方少、范围小时，平台内置的鉴权、限流和监控可以先跑起来。调用方增多、需要统一入口、统一审计和统一流控时，网关的价值会明显上升。网关负责统一入口，统一管控是它要解决的问题。
2. API发布后修改权限，需要重新授权吗
看平台和变更类型。通常修改授权范围、有效期或调用方，会直接影响调用权限。API 下线或删除后，原有授权会失效；已授权的 API 被修改后重新发布，部分平台要求负责人重新授权。变更前要通知调用方，变更后要验证调用是否正常。
3. 服务复用率怎么算比较合理
可以用被两个及以上应用调用的服务数除以已发布服务数，作为观察指标。同时看重复接口减少数、申请到首次调用时长、零调用服务数和调用覆盖率。单一复用率容易被接口拆分方式影响，不适合单独作为考核指标。
4. 直接开放数据库不是更省事吗
短期看省事，长期会遇到三个问题。权限粒度难控制，SQL 质量参差不齐，表结构变更影响多个系统。API 层把查询逻辑、权限和限流收口，变更影响也更容易评估。临时分析仍然可以走受控的查询通道，不必所有场景都走 API。
5. 数据服务API一次返回多少数据合适
按调用场景控制单次返回量。列表查询使用分页，单页大小由业务需要和接口性能共同确定，常见做法是先设一个上限，再由调用方传页码和每页条数。报表导出、批量对账这类大数据量需求，走异步任务、文件下载或数据共享交换，不占用同步 API。网关侧同时设置请求大小、超时和限流，避免一次异常请求拖垮服务。
6. 小团队没有专职数据服务团队怎么建
先做服务目录和三到五个高频服务，指定现有数据开发或数据产品人员兼任 Owner。权限和网关尽量复用公司现有能力，不单独造一套。把契约、测试、授权、监控和下线写成简单清单，先跑通一个闭环，再考虑平台化和自动化。
参考资料
- 华为云 DataArts Studio 数据服务简介，https://support.huaweicloud.com/intl/zh-cn/ally-visitor-1-usermanual-dataartsstudio/dataartsstudio_01_0301.html
- 阿里云 DataWorks 授权API，https://www.alibabacloud.com/help/zh/dataworks/user-guide/grant-permissions-to-call-an-api
- 帆软 FineDataLink 数据 API 全生命周期管理，https://www.finedatalink.com/blog/article/6ac4cee953504fa49bad168e
- 腾讯云开发者社区《数据中台-数据权限》，https://cloud.tencent.cn/developer/article/2434424
- 中国日报网《标准发布，新版DCMM国标7月1日实施！》，https://tech.chinadaily.com.cn/a/202601/15/WS69685b52a310942cc499b55f.html
