数据服务架构设计:数据契约、查询链路与高并发实践

数据服务在架构设计里是最容易被低估的一层。早两年我参与过一个数据平台建设，数仓、调度、指标系统都搞完了，结果业务部门反馈最强烈的不是模型慢，而是“数据接不出来”。今天A系统要客户明细，明天B系统要看实时订单，后天风控又要按小时批量拉特征。一开始大家图省事，各自去连Hive、查Kafka、读MySQL备用库，后来连接数被打爆，权限完全失控，同一个“活跃用户”在三个系统里口径都不一样。那时候我才意识到，数据服务不是简单包装几个API，它是一个有独立设计逻辑的架构层，把它当业务微服务来做会出事，把它当一个普通查询网关来做更会出事。

这篇文章我想把这几年的实践梳理一下，重点聊数据服务架构里真正需要拿捏的要点——数据契约怎么做，查询链路怎么设计，在线和离线场景怎么隔离，以及我自己经历过的一次慢接口事故复盘。内容偏架构向，适合数据平台负责人、后端架构师，以及准备把数据能力系统化对外开放的团队参考。

1. 先分清：数据服务到底要把问题解决在哪一层

很多团队一提到数据服务，第一反应是做“接口平台”，把表字段映射成HTTP参数，然后用一个Web服务包起来。这个思路本质上还是把数据服务当业务系统做，最后做出来的东西，只是一层薄薄的翻译器。真正需要解决的问题，根本不在于“把表变成接口”，而是在数据资产和业务消费之间，建立一个稳定的、可治理的、能屏蔽底层变化的结构。

1.1 数据服务不能照着业务微服务的路子设计

业务微服务的核心是业务逻辑，领域模型、事务边界、状态流转都围绕业务展开。而数据服务面对的是数据资产，它没有复杂的业务状态，但它有一个非常麻烦的特点：数据是二维结构，而且同一份数据会被多种场景以不同维度消费。

举个例子，订单域的业务微服务，关注的是“创建订单”“支付成功”“取消订单”这些行为。而数据服务层的订单数据，消费方可能是经营分析看板，需要聚合统计；可能是推荐服务，需要实时读用户最近几单；可能是财务系统，需要按时间区间批量拉全量流水。同一个订单主题，读取模式完全不一样，有的要单条点查，有的要跑全表扫描，有的要流式订阅。

这时候如果照着业务微服务的模式去做，比如一个订单数据服务，加一个list接口、一个detail接口、一个batch接口，开始可能跑得通，但很快会被两类需求打穿：一类是新的查询维度，业务方说我要按省份、按商品类目、按支付渠道组合筛选，你只能在接口里不断加参数，直到接口变成一个失控的动态SQL壳；另一类是数据模型变更，底层表加了个字段、改了枚举值、把订单金额从int变成decimal，API的返回结构就得跟着动，下游再跟着改一版。

所以，数据服务在设计起点上，首先要想的不是“有哪些接口”，而是“我提供的到底是表访问能力，还是模型消费能力”。如果只是表访问能力，那不需要架构，给个JDBC连接串就行。真正需要数据服务架构的，是这个问题的另一面：把一份数据资产，按照业务语义进行封装，让消费方拿到的是他们能理解、能信赖的结构化结果，而不是裸表。

1.2 认识四类需求形态，才能确定服务的边界

从实际需求形态来看，企业内部对数据服务的调用大致落在四种模式上。我习惯用下面这张表来辅助判断服务的形态。

这四种形态如果混在一个接口里，后果就是服务设计完全被长尾需求绑架。我见过一个数据服务接口，最初只是给前端列表页做分页查询，结果被后台报表系统当作数据源持续调用，参数里带上一个非常复杂的group by表达式，查询直接就把底层OLAP引擎打挂了。事后复盘，问题出在设计阶段没有区分轻量查询和分析型查询的边界，等于让一个零钱柜台去接大额转账业务，所有流程都没错，但服务吞吐模型不匹配。

数据服务架构要解决的第一件事，是把这四类需求从链路入口就识别出来，引导到不同的处理通道。后面几章我们展开讲，这里先记住一个结论：数据服务不是越通用越好，而是要对“查询模式”做区分，不同模式意味着完全不同的资源策略、超时策略、缓存策略。

1.3 数据服务的本质产出是“稳定数据协定”

再往深处说一层。为什么不能让业务方直接查数据仓库？因为数据仓库内部是持续演化的。物理模型要优化、分区策略要调整、引擎版本要升级、计算引擎甚至可能从Hive迁到Spark再迁到ClickHouse。如果消费方和这些内部状态直接绑定，每一次底层变更都意味着一次业务系统适配。

数据服务层存在的最核心意义，是提供一个“稳定数据协定”。业务方看到的是一套长期稳定的数据形态，比如“订单金额”“用户等级”“活跃状态”，服务层负责把底层不断变化的物理存储翻译成这些稳定概念，并在翻译过程中完成鉴权、过滤、口径统一、数据脱敏。

这个思路