做数据集成这几年被业务部门追着问最多的需求之一就是“客户360”。听起来简单打开一个页面这个客户是谁、买过什么、有没有售后、最近在干嘛全都能看到。可真动手做的人都知道页面只是最后一层皮底下的骨头是数据能不能在同一个时间点、以同一个ID、把散落在五六个系统里的信息拼到一起。今天这篇我就把这套“基于ETL与API的多源数据集成”方案完整拆一遍——从客户360的数据盘点、ETL管道设计、API实时接入到最终查询服务与实时刷新全程都是实际跑过的工程路径。适合正在做客户数据平台、会员中台或数据服务化的数据工程师和后端开发参考。1. “客户360”的真相一个页面背后的数据治理工程1.1 业务方的“一个页面”和技术侧的隐性工作量业务方描述需求往往很轻巧他们眼里这是一个“页面”。真正接手后才明白客户360本质上不是前端工程而是数据集成工程。需要把分布在多个业务系统里、格式各异、更新节奏不同、甚至标识都不统一的数据拉到同一套存储模型里才能让页面有内容可画。我最早接手这类需求时犯过一个错先去设计页面原型和接口。结果等到要接数据才发现CRM里客户标识是手机号订单系统里是会员卡号埋点系统里是设备ID客服系统里又是另一个工单ID。四套ID对不上页面画得再漂亮也只能显示“本系统内信息不全”。从那以后我做这类项目的顺序变成了先盘点数据、再定义ID、最后才谈页面。这个顺序建议所有准备做客户360的团队都记一下它能帮你避开后面80%的返工。1.2 多源数据的典型构成以我这边做过的一个零售业务场景为例客户360的数据源通常包括下面这几类。每个来源的数据特性差别很大这直接决定了后面ETL和API的接入策略数据源主要内容更新节奏数据质量特征CRM客户主数据姓名、手机号、等级、归属销售分钟级/批量标识字段多样存在重复建档订单系统订单明细、金额、退款实时/近实时字段规范量大客服工单售后记录、投诉、满意度准实时自由文本多结构化差埋点行为浏览、点击、加购、停留时长秒级量极大、噪声多会员/卡券积分、余额、券准实时与订单系统关联复杂这些数据如果各自躺在原系统里单独查询都没有问题。客户360的难点在于“同时看到”当客户在5分钟内下了单、发了工单、又在App里浏览了一圈页面要在一个时间切片里把这些事情串起来。这就是多源数据集成最核心的挑战——不是处理某一类数据而是多类数据在时间维度和身份维度上的对齐。时间维度好办加个时间戳一排序就行身份维度才是真正要命的。1.3 为什么这类项目特别容易翻车我见过不少客户360项目做了一年还在“打通数据”阶段。总结下来翻车原因基本逃不过这四类第一身份体系没在项目早期锁定。各系统ID对不上是最致命的后期补起来成本极高。第二没有区分数据权威源。同一客户的手机号CRM里改了但订单系统还是旧的到底以谁为准没定义导致下游宽表数据忽闪忽闪。第三实时性目标定得不合理。业务说“要实时”技术就上全套Flink加Kafka结果很多数据根本不需要秒级纯属花钱买运维复杂度。第四团队分工割裂——ETL任务归数仓组、API接入归后端组各做各的出了问题互相甩锅。这四个坑我在后面几节都会对应讲怎么规避。先记住一个结论客户360项目的成败一半取决于技术选型另一半取决于定义清楚“数据从哪里来、谁负责、以谁为准”。2. ETL与API的边界划分两条腿走路最稳2.1 为什么不能指望单一技术通吃面对客户360这种场景很多团队会陷入两派之争一派主张全部走ETL批处理稳定、可控、可回溯另一派觉得既然要“实时”那就上流式计算全链路Flink。我的结论是单拎出来任何一派都做不好客户360。批处理独占的问题在于时效性天花板太低。T1能解决历史交易、基础资料这类不敏感的数据但客户当前正在看的商品、刚提交的售后工单批处理根本来不及。流式计算独占的问题在于成本和准确性纯流式要把所有历史数据重放一遍状态管理复杂数据延迟抖动时容易重复计算或丢数而且对团队要求高。所以我的做法是一句话ETL保底、API补位、实时按需分级。这个原则想必很多做数据架构的同学都认同但真正落到代码和调度上的时候能严格执行的并不多。2.2 用时效性分级来定“实时”的定义在推进这件事之前建议先和业务方对齐“实时”到底指什么。实操中我会把数据需求拆成三个时效等级T1或小时级客户基本资料、历史累计消费、等级权益。这类数据变化慢完全可以用ETL批量同步。分钟级准实时订单状态、工单进展、积分变动。通过ETL的增量调度或近实时管道同步。秒级实时当前行为轨迹、在线客服会话、资费额度校验。这类才走API拉取或事件推送。很多项目里真正需要秒级的场景其实只占20%。把这20%单独拎出来用API链路解决剩下80%交给ETL整体成本会低一个量级而且系统稳定性会好很多。我见过一上来就全员Flink的项目到最后连订单表对账都对不齐就是因为把不需要实时的东西也塞进了实时链路。2.3 ETL在哪些环节不可替代ETL最不可替代的能力是状态可重放。举个例子客户的累计消费金额计算错了批处理模式可以重跑一段时间的任务修正所有下游数据但实时流式链路一旦错了要回滚就非常痛苦还容易把正常数据也冲掉。此外批量任务天然适合处理大数据量的全量清洗比如对历史订单做维度补全、对客户资料做标准化这些不追求时效性的动作放在批量管道里最合适。所以在架构上我把ETL作为权威数据的主通道所有最终落在宽表里的核心字段都必须要有一条批处理链路来保证可追溯、可对账。API实时数据只是在这条主通道没覆盖到的时间窗口里做“补位”。这个设计思路也决定了后面ETL任务的质量标准要比API链路高得多——因为它是下游对账的基准线。2.4 API在哪些场景补位API链路的定位不是和ETL抢活而是覆盖ETL管不到的两类场景一是源系统根本不给数据库权限只开放接口那就只能靠API拉数二是时效性要求高、等不了批量窗口比如客户刚下单就要在360视图看到这时候就需要触发实时刷新。这里有个容易踩的误区以为用了API就代表“实时化”实际上API拉取如果设计成定时轮询它也是“批处理”只是粒度更细罢了。真正有价值的API集成是围绕事件驱动做的——源系统有新数据产生时通过回调或消息队列把变化推过来下游再触发宽表更新。判断一个API对接方案合不合理就看它是在“等时间到了去问”还是在“等事件来了被通知”。后者才是真正的实时补位。3. 从多源数据到OneID宽表ETL管道搭建的关键细节3.1 先把身份对齐OneID的落地做法客户360的根基是OneID也就是把不同系统里的客户标识统一成一个全局客户ID。OneID听起来很玄但落地时不用一开始就上复杂的图计算我建议先做规则优先级匹配优先用手机号加实名信息做强匹配匹配不上的用微信unionid或openid与设备ID做次强匹配还匹配不上的用会员卡号与订单联系人做弱匹配完全匹配不了的新生成一个OneID等待后续事件关联。实操中我会把这些规则固化成一张ID映射表结构大致包含one_id、source_system、source_id、id_type、match_rule、matched_at。每次ETL增量跑完先更新这张映射表再通过它来生成宽表。这样做的最大好处是即使某个匹配规则后期要调整也只需要回刷映射表而不是推倒所有下游数据。映射表一定要做成可回放的结构记录规则版本否则后期排查合并问题时你根本不知道某个ID当初是怎么对上的。3.2 客户宽表一张表承载核心360信息OneID映射表建好后下一步就是把各源数据汇聚到一张客户宽表。宽表的结构我会按业务域分块示例DDL如下CREATE TABLE customer_360 ( one_id String, -- 身份域 mobile String, union_id String, customer_name String, -- 交易域 total_order_cnt UInt32, total_order_amt Decimal(18,2), last_order_time DateTime, -- 行为域 last_visit_time DateTime, visit_cnt_7d UInt32, -- 服务域 open_ticket_cnt UInt32, last_ticket_time DateTime, -- 元信息 updated_at DateTime ) ENGINE ReplacingMergeTree(updated_at) ORDER BY one_id;注意几个细节主键是one_id事务类和指标类字段要设计成“可累加可替换”最后用一个updated_at字段做ReplacingMergeTree的版本控制保证并发更新不乱。这张宽表就是所有下游查询的唯一事实来源前端页面、实时服务、数据分析全部从这张表取数避免各查各库造成口径不一致。存储引擎我建议直接用ClickHouse或者StarRocks这类分析型数据库因为最终前端查询通常是“单用户维度加多指标”的组合宽表在这种引擎上的查询性能极好。别选纯粹的OLTP库客户量上来之后聚合查询会把小事务库拖死。如果是中小体量一台配置好一点的ClickHouse节点就能扛住几十万客户的360查询性价比很高。3.3 增量同步时间戳水位线还是CDCETL管道搭建时最关键的参数是增量策略。我这边常用两种时间戳水位线源表有create_time/update_time这类字段时可以记录上次同步的最大时间戳下次只拉取大于它的数据。优点是实现简单缺点是源系统删除数据或时间戳回退时会漏数据。CDC变更数据捕获适用于核心交易库比如MySQL的binlog通过Debezium解析后推入Kafka。它能把增删改全部捕获天然支持近乎实时的同步。缺点是部署成本高对源库版本有要求。对于客户360项目我的建议是“水位线做基础、CDC做核心库、API做兜底”。交易订单这种关键数据用CDC普通的配置型数据用时间戳水位线就够了。CDC的好处不仅在于实时更在于它能捕获“删除”和“更新前值”这在做客户合并、订单冲正时特别有用水位线机制基本做不到。提示如果你的源库允许CDC最好接在从库上解析别直接压主库否则业务高峰期会明显影响在线交易。我当时就因为直接接主库binlog被DBA紧急叫停过一次。3.4 数据质量校验不能等上线才做ETL管道跑起来之后必须有一套自动化的数据质量检查否则越到后面越不敢信数据。我常用的校验项包括主键唯一性校验、空值率监控比如手机号空值率超过阈值就是主数据同步出问题了、关键指标环比波动比如昨日订单量比前日跌了50%大概率是同步通道断了、宽表单行记录数监控。这些检查不用做得太复杂在ETL任务的每个阶段后加一个简单的CHECK任务就可以了。一旦校验失败宁可阻断下游更新也不要让脏数据流入前端页面。我曾经因为省掉这个环节导致全量回刷时把一批空值写入了线上宽表前端页面整整展示了半天“客户姓名为空”那次教训之后数据质量检查就写进了所有ETL任务的固定步骤。4. API实时补位拉取、限流、幂等与事件订阅4.1 先判断该用“拉”还是“推”API集成的第一步不是写代码而是确定交互模式。很多源系统对外提供的接口只支持拉取query不支持推送callback。这种情况下我通常封装一个“增量拉取器”每次调用时带上游标参数通常是start_time加end_time源系统返回这段窗口内变更的数据拉取器再写入Kafka或直接更新宽表。如果源系统支持Webhook推送或者提供了消息队列那就优先做事件订阅。以订单为例下单、支付、退款都会发出事件下游消费事件并更新宽表全程时效能压到秒级。前两年做实时特征服务时我就是靠这套推送机制把订单变更的可见延迟从分钟级压到了3秒以内。选“拉”还是“推”取决于源系统的能力不取决于你的偏好。提示无论拉取还是推送消息内容里一定要带event_id occurred_at这样的幂等键。下游消费时用幂等键去重否则网络重传或消息重放会导致指标重复累加。这是我给所有接API的团队的第一条规矩。4.2 API调用量与限流关心你的配额API集成翻车最常见的原因就是没算好调用量。假设你有50万客户行为事件每小时增量100万条如果直接按事件一条条调用接口调用量根本压不住。我这边给出的经验是能用批量接口绝不单条调能离线批量同步的别走在线接口。另外源系统的API基本都有限流策略比如每秒最多100次。代码里必须做令牌桶限速加指数退避重试。我在Java里就踩过很深的坑某个源系统限流返回429我原来的重试逻辑是等1秒重试结果同一批任务几百个线程同时重试直接把源系统打瘫还把对方运维惹毛了。正确策略是每次失败后按指数增长重试间隔1秒、2秒、4秒、8秒……封顶60秒最多重试3次超过就直接写入死信队列不无限重试重试期间带上请求ID方便事后追踪调用链。还有一点容易被忽略API调用量的配额要和源系统负责人事先对齐尤其是跨部门的数据源。你以为只是调个接口拿数据但对方可能把接口配额当成生产系统的核心资源在管不提前沟通上线第一天就会被限流到怀疑人生。4.3 API数据与ETL数据如何合并权威与实时的博弈API接入的数据通常时效性好但权威性弱ETL同步的数据权威性强但时效性差两者必须有一个清晰的合并规则否则同一个字段一会儿变旧一会儿变新前端会非常困惑。我的合并策略是按字段类型分开处理。客户姓名、手机号这类的“主数据字段”以ETL同步的CRM数据为准API的实时改动更新的是“最近活跃信息”订单金额这类“事实数据”谁先到谁先写用updated_at做最终覆盖行为类字段最近浏览时间、7日访问次数则完全以API实时数据为准因为它们本来就属于时效敏感数据。这样处理后业务看到的效果是客户360页面的核心资料稳定可靠实时行为鲜活及时两者不打架。如果你不做这种字段级分工最典型的问题就是客户在客服改了个手机号第二天ETL跑批又把旧手机号刷回来了页面数据来回横跳业务会对数据失去信任。4.4 用事件驱动替代定时轮询如果条件允许我强烈建议把API集成从“定时拉取”升级为“事件驱动”。以订单状态为例定时拉取最快能做到分钟级每1分钟跑一次增量拉取但事件驱动能做到秒级订单刚支付完360页面立即刷新。实操里我会在接入层加一个事件总线所有外部系统的事件统一投递到Kafka内部的宽表更新任务统一消费。这样做的好处是解耦新增一个数据源时只需把事件适配器对接好下游不用改。我后来把客户360升级成实时特征服务时靠的就是这条总线——底层的事件流没有变动直接加了新的消费端数据就开始往推荐和风控场景供了。如果你一开始就做点对点接口调用后面每加一个下游都要改一遍源系统对接逻辑成本翻着涨。5. 查询服务与实时推送让前端真正用起来5.1 宽表不等于接口查询服务的设计要点很多团队踩过这个坑宽表建好后直接把ClickHouse连接串发给前端让他们自己查。结果就是前端各种全表扫描SQL把查询节点打到报警。正确的做法是在宽表之上再封装一层查询服务提供RESTful API。查询服务要做几件事接口规范化比如GET /customer/{oneId}/360返回统一的JSON结构字段裁剪与脱敏手机号、地址等敏感字段根据角色控制返回客服和数据分析师看到的不一样指标聚合有些字段比如7日访问次数需要预聚合或按参数实时计算超时与限流给前端接口加熔断保护避免某个大客户刷接口把服务打挂。这个服务我一般用Java Spring Boot写内部直接查ClickHouse宽表配合缓存。接口层要做成独立部署的服务别跟ETL调度系统混在一起。有一次我图省事把查询接口挂在了ETL调度器旁边的服务里结果ETL重跑历史任务时把资源全部占满查询接口的响应时间从50毫秒涨到了8秒前端直接飘红这个教训挺深刻的。5.2 实时刷新WebSocket还是SSE客户360页面需要“实时感”这里有两个主流方向WebSocket和SSEServer-Sent Events。两者区别很明显WebSocket是双向全双工适合即时通讯、协同编辑这类“双方都要主动发”的场景SSE是单向Server to Client基于HTTP协议更简单自动重连、断线续传都天然支持。客户360这个场景状态变更基本是服务端向客户端推送前端很少需要反向发指令所以我实际选的是SSE。原因有三一是实现简单不需要维护长连接协议二是有自动重连机制前端省事三是能跑在现有HTTP基础设施上配合Nginx也很方便。SSE推送链路大致如下源系统事件 - Kafka - 宽表更新 - 查询服务收到变更消息 - SSE推送 - 前端刷新页面为了实时推送查询服务需要订阅一份“客户变更事件流”一旦某个oneId对应的宽表数据有更新就向这个用户对应的SSE连接推送一条消息前端拿到消息后再调查询接口拉取最新数据。这样既没有页面定时轮询的资源浪费又保证了数据是新鲜的。5.3 缓存与热点处理别让宽表扛所有流量客户360页面的访问模式有很强的热点性——客服查看、销售跟进、运营分析总是集中在少部分活跃客户上。全部去ClickHouse查宽表压力还是不小的。我会在查询服务和宽表之间加两层缓存Redis热点缓存按one_id缓存最近1-2分钟的完整响应命中后直接返回进程内短缓存查询服务本地放一个5秒的二级缓存扛住突发尖峰。缓存的失效策略要小心SSE推送说“数据变了”这时需要主动失效对应key而不是等过期。我在缓存KEY里加了版本号每次宽表更新时递增查询时带上版本号比较不一致就回源。这套机制跑下来ClickHouse的QPS压力降了大概70%页面响应时间也稳定在200毫秒内。做数据服务的人应该记住一个原则缓存不是用来省钱的是用来保命的——流量的毛刺和查询热点来了全靠它挡第一波。6. 踩坑实录这套架构在真实环境会遇到什么6.1 时间戳回退带来的数据幽灵最让我头疼的一个坑某个源系统和宽表做时间戳增量同步结果源系统做了一次数据订正把一批老订单的更新时间倒退了。我这里的水位线已经往前推进所以这批订正数据永远不会被增量任务拉到宽表里的数据就成了“永久错误”。后来我意识到时间戳增量同步只能信任单调递增的字段。对于不可靠的时间戳一是尽量用CDC二是每周做一次全量对账——拿宽表和源系统做总量和关键字段抽样比对把差异找出来回刷。这对客户360这种重准确性的场景是不可省的。别嫌麻烦对账脚本写一次后面能救你无数次。6.2 ID映射冲突同一个客户被合并错了OneID匹配不是100%准确的。我遇到过两个真实客户手机号刚好用了同一个家庭号码规则匹配后合并成一个OneID导致客户360视图里把两人的订单、工单全混在一起了。这个问题直到客户投诉之后才暴露。现在的做法是ID映射表里增加人工审核队列和灰度合并机制。机器匹配产生冲突时不直接合并而是先进入疑似合并列表由业务方在后台确认。宁可暂时拆开显示两个客户也不要贸然合并伤害数据准确性。这个教训让我深刻体会到OneID这种影响范围巨大的数据治理规则不能全交给算法自动跑。数据工程师要做的不是“让算法更智能”而是“把判断和修正的路径留出来”。6.3 宽表越建越宽字段爆炸式增长客户360宽表刚开始只有30个字段半年后长到了200多个。业务方每次有新需求就往里加字段宽表越来越宽ClickHouse查询性能开始下滑ETL任务也越来越慢。后来立了个规矩宽表只保留“页面要展示的核心指标”和“下游高频查询字段”低频分析指标拆到独立的明细表中按需join。这样做之后宽表从200多个字段砍回80个左右查询性能恢复。给所有做数据集成的人一个建议宽表是一种取舍不是垃圾桶。每加一个字段都要问清楚这个字段被谁查、多久查一次、能不能用明细表join替代。回答不上来的不加。6.4 演进方向从360视图到实时特征服务客户360做完后它的业务价值往往不止于一个展示页面。后续可以往两个方向演进一是把宽表里的客户画像字段标准成实时特征服务供推荐、营销、风控等下游调用这时查询服务就需要从“页面接口”升级成“特征服务API”提供批量获取、订阅推送等能力二是把数据配成自助分析的数据集让业务同学能自己拉取分析客户群体。从我的实际经验看客户360这类项目最大的难点永远不在技术栈本身而在于对数据现状的敬畏先盘点、后对齐、再建模一步都急不得。尤其别为了追“实时”这个时髦词把架构整得一上来就是全链路流式结果数据质量没人管、身份Mapping没人维护。技术方案越简单越好——能把80%的需求用ETL解决就用ETL剩下的20%再上API和流式计算。我做了几个客户360、实时特征相关的项目之后最深的一点体会是实时不是目的让业务在正确的时机拿到准确的数据才是目的。后续如果你们也在做类似的事情建议先把数据源和ID体系盘清楚再考虑用什么框架这条顺序踩一次就知道有多重要了。
基于ETL与API的多源数据集成实战：构建客户360视图
做数据集成这几年被业务部门追着问最多的需求之一就是“客户360”。听起来简单打开一个页面这个客户是谁、买过什么、有没有售后、最近在干嘛全都能看到。可真动手做的人都知道页面只是最后一层皮底下的骨头是数据能不能在同一个时间点、以同一个ID、把散落在五六个系统里的信息拼到一起。今天这篇我就把这套“基于ETL与API的多源数据集成”方案完整拆一遍——从客户360的数据盘点、ETL管道设计、API实时接入到最终查询服务与实时刷新全程都是实际跑过的工程路径。适合正在做客户数据平台、会员中台或数据服务化的数据工程师和后端开发参考。1. “客户360”的真相一个页面背后的数据治理工程1.1 业务方的“一个页面”和技术侧的隐性工作量业务方描述需求往往很轻巧他们眼里这是一个“页面”。真正接手后才明白客户360本质上不是前端工程而是数据集成工程。需要把分布在多个业务系统里、格式各异、更新节奏不同、甚至标识都不统一的数据拉到同一套存储模型里才能让页面有内容可画。我最早接手这类需求时犯过一个错先去设计页面原型和接口。结果等到要接数据才发现CRM里客户标识是手机号订单系统里是会员卡号埋点系统里是设备ID客服系统里又是另一个工单ID。四套ID对不上页面画得再漂亮也只能显示“本系统内信息不全”。从那以后我做这类项目的顺序变成了先盘点数据、再定义ID、最后才谈页面。这个顺序建议所有准备做客户360的团队都记一下它能帮你避开后面80%的返工。1.2 多源数据的典型构成以我这边做过的一个零售业务场景为例客户360的数据源通常包括下面这几类。每个来源的数据特性差别很大这直接决定了后面ETL和API的接入策略数据源主要内容更新节奏数据质量特征CRM客户主数据姓名、手机号、等级、归属销售分钟级/批量标识字段多样存在重复建档订单系统订单明细、金额、退款实时/近实时字段规范量大客服工单售后记录、投诉、满意度准实时自由文本多结构化差埋点行为浏览、点击、加购、停留时长秒级量极大、噪声多会员/卡券积分、余额、券准实时与订单系统关联复杂这些数据如果各自躺在原系统里单独查询都没有问题。客户360的难点在于“同时看到”当客户在5分钟内下了单、发了工单、又在App里浏览了一圈页面要在一个时间切片里把这些事情串起来。这就是多源数据集成最核心的挑战——不是处理某一类数据而是多类数据在时间维度和身份维度上的对齐。时间维度好办加个时间戳一排序就行身份维度才是真正要命的。1.3 为什么这类项目特别容易翻车我见过不少客户360项目做了一年还在“打通数据”阶段。总结下来翻车原因基本逃不过这四类第一身份体系没在项目早期锁定。各系统ID对不上是最致命的后期补起来成本极高。第二没有区分数据权威源。同一客户的手机号CRM里改了但订单系统还是旧的到底以谁为准没定义导致下游宽表数据忽闪忽闪。第三实时性目标定得不合理。业务说“要实时”技术就上全套Flink加Kafka结果很多数据根本不需要秒级纯属花钱买运维复杂度。第四团队分工割裂——ETL任务归数仓组、API接入归后端组各做各的出了问题互相甩锅。这四个坑我在后面几节都会对应讲怎么规避。先记住一个结论客户360项目的成败一半取决于技术选型另一半取决于定义清楚“数据从哪里来、谁负责、以谁为准”。2. ETL与API的边界划分两条腿走路最稳2.1 为什么不能指望单一技术通吃面对客户360这种场景很多团队会陷入两派之争一派主张全部走ETL批处理稳定、可控、可回溯另一派觉得既然要“实时”那就上流式计算全链路Flink。我的结论是单拎出来任何一派都做不好客户360。批处理独占的问题在于时效性天花板太低。T1能解决历史交易、基础资料这类不敏感的数据但客户当前正在看的商品、刚提交的售后工单批处理根本来不及。流式计算独占的问题在于成本和准确性纯流式要把所有历史数据重放一遍状态管理复杂数据延迟抖动时容易重复计算或丢数而且对团队要求高。所以我的做法是一句话ETL保底、API补位、实时按需分级。这个原则想必很多做数据架构的同学都认同但真正落到代码和调度上的时候能严格执行的并不多。2.2 用时效性分级来定“实时”的定义在推进这件事之前建议先和业务方对齐“实时”到底指什么。实操中我会把数据需求拆成三个时效等级T1或小时级客户基本资料、历史累计消费、等级权益。这类数据变化慢完全可以用ETL批量同步。分钟级准实时订单状态、工单进展、积分变动。通过ETL的增量调度或近实时管道同步。秒级实时当前行为轨迹、在线客服会话、资费额度校验。这类才走API拉取或事件推送。很多项目里真正需要秒级的场景其实只占20%。把这20%单独拎出来用API链路解决剩下80%交给ETL整体成本会低一个量级而且系统稳定性会好很多。我见过一上来就全员Flink的项目到最后连订单表对账都对不齐就是因为把不需要实时的东西也塞进了实时链路。2.3 ETL在哪些环节不可替代ETL最不可替代的能力是状态可重放。举个例子客户的累计消费金额计算错了批处理模式可以重跑一段时间的任务修正所有下游数据但实时流式链路一旦错了要回滚就非常痛苦还容易把正常数据也冲掉。此外批量任务天然适合处理大数据量的全量清洗比如对历史订单做维度补全、对客户资料做标准化这些不追求时效性的动作放在批量管道里最合适。所以在架构上我把ETL作为权威数据的主通道所有最终落在宽表里的核心字段都必须要有一条批处理链路来保证可追溯、可对账。API实时数据只是在这条主通道没覆盖到的时间窗口里做“补位”。这个设计思路也决定了后面ETL任务的质量标准要比API链路高得多——因为它是下游对账的基准线。2.4 API在哪些场景补位API链路的定位不是和ETL抢活而是覆盖ETL管不到的两类场景一是源系统根本不给数据库权限只开放接口那就只能靠API拉数二是时效性要求高、等不了批量窗口比如客户刚下单就要在360视图看到这时候就需要触发实时刷新。这里有个容易踩的误区以为用了API就代表“实时化”实际上API拉取如果设计成定时轮询它也是“批处理”只是粒度更细罢了。真正有价值的API集成是围绕事件驱动做的——源系统有新数据产生时通过回调或消息队列把变化推过来下游再触发宽表更新。判断一个API对接方案合不合理就看它是在“等时间到了去问”还是在“等事件来了被通知”。后者才是真正的实时补位。3. 从多源数据到OneID宽表ETL管道搭建的关键细节3.1 先把身份对齐OneID的落地做法客户360的根基是OneID也就是把不同系统里的客户标识统一成一个全局客户ID。OneID听起来很玄但落地时不用一开始就上复杂的图计算我建议先做规则优先级匹配优先用手机号加实名信息做强匹配匹配不上的用微信unionid或openid与设备ID做次强匹配还匹配不上的用会员卡号与订单联系人做弱匹配完全匹配不了的新生成一个OneID等待后续事件关联。实操中我会把这些规则固化成一张ID映射表结构大致包含one_id、source_system、source_id、id_type、match_rule、matched_at。每次ETL增量跑完先更新这张映射表再通过它来生成宽表。这样做的最大好处是即使某个匹配规则后期要调整也只需要回刷映射表而不是推倒所有下游数据。映射表一定要做成可回放的结构记录规则版本否则后期排查合并问题时你根本不知道某个ID当初是怎么对上的。3.2 客户宽表一张表承载核心360信息OneID映射表建好后下一步就是把各源数据汇聚到一张客户宽表。宽表的结构我会按业务域分块示例DDL如下CREATE TABLE customer_360 ( one_id String, -- 身份域 mobile String, union_id String, customer_name String, -- 交易域 total_order_cnt UInt32, total_order_amt Decimal(18,2), last_order_time DateTime, -- 行为域 last_visit_time DateTime, visit_cnt_7d UInt32, -- 服务域 open_ticket_cnt UInt32, last_ticket_time DateTime, -- 元信息 updated_at DateTime ) ENGINE ReplacingMergeTree(updated_at) ORDER BY one_id;注意几个细节主键是one_id事务类和指标类字段要设计成“可累加可替换”最后用一个updated_at字段做ReplacingMergeTree的版本控制保证并发更新不乱。这张宽表就是所有下游查询的唯一事实来源前端页面、实时服务、数据分析全部从这张表取数避免各查各库造成口径不一致。存储引擎我建议直接用ClickHouse或者StarRocks这类分析型数据库因为最终前端查询通常是“单用户维度加多指标”的组合宽表在这种引擎上的查询性能极好。别选纯粹的OLTP库客户量上来之后聚合查询会把小事务库拖死。如果是中小体量一台配置好一点的ClickHouse节点就能扛住几十万客户的360查询性价比很高。3.3 增量同步时间戳水位线还是CDCETL管道搭建时最关键的参数是增量策略。我这边常用两种时间戳水位线源表有create_time/update_time这类字段时可以记录上次同步的最大时间戳下次只拉取大于它的数据。优点是实现简单缺点是源系统删除数据或时间戳回退时会漏数据。CDC变更数据捕获适用于核心交易库比如MySQL的binlog通过Debezium解析后推入Kafka。它能把增删改全部捕获天然支持近乎实时的同步。缺点是部署成本高对源库版本有要求。对于客户360项目我的建议是“水位线做基础、CDC做核心库、API做兜底”。交易订单这种关键数据用CDC普通的配置型数据用时间戳水位线就够了。CDC的好处不仅在于实时更在于它能捕获“删除”和“更新前值”这在做客户合并、订单冲正时特别有用水位线机制基本做不到。提示如果你的源库允许CDC最好接在从库上解析别直接压主库否则业务高峰期会明显影响在线交易。我当时就因为直接接主库binlog被DBA紧急叫停过一次。3.4 数据质量校验不能等上线才做ETL管道跑起来之后必须有一套自动化的数据质量检查否则越到后面越不敢信数据。我常用的校验项包括主键唯一性校验、空值率监控比如手机号空值率超过阈值就是主数据同步出问题了、关键指标环比波动比如昨日订单量比前日跌了50%大概率是同步通道断了、宽表单行记录数监控。这些检查不用做得太复杂在ETL任务的每个阶段后加一个简单的CHECK任务就可以了。一旦校验失败宁可阻断下游更新也不要让脏数据流入前端页面。我曾经因为省掉这个环节导致全量回刷时把一批空值写入了线上宽表前端页面整整展示了半天“客户姓名为空”那次教训之后数据质量检查就写进了所有ETL任务的固定步骤。4. API实时补位拉取、限流、幂等与事件订阅4.1 先判断该用“拉”还是“推”API集成的第一步不是写代码而是确定交互模式。很多源系统对外提供的接口只支持拉取query不支持推送callback。这种情况下我通常封装一个“增量拉取器”每次调用时带上游标参数通常是start_time加end_time源系统返回这段窗口内变更的数据拉取器再写入Kafka或直接更新宽表。如果源系统支持Webhook推送或者提供了消息队列那就优先做事件订阅。以订单为例下单、支付、退款都会发出事件下游消费事件并更新宽表全程时效能压到秒级。前两年做实时特征服务时我就是靠这套推送机制把订单变更的可见延迟从分钟级压到了3秒以内。选“拉”还是“推”取决于源系统的能力不取决于你的偏好。提示无论拉取还是推送消息内容里一定要带event_id occurred_at这样的幂等键。下游消费时用幂等键去重否则网络重传或消息重放会导致指标重复累加。这是我给所有接API的团队的第一条规矩。4.2 API调用量与限流关心你的配额API集成翻车最常见的原因就是没算好调用量。假设你有50万客户行为事件每小时增量100万条如果直接按事件一条条调用接口调用量根本压不住。我这边给出的经验是能用批量接口绝不单条调能离线批量同步的别走在线接口。另外源系统的API基本都有限流策略比如每秒最多100次。代码里必须做令牌桶限速加指数退避重试。我在Java里就踩过很深的坑某个源系统限流返回429我原来的重试逻辑是等1秒重试结果同一批任务几百个线程同时重试直接把源系统打瘫还把对方运维惹毛了。正确策略是每次失败后按指数增长重试间隔1秒、2秒、4秒、8秒……封顶60秒最多重试3次超过就直接写入死信队列不无限重试重试期间带上请求ID方便事后追踪调用链。还有一点容易被忽略API调用量的配额要和源系统负责人事先对齐尤其是跨部门的数据源。你以为只是调个接口拿数据但对方可能把接口配额当成生产系统的核心资源在管不提前沟通上线第一天就会被限流到怀疑人生。4.3 API数据与ETL数据如何合并权威与实时的博弈API接入的数据通常时效性好但权威性弱ETL同步的数据权威性强但时效性差两者必须有一个清晰的合并规则否则同一个字段一会儿变旧一会儿变新前端会非常困惑。我的合并策略是按字段类型分开处理。客户姓名、手机号这类的“主数据字段”以ETL同步的CRM数据为准API的实时改动更新的是“最近活跃信息”订单金额这类“事实数据”谁先到谁先写用updated_at做最终覆盖行为类字段最近浏览时间、7日访问次数则完全以API实时数据为准因为它们本来就属于时效敏感数据。这样处理后业务看到的效果是客户360页面的核心资料稳定可靠实时行为鲜活及时两者不打架。如果你不做这种字段级分工最典型的问题就是客户在客服改了个手机号第二天ETL跑批又把旧手机号刷回来了页面数据来回横跳业务会对数据失去信任。4.4 用事件驱动替代定时轮询如果条件允许我强烈建议把API集成从“定时拉取”升级为“事件驱动”。以订单状态为例定时拉取最快能做到分钟级每1分钟跑一次增量拉取但事件驱动能做到秒级订单刚支付完360页面立即刷新。实操里我会在接入层加一个事件总线所有外部系统的事件统一投递到Kafka内部的宽表更新任务统一消费。这样做的好处是解耦新增一个数据源时只需把事件适配器对接好下游不用改。我后来把客户360升级成实时特征服务时靠的就是这条总线——底层的事件流没有变动直接加了新的消费端数据就开始往推荐和风控场景供了。如果你一开始就做点对点接口调用后面每加一个下游都要改一遍源系统对接逻辑成本翻着涨。5. 查询服务与实时推送让前端真正用起来5.1 宽表不等于接口查询服务的设计要点很多团队踩过这个坑宽表建好后直接把ClickHouse连接串发给前端让他们自己查。结果就是前端各种全表扫描SQL把查询节点打到报警。正确的做法是在宽表之上再封装一层查询服务提供RESTful API。查询服务要做几件事接口规范化比如GET /customer/{oneId}/360返回统一的JSON结构字段裁剪与脱敏手机号、地址等敏感字段根据角色控制返回客服和数据分析师看到的不一样指标聚合有些字段比如7日访问次数需要预聚合或按参数实时计算超时与限流给前端接口加熔断保护避免某个大客户刷接口把服务打挂。这个服务我一般用Java Spring Boot写内部直接查ClickHouse宽表配合缓存。接口层要做成独立部署的服务别跟ETL调度系统混在一起。有一次我图省事把查询接口挂在了ETL调度器旁边的服务里结果ETL重跑历史任务时把资源全部占满查询接口的响应时间从50毫秒涨到了8秒前端直接飘红这个教训挺深刻的。5.2 实时刷新WebSocket还是SSE客户360页面需要“实时感”这里有两个主流方向WebSocket和SSEServer-Sent Events。两者区别很明显WebSocket是双向全双工适合即时通讯、协同编辑这类“双方都要主动发”的场景SSE是单向Server to Client基于HTTP协议更简单自动重连、断线续传都天然支持。客户360这个场景状态变更基本是服务端向客户端推送前端很少需要反向发指令所以我实际选的是SSE。原因有三一是实现简单不需要维护长连接协议二是有自动重连机制前端省事三是能跑在现有HTTP基础设施上配合Nginx也很方便。SSE推送链路大致如下源系统事件 - Kafka - 宽表更新 - 查询服务收到变更消息 - SSE推送 - 前端刷新页面为了实时推送查询服务需要订阅一份“客户变更事件流”一旦某个oneId对应的宽表数据有更新就向这个用户对应的SSE连接推送一条消息前端拿到消息后再调查询接口拉取最新数据。这样既没有页面定时轮询的资源浪费又保证了数据是新鲜的。5.3 缓存与热点处理别让宽表扛所有流量客户360页面的访问模式有很强的热点性——客服查看、销售跟进、运营分析总是集中在少部分活跃客户上。全部去ClickHouse查宽表压力还是不小的。我会在查询服务和宽表之间加两层缓存Redis热点缓存按one_id缓存最近1-2分钟的完整响应命中后直接返回进程内短缓存查询服务本地放一个5秒的二级缓存扛住突发尖峰。缓存的失效策略要小心SSE推送说“数据变了”这时需要主动失效对应key而不是等过期。我在缓存KEY里加了版本号每次宽表更新时递增查询时带上版本号比较不一致就回源。这套机制跑下来ClickHouse的QPS压力降了大概70%页面响应时间也稳定在200毫秒内。做数据服务的人应该记住一个原则缓存不是用来省钱的是用来保命的——流量的毛刺和查询热点来了全靠它挡第一波。6. 踩坑实录这套架构在真实环境会遇到什么6.1 时间戳回退带来的数据幽灵最让我头疼的一个坑某个源系统和宽表做时间戳增量同步结果源系统做了一次数据订正把一批老订单的更新时间倒退了。我这里的水位线已经往前推进所以这批订正数据永远不会被增量任务拉到宽表里的数据就成了“永久错误”。后来我意识到时间戳增量同步只能信任单调递增的字段。对于不可靠的时间戳一是尽量用CDC二是每周做一次全量对账——拿宽表和源系统做总量和关键字段抽样比对把差异找出来回刷。这对客户360这种重准确性的场景是不可省的。别嫌麻烦对账脚本写一次后面能救你无数次。6.2 ID映射冲突同一个客户被合并错了OneID匹配不是100%准确的。我遇到过两个真实客户手机号刚好用了同一个家庭号码规则匹配后合并成一个OneID导致客户360视图里把两人的订单、工单全混在一起了。这个问题直到客户投诉之后才暴露。现在的做法是ID映射表里增加人工审核队列和灰度合并机制。机器匹配产生冲突时不直接合并而是先进入疑似合并列表由业务方在后台确认。宁可暂时拆开显示两个客户也不要贸然合并伤害数据准确性。这个教训让我深刻体会到OneID这种影响范围巨大的数据治理规则不能全交给算法自动跑。数据工程师要做的不是“让算法更智能”而是“把判断和修正的路径留出来”。6.3 宽表越建越宽字段爆炸式增长客户360宽表刚开始只有30个字段半年后长到了200多个。业务方每次有新需求就往里加字段宽表越来越宽ClickHouse查询性能开始下滑ETL任务也越来越慢。后来立了个规矩宽表只保留“页面要展示的核心指标”和“下游高频查询字段”低频分析指标拆到独立的明细表中按需join。这样做之后宽表从200多个字段砍回80个左右查询性能恢复。给所有做数据集成的人一个建议宽表是一种取舍不是垃圾桶。每加一个字段都要问清楚这个字段被谁查、多久查一次、能不能用明细表join替代。回答不上来的不加。6.4 演进方向从360视图到实时特征服务客户360做完后它的业务价值往往不止于一个展示页面。后续可以往两个方向演进一是把宽表里的客户画像字段标准成实时特征服务供推荐、营销、风控等下游调用这时查询服务就需要从“页面接口”升级成“特征服务API”提供批量获取、订阅推送等能力二是把数据配成自助分析的数据集让业务同学能自己拉取分析客户群体。从我的实际经验看客户360这类项目最大的难点永远不在技术栈本身而在于对数据现状的敬畏先盘点、后对齐、再建模一步都急不得。尤其别为了追“实时”这个时髦词把架构整得一上来就是全链路流式结果数据质量没人管、身份Mapping没人维护。技术方案越简单越好——能把80%的需求用ETL解决就用ETL剩下的20%再上API和流式计算。我做了几个客户360、实时特征相关的项目之后最深的一点体会是实时不是目的让业务在正确的时机拿到准确的数据才是目的。后续如果你们也在做类似的事情建议先把数据源和ID体系盘清楚再考虑用什么框架这条顺序踩一次就知道有多重要了。
