数据服务架构设计与落地：从数据质量到API网关实践

1. 数据服务的本质把数据变成能被业务直接使用的资产1.1 数据服务到底在解决什么问题做了这么多年大数据平台我越来越觉得数据服务这个词被说得太玄了。本质上它就是解决一个问题原始数据躺在HDFS、Kafka、ClickHouse这些地方业务方怎么才能安全、高效、标准化地拿到自己想要的数而不是每来一个需求就让数据工程师写一个临时接口。早期我们团队就经历过这种痛。业务部门要一个用户画像标签数据组从Hive里跑一张表导给产品产品自己写查询拼逻辑结果口径对不上同一天活跃用户数运营看的是19.8万产品看的是21.3万最后两个人扯皮扯了一下午。后来发现是ETL跑数时间不同一个是凌晨快照一个是实时汇总。这种问题靠人盯是盯不过来的必须从体系上解决这就是数据服务存在的意义。数据服务要干的活很明确统一数据出口所有取数、指标计算、标签查询都走同一套服务从源头上掐掉口径混乱。把底层存储的复杂度隔离掉上层业务不关心中间用了Hive还是Doris拿到的是已经加工好的结构化结果。给数据访问加一层权限和审计谁能看什么数、什么时候看的、查了多少量全部留痕。用标准接口代替“人肉取数”把数据变成一种可以随时调用的基础能力。所以数据服务的价值前面永远是“给业务使用”而不是把数据堆在仓库里自我欣赏。这也是为什么很多公司明明上了数仓、上了中台数据资产却还是用不起来因为他们只做了存储和计算没有做服务化这一层。1.2 数据服务在企业数据平台中的位置如果一张图看数据平台的架构通常从下往上分好几层数据采集层、数据存储与计算层、数据仓库层、数据服务层再往上才是数据应用。数据服务层的位置正好卡在数仓和应用中间承上启下。没有数据服务层的时候应用的每个需求都得单独跑到数仓层或者存储层去捞数。开发一个报表要写SQL做一个推荐要写MR任务搞一套风控要对接Kafka消费原始日志每一条链路都是定制的改一处牵全身。有了数据服务层之后数仓只需要把数据加工成标准化的宽表、指标、标签服务层把这些资产包成API或数据集业务方按需申请和调用链路就规整多了。从团队协作角度看有了这层之后数据工程师和业务开发的边界也变清晰了。数据团队负责把数加工好、把服务发布好业务团队负责消费服务而不是直接给一堆表、一堆SQL让业务自己去拼。这层做好之后取数效率能提升好几倍我们当时上线统一数据服务网关之后单个新需求的交付周期从平均3天压缩到半天以内主要工作全部集中在权限审批和数据质量校验上真正开发的时间很少。2. 数据架构演进与服务化思路2.1 从数仓到中台再到服务化这条路是怎么走过来的回头看过去十年的数据架构演进其实是分阶段的。最早是传统数仓时代ETL跑批每天凌晨把业务库的数据抽到Oracle或Teradata里白天业务看报表。这个阶段数据服务的方式就是报表BI工具直接连数仓最多建个汇总层。然后是Hadoop生态兴起的时代HDFS加Hive成为数仓底座数据量大了SQL也能跑批了。但查询体验并不好跑一个报告要几分钟甚至几十分钟业务方接受不了于是又引入了Kylin、Presto、ClickHouse这些加速查询的组件。这个阶段数据服务开始雏形化有统一的数据平台有自助取数但接口形态还是没有标准化各项目各搞各的。再往后就是数据中台和服务化。中台的核心是把数据能力产品化、复用化数据服务作为中台的出口把数据仓库生产的指标、标签、算法结果统一以API和服务的方式输出给内部多个业务线。大家现在看一些大厂分享的架构图中间一定会有一个服务层上面挂着一堆API、一个数据网关、一套统一权限中心这就是服务化之后的典型面貌。这套演进背后的逻辑其实就是数据从“资源”走向“资产”再走向“服务”的过程。资源只是存在那儿资产是经过治理有价值的服务才是能被业务真正消费的形态。我见过不少团队跳过了服务化阶段业务需求一多就乱了接口满天飞建了一堆服务没人维护最后又回到人肉对数的状态本质上是没有把服务化的标准和规范立起来。2.2 数据服务架构的四个核心环节一个可落地的数据服务架构我习惯把它拆成四个环节接入、加工、服务供给、服务治理。接入环节解决的是数据从哪来离线用Sqoop、DataX同步业务库数据或者直接读ODPS表实时用Canal监听MySQL binlog或者消费Kafka里的埋点日志。这个环节的核心是稳定采集任务挂了要能自动告警和重跑不然下游全断。加工环节就是数仓的建设分层建模明细层、汇总层、应用层一层层往上捋。这一层的产出物是宽表、指标和标签是整个数据服务的内容来源。很多团队在加工环节不重视规范化导致一张宽表字段命名混乱服务层开发的时候根本不知道该用哪个字段等于把问题后移了。服务供给环节是把加工好的数据包成service。形式可以是统一的SQL查询网关、预计算的API、多维分析接口或者是直接把数据推到KV存储里提供毫秒级查询。这一层要做的就是屏蔽底层引擎的差异给上层一个统一的接口视图。服务治理环节是对整个服务生命周期做管理服务发布、版本管理、调用量监控、熔断降级、权限管控、审计日志缺一不可。没有治理环节服务两三个月就会变成一团乱麻谁改了底层表结构谁也说不清。这四个环节环环相扣每层都要有专门的标准和负责人整个服务化才跑得起来。3. 关键技术选型与集群部署策略3.1 计算引擎选型Hadoop、Spark、Flink到底怎么选聊到大数据服务的底层必然绕不开计算引擎。很多刚入行的同学一上来就问Hadoop是不是已经淘汰了直接上Flink行不行。我的回答通常是没有银弹只有适不适合你的场景。Hadoop主要指MapReduce和HDFS在批处理领域依然有它的价值尤其是超大规模数据集上的全量离线计算稳定性和生态成熟度没得说。但它的实时性很差分钟级起步不适合要求秒级响应的交互式分析场景。如果你的场景主要是一天跑一次、处理几TB到几十TB的离线数据Hadoop加Hive完全够用没必要过度设计。Spark算是一个很好的升级选项。它把计算放到了内存里迭代计算快很多而且统一了批处理和流处理Structured Streaming一个引擎能覆盖多种场景。我们实际生产环境里Spark是主力跑数仓ETL、跑特征工程、跑模型训练的数据预处理都很顺手。Spark对资源的管理比较灵活既能跑在YARN上也能跑在Kubernetes上跟现有集群集成很方便。Flink的强项是真正的流式处理和低延迟状态计算毫秒级延迟。如果业务需要实时风控、实时大屏、实时推荐这类场景Flink是绕不开的。但要注意Flink的运维复杂度明显高于Spark而且做流批一体这件事目前还不能完全替代Spark的批处理优势所以常见做法是Flink管实时链路Spark管离线链路两套并行中间靠统一元数据管理来对齐口径。选型时还有一个容易被忽略的点团队的技术积累。Spark的社区资料和踩坑案例都很丰富招人也容易Flink人才相对少一些部署出问题排查的难度更高。所以先从稳定的场景跑起来再逐步扩展是更现实的路线。3.2 集群部署的规模评估与角色划分集群部署这件事最怕一拍脑袋就定规模。我见过一个团队总共几十GB的数据量愣是配了5台32核64G的机器跑HDFS三个月后机器闲置率超过80%维护成本全花在无意义的高可用上。反过来也有团队数据量已经上百TB了还在用三台破机器硬扛集群两周宕机一次。规模评估有一个粗略的计算方式。先估算每天的增量数据量和存储周期比如日增500GB保留30天那么HDFS原始存储量大约是15TB考虑三副本就是45TB再算上中间结果、临时表、测试环境至少再预留50%的冗余那么总存储大概在70TB左右。按单盘4TB、单节点12盘位、故障冗余20%计算大概需要20来个节点就能满足。角色划分上我建议至少区分Master节点和Worker节点。Master节点跑NameNode、ResourceManager、HMaster等管理角色对内存要求高不建议跟数据节点混部Worker节点吃磁盘和网络主要跑DataNode和NodeManager。如果用了Doris或ClickHouse这类MPP引擎还要单独规划计算和存储资源避免和离线任务抢I/O。比较稳妥的做法是初期统一规划一套Hadoop集群跑HDFS、YARN、Hive后续计算引擎按实际需求动态扩容。如果业务量不大尽量少引入组件不要为了技术炫技把架构搞得极其复杂因为每一套组件都对应一份运维成本。3.3 部署过程中几个容易踩的坑部署这块我踩过的坑不少挑几个有代表性的分享给各位。第一个是网络配置。Hadoop集群内节点之间通信非常频繁特别是Shuffle阶段网卡打满直接拖垮整个任务。所以节点之间一定要走万兆内网千兆环境跑大数据集群性能压测很难达标。另外防火墙规则要放通透传端口不然DataNode注册不上NameNode排查起来极其痛苦。第二个是Java版本和参数设置。Hadoop 3.x对应Java 8或Java 11但具体分支不一样用了不兼容的版本经常出现一些莫名其妙的报错比如UnsupportedClassVersionError排查半天发现是默认JDK版本不对。还有YARN的调度内存和总内存要算好如果每台机器资源配置和NodeManager配置不一致容器起不来任务一直Pending。第三个是数据均衡问题。集群跑久了冷热数据分布会很均匀是不可能的经常出现某些节点磁盘使用率90%另一些才50%。这时候需要定期做Balancer建议在业务低峰期执行同时要对Balancer的带宽做限流否则会影响线上任务的读写速度。我习惯在凌晨两点后跑限速20MB/s一晚上也能均衡不少。4. 数据质量与数据治理数据服务的地基4.1 为什么说质量是数据服务不可妥协的底线数据质量听起来是个老生常谈的词但它在数据服务场景里的重要性要比想象中大得多。数据服务是面向业务直接输出的业务方不会关心你的管道多么健壮、你的数仓模型多么规范他们只关心接出来的订单金额对不对、用户数准不准。一旦数据出错他们对数据团队的信任度会断崖式下降后面再想挽回就很难了。我印象里有个印象很深的案例一次大促活动运营实时大屏的GMV跑得比业务库多出一大截原因是实时计算里的去重逻辑写错了把同一个订单在多个渠道带来的重复流量也算进去了。虽然技术团队马上修复了但大屏上展示的错误数据已经被很多人截图传播后面再怎么解释数据已经修复影响还是很难消除。这就是数据质量的信任成本一旦发生就很难量化。所以数据服务建设的第一条原则就是宁可让数据晚到也不能让错误数据发布出去。这也是为什么我们坚持在服务层前面加一层质量校验关卡不管是离线指标还是实时指标发布之前必须经过完整的校验流程否则不允许上线。4.2 质量校验的常见方式和落地细节数据质量校验常规的做法是对几个核心维度做检查完整性表行数、字段空值率、主键重复率。比如当日用户表行数比前一天骤降50%大概率是上游同步任务出问题了。准确性核心指标和源系统或上一级口径做对比允许的误差要在合理范围。比如订单金额和业务库的总额做波动检测偏差超过某个阈值就报警。及时性看数据到达时间离线任务必须在规定时间点跑完实时任务必须保证一定的产出延迟。一致性体现在维度表中同一ID对应的属性值一致不会出现同一天在两张表里性别不同这种问题。落地上离线链路我们常用方式是调度平台自带的数据质量节点比如DolphinScheduler或者DataWorks里的质量监控在任务跑完之后自动执行一段校验SQL失败就阻断下游并告警。实时链路比较麻烦需要在计算逻辑里埋点打指标比如在Flink里自定义一个Sink把每五分钟的输入行数、主键去重数、最大事件时间打到Prometheus配合Grafana看曲线配合告警规则跑出异常时能第一时间发现。实时链路的校验还有一个思路用离线任务产出的T1数据反哺实时链路的质量基准。比如昨天的离线指标算出来是1000万今天实时链路在相同时间段内如果跑出950万以下或者1100万以上就说明实时链路大概率有问题这样可以自动触发回放或重算。另外要注意的是质量校验不能只在校验节点做还要在服务入口做。API层对每次请求的返回结果做基本的结构校验字段缺了、类型不对、行数异常都记录下来。服务入口的问题更容易被业务感知必须留足够的日志才能快速定位。4.3 主数据管理与指标口径统一数据服务最容易出问题的其实是口径问题也就是同一份数在不同地方被算出来不一样。这个问题的根源经常在于“主数据”没有统一管理。拿“用户”来举例用户在注册库、订单库、日志库里的ID体系可能都不一样有的是user_id有的是uid有的是手机号。如果不做统一的用户主数据ID映射服务层在关联数据的时候就会出问题要么关联不上缺数据要么关联错乱导致脏数据。解决办法是建立统一ID-Mapping体系把各端的身份标识通过图计算或规则归一到同一个统一的用户ID上服务层只认这一套ID。指标也是一样。因为各业务线对“活跃用户”的定义不一样有的是启动过APP就算有的是做过某个关键动作才算如果不统一同样的指标名背后其实是完全不同的统计口径。所以在建设数据服务之前必须先有指标字典每个指标要有唯一编码、名称、定义、计算公式、统计周期、维度归属。这个字典要挂在数据资产平台上任何人访问指标前先查字典。我自己的经验是指标口径的统一是最难推进的因为背后是业务利益和认知差异。技术手段能做的是尽量把定义写清楚、把逻辑固化成代码减少人工解释空间但真正让各方达成共识还是需要数据治理委员会这类机制来推动。技术再强也替代不了组织协同。5. 数据服务的主流落地方式与API化实践5.1 数据服务的三种常见落地形态数据服务在不同公司、不同场景下落地方式差异很大但归纳下来无非三种形态。第一种是查询式服务。最常见的形式就是提供一个统一SQL查询网关业务方通过HTTP或JDBC提交SQL由网关解析、路由、执行并把结果标准化返回。这种形态适合交互式分析、即席查询、报表系统。优点是灵活什么都能查缺点是对底层的安全管控要求很高不可能直接让业务方裸查Hive表。第二种是API式服务。把通用的查询逻辑封装成一个个Restful API业务方直接传参数就能拿数据不需要关心SQL和底层表。比如用户标签查询接口、订单统计接口、实时指标接口。这种形态适合高速访问、稳定输出、多团队复用的场景是数据服务的主流。第三种是推送式服务。数据服务主动把数据推到业务的存储或者消息队列里比如把特征数据推送到线上模型的Redis把排名数据推送到排行榜服务的缓存或者把结果推送到企业内部的报表中心。这种形态适合对实时性要求高、业务不希望每次都来调接口的场景。三种形态不是互斥的做得好的数据服务通常会同时支持几种。比如一个数据服务门户既提供自助查询能力也提供标准API给开发同时支持结果订阅推送。5.2 数据API网关的典型设计API网关是服务化落地中最核心的组件它的设计好坏直接决定了服务的稳定性、安全性和可扩展性。网关层通常要做几件事路由转发、鉴权、限流、熔断、日志、动态模板。以我的经验看下面几个细节对上线后的体验影响最大。路由规则根据请求路径或者Header里的集群标识把请求转发到对应的计算引擎或存储。比如/api/v1/metric/user走预计算的Doris/api/v1/tag/batch走ES/api/v1/ad_hoc/query走Presto. 路由表要支持热更新新增服务时不能重启网关。参数校验与动态SQLAPI发布时定义好入参格式和出参结构网关根据模板自动生成可执行的查询语句。这里要特别小心SQL注入一定不能用字符串拼接建议所有查询走预编译或参数绑定。限流熔断限流不能只做简单的全局限流要按接口、按调用方维度做精细化控制。比如某业务方申请了每秒100的QPS超过的请求可以排队或直接拒绝避免一个调用方把服务压垮导致所有人都不可用。熔断要基于错误率和响应时间的滑动窗口连续的5xx或超时达到阈值就自动降级。缓存策略热点数据做本地缓存加分布式缓存两级。比如某个指标30秒内是高频读、低延迟要求可以直接在网关内存里缓存命中率能达到90%以上。但缓存一定要设置合适的TTL和失效策略避免数据长时间陈旧。全链路追踪每一次请求要有一个traceId从网关到引擎到返回值全部串起来。出了问题能用traceId快速定位到是哪一环慢了或者错了。没有链路追踪的API网关维护起来就像蒙着眼睛找针。网关整体框架上如果团队有Java背景Spring Cloud Gateway是比较成熟的方案如果团队偏运维Nginx加OpenResty也能做一层灵活的代理还有些公司直接用高吞吐的消息网关组件把查询请求分流。没有最强的只有最匹配团队的。5.3 权限控制和审计日志的注意事项数据服务的权限管控比普通业务服务的权限要严格得多因为数据资产的泄露风险太直接了。这块我见过的教训不少总结几点重要的。权限控制的核心是“最小够用原则”。每个调用方只能拿到自己业务范围内的数据每一个API都要有独立的权限配置。比如用户标签查询接口A运营线只能查自己分管的用户群体不能查全部用户。这里如果做不好数据服务上线之后基本就是裸奔状态。实现上API网关要接统一权限中心配置每类调用方可以访问的数据域、指标和维度而不仅仅是接口级别的权限。接口内部要根据调用方身份动态拼接过滤条件从查询源头做数据行级管控。只控制接口不控制行级等于没控。还有一个容易被忽略的是返回结果脱敏。手机号、身份证、邮箱这类敏感字段在数据服务出口统一做脱敏处理根据调用方的密级和用途决定是明文返回、掩码返回还是拒绝返回。脱敏不能在应用层做要在服务层统一做很多应用引了数据自己脱敏经常脱不干净。审计日志要记录调用方、接口、时间、请求参数、返回行数、处理耗时、状态码。这个日志除了合规要求之外还有两个实际用途一是做成本分析知道哪些调用方消耗了多少查询资源后续可以推进成本分摊和容量规划二是做安全分析发现异常调用模式比如某个接口凌晨大量被调用就要留意是不是数据被拖走了。6. 数据服务相关岗位的面试重点与成长路径6.1 高频面试题背后考察的真实能力最近大数据面试题一直都是热门搜索词说明这个行业的入行人很多但真正理解数据服务价值的候选人并不多。我作为面试官经常会从几个角度去考察候选人这里拆解一下背后的意图。第一类问题问项目经历。“你们的数据平台服务是怎么设计的”这个问题重点看候选人是否有全局视角能不能把自己的模块放到整体架构里讲清楚。很多时候候选人会陷入自己的技术细节把Spark调优讲得飞起但一问到数据从哪来、服务如何发布、权限怎么控就答不上来了。这反映出只看到局部没理解数据服务的全链路。第二类问题问选型取舍。“为什么用Flink不用Spark Streaming”这类问题没有标准答案但能看出候选人是否理解选型背后的业务诉求。面试官不是要你背一堆特性对比而是希望听你说当时业务要求秒级延迟、有状态计算、需要精确一次语义所以选了Flink但它运维成本高所以把非核心链路还是留在Spark上。有取舍的答案才是有经验的答案。第三类问题问数据质量和口径。“数据对不上怎么办”很多候选人都会说加监控、加告警。但好一点的回答会从根因出发先判断是同步延迟、计算bug还是口径不一致然后分别应对同步延迟看监控曲线计算bug查日志回放口径问题要建指标字典从源头治理。这个问题的考察点在于候选人的排查思维条理性。第四类问题问业务理解。“这个指标上升了10%你会怎么分析”这类题是考察数据服务能不能对业务产生真实价值。不会只是跑个数出来而是要结合业务场景判断是正常波动还是异常是哪个维度驱动的是否需要触发预警。数据服务最终是要服务业务的不懂业务的数据工程师做出来的服务很难让业务用起来顺心。6.2 数据科学与大数据技术的就业方向数据科学与大数据技术专业的同学就业方向其实比很多人想得要宽不要只盯着算法或数仓这两个窄方向。从数据服务链路来说大致有三类角色数据工程师、数据平台工程师、数据分析师。数据工程师侧重ETL开发、数仓建模、实时计算离数据加工更近数据平台工程师侧重组件运维、调度系统、数据服务网关的开发和优化离技术基建更近数据分析师侧重取数、指标体系、业务洞察离业务更近。这三个方向各有各的门槛和发展路径。如果从薪资和成长空间看数据平台工程师现在缺口挺大的因为很多公司数据基建都在走向服务化和一体化懂Flink、Spark、Doris、数据治理和API网关的人非常稀缺。这个方向要求技术栈全面既要懂大数据组件也要有一点后端开发和架构设计能力对刚入行的人来说是一个值得投入的方向。数据服务这个领域经验的价值很大。越是在一线踩过坑、处理过数据质量事故、设计过服务治理的人越能在面试中展现出竞争力。建议同学在学理论的同时多找机会做真实的项目哪怕是自建一个迷你数据服务平台把采集、加工、服务、治理走一遍面试时拿出来讲比背一百道面试题都有说服力。我在实际带团队的时候也发现能快速成长的新人通常不是技术基础最强的而是愿意从数据全链路去理解问题的。他们不会写完一个Spark任务就交差而是会追问这个表下游谁在用、指标口径准不准、出了问题怎么排查。这种思维习惯放到任何一家公司的数据团队都是很吃香的。数据服务这个方向越做越有意思因为它既要懂技术也要懂业务还要懂治理。把这条路走通了你就不再是那个天天被业务追着要数的工具人而是真正在搭建企业数据资产的桥梁。