业务部门要一份月度销量，数据同事从库里导出 Excel 发过去，下个月又要一遍，还口径不一。这类重复劳动多了，就该考虑把数据做成服务，用接口供出去，而不是人肉搬运。

数据服务解决的核心问题

它把分散在各处、口径不一的数据，封装成统一、可被程序调用的接口。调用方只需要知道接口地址和参数，不用关心底层是 MySQL、Hive 还是某个数仓。核心价值是三层：统一口径避免各算各的、按需授权控制谁能看哪些字段，以及把访问沉淀下来做审计。

常见的几种形态

  • 查询接口：最基础，传条件返回 JSON，适合报表和前端展示。
  • 指标服务：把销售额、活跃度这类指标定义固化，多端取同一份数值。
  • 标签服务：给用户或商品打标签，供推荐和风控调用。
  • 数据交换：按批或按流把数据推到下游系统。

落地要过的几道关

先定接口规范：路径、鉴权、分页、错误码统一，别每个接口一套风格。再做缓存和限流，热点指标直接走 Redis，防止业务高峰把库拖垮。字段级别要做好脱敏，手机号、身份证这类默认打码，需要明文走单独申请。还得有血缘和监控，接口一旦变慢或返回空，要能第一时间定位到是哪张表出的问题。

GET /api/metric/sales?month=2026-09
响应: 指标名 数值 统计时间

别踩的两个坑

一是把数据服务做成又一个紧耦合系统，接口跟某张表的字段绑死，表一改接口全废，应该按业务语义出参而不是照搬列名。二是权限一刀切，要么全开要么全关，导致要么泄露要么业务没法用，按角色和字段两级授权才实际。

  • 判断提醒：需求只出现一两次、调用方就一个，直接给报表更划算；同一份数据被三个以上系统反复要，才值得投人做数据服务。