1. 项目代号背后的需求博弈1.1 “rea”到底是什么拿到“rea”这个项目代号的时候团队里开了个短暂的碰头会。三个字母没有任何上下文第一反应是“read”少了字母第二反应是有人拼错了React第三反应是某个框架里的术语缩写。这种模糊感其实挺常见的很多项目在立项阶段都只有一个代号后面的一切全靠推导。我当时做了一件事列了一个“可能的含义清单”。比如rea Realtime Experience Analytics实时体验分析rea Resource Exploration API资源探测接口rea Read/Evaluate/Act读-评估-执行某种决策循环rea 某个内部系统的缩写连命名人都忘了原意这种清单看起来很笨但非常有效。因为它逼着每个参与者把自己的预期放到台面上而不是各自抱着一个理解去做开发。讨论之后我们发现真正能让团队共振、也有商业价值的是Realtime Experience Analytics这条线——一套面向Web应用的用户体验实时监控系统。为什么选它因为当时团队已经有一套定时统计报表每天凌晨跑批第二天早上看数据。但业务方提了个很尖锐的问题昨天下午线上活动页面卡了为什么今天早上才告诉我们这个问题暴露的不只是技术债而是整个监控体系的时效性缺陷。所以“实时”这个属性就成了项目的核心锚点而“体验分析”则是业务价值的落点。1.2 从模糊到清晰锁定核心用户与场景项目代号确定方向后下一步就是定义“给谁用、解决什么问题”。这部分我踩过不少坑早期做数据类项目时习惯先聊技术再聊场景结果做出来的东西像个技术demo业务方根本用不上。这次我们把场景摆在了最前面。核心用户是三类人前端研发想知道页面加载慢是网络问题、接口问题还是渲染问题后端研发想知道某个接口在某段时间内是否成为瓶颈运营/产品想知道用户是否真的完成了关键转化动作流失点在哪围绕这三类用户我们抽象出几个必做的能力采集页面性能指标首屏时间、DOM就绪、接口耗时采集用户行为链路点击、停留、跳转、提交实时聚合与告警某个指标超过阈值立刻通知事后回溯按用户会话查看完整操作序列这个“用户-场景-能力”的三角拆解是后续所有技术决策的出发点。说白了技术选型不是看哪个框架流行而是看谁能在最短时间内稳定支撑这三块。后来我们砍掉了很多“锦上添花”的需求比如复杂的漏斗分析、用户分群画像因为那些会显著拉长项目周期而且初期大家根本用不上。2. 技术选型一套能支撑实时的管道2.1 为什么是“前端埋点 消息队列 OLAP存储”三段式实时体验分析类的系统业界常见的做法是分段处理采集端负责数据产生与初步加工传输层负责缓冲与削峰存储与计算层负责聚合和查询。我们最终选定的链路是前端SDK → 网关 → 消息队列 → 消费与清洗 → 实时聚合/OLAP存储 → 查询API与看板。这个三段式结构解决了三个核心问题解耦采集与消费。前端产生的事件量是脉冲式的白天活动期间可能每秒上万条凌晨可能只有几十条。如果采集端直连数据库要么数据库扛不住高峰要么闲时资源浪费。中间加一层消息队列天然起到了削峰填谷的作用。让实时和离线并存。同一份数据进入消息队列后可以同时被实时链路和离线链路消费不用维护两套采集逻辑。容错与重放。数据管道上游挂了消息队列里积压的数据不会丢恢复后可以继续消费这是直接写入数据库无法天然实现的。2.2 关键组件的选型和参数心得这里逐个说说每个环节的具体选型思路。先说前端SDK我们选择了自研一个轻量级的SDK而不是直接嵌入第三方商业方案。原因很简单数据主权和灵活性。我们需要采集特定的业务事件比如用户点击了某个业务模块并且要把SDK的体积控制在很小的范围内第三方方案很难同时满足这两点。后端语言选了Java和Spring Boot不是因为它最“潮”而是团队存量技术栈就是这组上手快、排查问题资料多。模块间通信用了Spring的异步事件机制跨进程的部分依赖消息队列。消息队列选了Kafka。选型对比时也看过RocketMQ等方案最终因为Kafka吞吐高、生态成熟、消费模型灵活而定。容量规划上我们做了一个粗略估算假设日均5000万事件峰值是均值的5倍单事件平均1KB那么峰值每秒约3000条消息Kafka集群三节点足够。这个估算在后面性能测试中验证过基本准确。OLAP存储我们选了ClickHouse。这个选择是经过两类方案对比后的结果一类是传统MySQL分库分表一类是ClickHouse。MySQL对于这种带有大量维度字段、需要秒级聚合的查询场景即使分了库表查询性能和扩展性也会随着数据量增长迅速恶化。ClickHouse的列式存储和向量化执行在处理这种分析型查询上有数量级的优势。当然代价是我们得为它配套独立的冷热备份机制这个后面会讲到。环节选型核心考量数据采集自研轻量JS SDK体积可控、事件自定义、采样率可控异步缓冲Kafka高吞吐、可重放、多消费者清洗加工Java/Spring Boot消费者组与团队技术栈一致、生态完善存储ClickHouse列式存储支持秒级聚合查询与看板Spring Boot API Web快速搭建、灵活定制3. 核心模块的实操实现3.1 前端埋点SDK的设计与实现SDK设计的第一原则是“不要阻碍主业务”。这意味着脚本必须异步加载不能同步阻塞页面渲染上报必须走SendBeacon或图片请求这类不干扰主线程的方式所有内部错误必须捕获并静默处理绝不能让埋点代码的异常暴露到用户控制台。我们实现了几种常见的采集项。性能指标用浏览器的PerformanceTiming和PerformanceObserver事件监听用原生addEventListener会话标识用cookie或者localStorage存储一个UUID每次页面加载生成新的会话ID。一个比较关键的细节是采样率控制。全量埋点数据量太大而且很多用户的行为特征高度相似所以我们对普通访问做了动态采样默认50%采样率当某个页面流量突然增大时自动降低采样率到10%。这个逻辑放在SDK内部后端通过配置接口下发切流量非常方便。SDK的代码结构大致是这样的思路// sdk核心入口收集数据后统一走report管道 class ReaSDK { constructor(config) { this.config Object.assign({ endpoint: , sampleRate: 0.5 }, config); this.sessionId this.getSessionId(); this.bindEvents(); } bindEvents() { // 监听点击、错误、性能等事件 window.addEventListener(click, this.handleClick.bind(this), true); window.addEventListener(error, this.handleError.bind(this), true); } handleClick(e) { if (Math.random() this.config.sampleRate) return; const payload { type: click, sessionId: this.sessionId, path: location.pathname, target: e.target ? e.target.tagName : , timestamp: Date.now() }; this.report(payload); } report(data) { const blob new Blob([JSON.stringify(data)], { type: application/json }); navigator.sendBeacon navigator.sendBeacon(this.config.endpoint, blob); } }实操中注意几个点事件监听建议用捕获阶段而不是冒泡阶段因为捕获阶段能更早拿到事件且不会被业务侧的stopPropagation拦截上报数据要做数组批量打包前端攒够10条或2秒时间窗口再发一次能显著减少请求量。3.2 后端数据接入与聚合的方案后端主要分两个部分数据接入和实时聚合。数据接入层负责接收SDK上报的HTTP请求做基本的格式校验、字段补全、内容过滤然后写入Kafka。这一步设计得尽量简单避免复杂的业务逻辑目的只有一个高并发写入时不丢不重不阻塞。实时聚合这一层我们用了两种路径。路径一是流式聚合消费Kafka后直接做窗口计算比如每分钟计算一次某个页面的平均加载耗时结果写入Redis或ClickHouse的汇总表供看板查询路径二是明细存储原始事件全量写入ClickHouse明细表用于事后下钻分析。两条路径并行互不干扰。流式聚合这块我们用了一个比较朴素的方案消费者线程在内存中维护一个ConcurrentHashMap作为窗口计数器窗口大小定为10秒每个窗口结束后把计数结果批量写入聚合表。用10秒这个值的考量是窗口太大指标的实时性打折窗口太小状态管理和持久化成本高。实际运行下来10秒窗口在实时性和开销之间取得了不错的平衡。聚合写入ClickHouse时为了避免高频小批量写入引发Too many parts的问题我们攒批到5000条或5秒才提交一次。这两个参数可以直接写在ClickHouse的异步插入配置里也可以由应用层控制。我们选择了应用层控制因为这样能更灵活地调节批量大小和吞吐量。数据接入流程前端SDK以JSON格式批量POST到/collect接口网关层做Basic Auth校验和限流每IP每秒100次接入服务校验字段完整性补齐客户端IP、UserAgent、服务端时间数据序列化后发送到Kafka的rea-events-topic话题消费者组实时消费一路走聚合写Redis一路原样写ClickHouse这套流程上线后高峰期每秒能够稳定处理5000条数据P99延迟在120ms以内。支撑这个吞吐量的关键在于每个环节都做了解耦任何一环的抖动都不会直接拖垮整体的采集链路。4. 数据可靠性建设从“丢数据”到“可追责”4.1 消费幂等与数据补偿机制消息队列用久了大家都会遇到一个经典问题Consumer挂了重启或者上游重复发送数据到底会不会丢会不会重复Kafka的At Least Once语义保证的是“至少一次”也就是说它不保证“正好一次”在极端场景下重复消费是可能的。我们在线上的确踩到过一次重复数据导致计数翻倍的故障。排查了半天发现是消费者在处理过程中抛了一个异常Kafka把消息重新入队而我们的聚合逻辑没有做去重判断于是同一批点击事件被统计了两次。解决的方法是幂等写入。ClickHouse有一个ReplacingMergeTree引擎它允许指定一个版本列相同排序键下只保留版本最大的那条记录。我们把事件ID作为排序键消费时间戳作为版本号这样即使同一事件被消费两次存储层也会自动去重。但这并不是治本的办法。我后来在代码规范里加了一条消费者必须在下游写入前生成一个全局唯一的事件唯一标识并且把去重逻辑同时放在应用层和存储层两道防线中。应用层维护一个最近处理过的布隆过滤器命中则跳过存储层用合并树兜底。双保险之后这个类问题基本绝迹。4.2 延迟与乱序数据的处理策略实时系统的另一个隐形杀手是数据乱序。前端SDK上报的数据在网络拥塞时可能出现乱序到达比如点在先的数据因为网关重试结果后到。直接按时间戳排序会得到错误的结果。一种简单的思路是采用“事件时间”而不是“到达时间”。每条数据在SDK端就打上客户端时间戳后端所有聚合计算都以这个时间为准。但客户端时间有可能因为用户本机时间设置错误而偏差因此在接入层我们会额外记录服务端收到时间两个时间差超过5分钟的记录直接标记异常并降级处理。另一个必须应对的场景是延迟数据。消费者从Kafka读取到一条迟到超过窗口边界的数据时正常窗口计算早就结束了直接把数据丢弃会丢失有效信息。我们的方案是用延迟缓冲队列加补偿任务延迟数据先打入一个侧输出流落到ClickHouse延迟表然后一个定时任务每隔10分钟扫描延迟表发现窗口尚未关闭的把数据补算进对应的汇总指标里。虽然补算的指标晚了一些但数据是完整的看板展示时标记为“修正后数据”避免误导用户。数据可靠性速查问题表现我们的应对重复消费指标翻倍、计数膨胀应用层布隆过滤器 存储层ReplacingMergeTree数据丢失窗口指标断层Kafka保留时间延长至7天消费位点可回退乱序到达转化链路错乱、漏斗不准以客户端事件时间为准网关时间辅助校验延迟过高看板指标滞后延迟补偿任务 修正后数据标记这套机制上线后再也没有发生过“数据对不上账”的扯皮。基本能做到任意一条数据都能追溯到它来自哪个会话、什么时间被采集、什么时候被消费这大大提升了团队排查问题的效率。5. 运维期踩过的坑与排查实录5.1 ClickHouse运维的“三把火”第一次在生产环境接入ClickHouse时我们想当然地把它当成MySQL来用结果第一个晚上就出了幺蛾子插入数据时ClickHouse报错“Too many parts”整个写入链路都堵了线上看板指标直接变成一条平线。原因是ClickHouse后台的Merge任务速度赶不上高频小批量插入产生的parts数量。这个问题的教训是ClickHouse不擅长高频小批量写入它擅长大批量低频写入。解决办法有两个一是攒批让每次插入的数据量达到几千条以上二是调低后台后台Merge的触发阈值让parts更频繁地被合并。这两个手段我们最终都用了写入侧在应用层配置了攒批逻辑同时建表时设置了专门的Merge参数。经验数据是单次写入5000条以上ClickHouse的写入性能才有最好表现。第二把火是存储空间膨胀。明细表保留30天原始数据但因为采样率和事件类型逐渐变多存储一度飙到600GB。后来做了冷热分层1天以内的数据保留在热存储全量明细1天以上的数据按天分片超过7天的从分区表迁移到归档表只保留聚合指标。这样热数据查询依然很快冷数据只是留档访问频率极低。第三把火是查询超时。看板页面加载要十几秒排查发现是聚合查询扫描了全表。优化手段有二一是把查询字段都建在排序键上让ClickHouse只扫描必要的分区二是聚合结果预热把常用的指标提前算好放进Redis用户打开看板直接读缓存。优化后看板首屏时间降到1秒以内。5.2 三个排查过的最“诡异”的问题第一个问题线上某段时间突然没有数据但系统一切正常。后来查到原因是前端SDK上报的域名证书过期了浏览器拦截了所有上报请求。这个问题的诡异之处在于它不在服务端日志里留下任何错误痕迹。排查过程从“服务端采集链路是否正常”入手最后发现页面控制台有证书报错。修复方案是监控SDK内部的上报失败率失败率超过阈值自动告警证书有效期提前30天自动提醒。第二个问题某一类事件的数据量比预期高出十倍。查了Kafka消费日志发现某台服务器上的SDK初始化代码被重复执行了多次每次初始化就会重新绑定一次点击事件导致同一用户的一次点击被上报了多次。修复方案是SDK内部做防重复初始化判断绑定事件前先检查标志位。这就是一个很典型的“上报端bug”而不是“接收端bug”。第三个问题监控看板显示某接口P95耗时正常但业务方坚持说该接口很卡。后来把P95拆成P50、P90、P99对比才发现问题出在P99上P99每次都会出现一个4秒左右的尖峰这个尖峰被平均数给掩盖了。聚合指标如果只看平均数和P95很容易漏掉真正影响体验的尾延迟。从那以后我们所有接口性能看板都强制展示P50、P90、P99三档并提供尾延迟分布的直方图。5.3 常规运维清单给还在用这套架构跑数据的小伙伴提几个建议Kafka消费者如果长期不消费重启后从最新偏移量开始而不是从之前的偏移量继续程序启动时必须明确设置偏移量策略ClickHouse的表引擎分区键定成日期字段toYYYYMMDD查询和删除老数据都方便明细表和聚合表的TTL分开设置明细表保留7天聚合表保留60天采集网关的限流阈值宁可设高一些也不要设太低否则活动突发流量进来直接误伤正常上报前端SDK的发布要做到向后兼容旧版本SDK上报的数据格式如果已经变更后端接收逻辑必须兼容旧字段至少一个版本周期6. 从rea到团队协作项目推进中的管理心得6.1 节奏把控与分工建议技术上聊了这么多项目落地过程中实际最难的部分往往是进度管理和跨角色协作。我们的团队很精简一位前端两位后端一位测试。四个人把rea拆成了三个里程碑。第一个里程碑只做最小闭环前端采集后端接收简单看板。这个阶段的目标是让业务方能看到实时数据哪怕指标不全。第二个里程碑补上性能指标和告警这是业务方最痛的点。第三个里程碑才做完整的行为链路回溯和漏斗分析。这种节奏的好处是每个里程碑都有可以演示的成果业务方会持续给你反馈而不是憋了三个月拿出一个没人要的东西。团队分工上有两点值得特别强调前端和后端之间接口契约必须先定义清楚。我们用一个JSON Schema描述所有事件字段前后端共享这份定义任何一方的改动都要改schema并通知对方。这避免了很多联调事故。测试人员从一开始就参与而不是做完了才介入。针对这种实时数据系统我们专门搭建了一个测试用的模拟流量服务可以按脚本生成各种类型和频率的事件测试在开发过程中就能验证消费者逻辑是否健壮。6.2 数据指标定义远比技术选型重要我刚做这个项目的时候把大量精力花在选型、调参、性能优化上后来被业务方问了一个问题你们这个“体验指数”到底想表达什么我愣住了。我们一直在实现“采集什么数据”我几乎没有认真思考过“这些数据组合在一起应该变成什么结论”。这个问题直接推动了指标体系的重新设计。我们最终敲定了三个核心指标加载体验首屏时间P50/P90分别反映一般用户和较差网络用户的体验交互活跃度会话中的有效点击/有效操作次数衡量用户是否真的在“用”产品转化流失从访问到关键动作完成的漏斗转化率定位流失最严重的环节技术再好如果指标体系说不清楚业务方照样觉得这项目没什么用。这让我深刻认识到数据项目的第一步永远是“业务和产品定义”第二步才是技术实现。7. 想继续做下去我会先动这些地方7.1 实时计算引擎替换与算法升级如果这个项目继续往下做我认为最重要的改动是放弃手写窗口累加逻辑换成Flink这样的流式计算框架。原因很简单手写统计逻辑在业务规则变复杂后可维护性会迅速恶化。Flink的窗口机制、状态管理、精确一次语义都是成熟开箱即用的能力引入它能省掉很多我们自己维护的边界逻辑。除此之外异常检测算法也要升级。目前我们靠阈值告警比如“接口P95超过3秒发告警”这种静态阈值在业务高峰期很容易误报半夜又可能漏报。后续想引入动态基线和波动识别让告警能结合历史数据自动调整阈值真正做到发现“与往常不一样”而不是简单超过某个数。7.2 前端视角的增强能力体验分析如果只停留在“性能指标”上说实话有点浪费。我一直觉得如果能把用户的具体操作路径可视化出来比任何报表都更有说服力。比如用户进入页面筛选条件、点击多个商品、加入购物车、最后没有提交订单这条链路如果能用一张图还原出来产品和运营立刻就能找到优化点。这块目前的技术实现可以基于已有明细数据和会话ID把同一会话的所有事件按时间排列然后前端渲染成轨迹图。难点不在后端而在于前端在大量事件渲染时的性能。会话较少时可以全量渲染事件很多的会话可以做聚类降维只展示关键节点。7.3 成本控制与资源调优最后提一下成本。实时数据系统最容易被忽视的就是成本。我们算过一笔账ClickHouse三节点集群的机器费用加上Kafka的磁盘费用一年下来是一笔不小的开支。如果业务量没有指数级增长完全可以做垂直优化比如降低明细表保留天数、压缩Kafka日志保留时间、将部分低价值事件降级为离线采集。控制成本这件事不是省出来的是所有技术选型和架构决策的底层约束。几点真实的个人体会做“rea”这个项目收获最大的一条教训是面对一个模糊的代号不要急着写代码先花时间把“它到底该解决什么问题”聊透。技术选型、数据管道、性能优化都是在这个前提之下自然生长出来的。还有一条实操层面的体会在实时系统的开发中数据可靠性不是靠某一个机制就能完成的需要从SDK的采集策略到存储层的去重机制做全链路设计。任何一环的疏忽都会在数据量上涨后变成不可忽略的故障。如果你也在做类似的项目希望这篇文章里的选型思路、参数细节和踩坑经验能帮你少走一些弯路。尤其是ClickHouse的写入抖动、Kafka消费幂等、前端埋点防重复这些问题都是文档里很难看到但实际一定会遇到的内容。 1. 项目代号背后的需求博弈1.1 “rea”到底是什么拿到“rea”这个项目代号的时候团队里开了个短暂的碰头会。三个字母没有任何上下文第一反应是“read”少了字母第二反应是有人拼错了React第三反应是某个框架里的术语缩写。这种模糊感其实挺常见的很多项目在立项阶段都只有一个代号后面的一切全靠推导。我当时做了一件事列了一个“可能的含义清单”。比如rea Realtime Experience Analytics实时体验分析rea Resource Exploration API资源探测接口rea Read/Evaluate/Act读-评估-执行某种决策循环rea 某个内部系统的缩写连命名人都忘了原意这种清单看起来很笨但非常有效。因为它逼着每个参与者把自己的预期放到台面上而不是各自抱着一个理解去做开发。讨论之后我们发现真正能让团队共振、也有商业价值的是Realtime Experience Analytics这条线——一套面向Web应用的用户体验实时监控系统。为什么选它因为当时团队已经有一套定时统计报表每天凌晨跑批第二天早上看数据。但业务方提了个很尖锐的问题昨天下午线上活动页面卡了为什么今天早上才告诉我们这个问题暴露的不只是技术债而是整个监控体系的时效性缺陷。所以“实时”这个属性就成了项目的核心锚点而“体验分析”则是业务价值的落点。1.2 从模糊到清晰锁定核心用户与场景项目代号确定方向后下一步就是定义“给谁用、解决什么问题”。这部分我踩过不少坑早期做数据类项目时习惯先聊技术再聊场景结果做出来的东西像个技术demo业务方根本用不上。这次我们把场景摆在了最前面。核心用户是三类人前端研发想知道页面加载慢是网络问题、接口问题还是渲染问题后端研发想知道某个接口在某段时间内是否成为瓶颈运营/产品想知道用户是否真的完成了关键转化动作流失点在哪围绕这三类用户我们抽象出几个必做的能力采集页面性能指标首屏时间、DOM就绪、接口耗时采集用户行为链路点击、停留、跳转、提交实时聚合与告警某个指标超过阈值立刻通知事后回溯按用户会话查看完整操作序列这个“用户-场景-能力”的三角拆解是后续所有技术决策的出发点。说白了技术选型不是看哪个框架流行而是看谁能在最短时间内稳定支撑这三块。后来我们砍掉了很多“锦上添花”的需求比如复杂的漏斗分析、用户分群画像因为那些会显著拉长项目周期而且初期大家根本用不上。2. 技术选型一套能支撑实时的管道2.1 为什么是“前端埋点 消息队列 OLAP存储”三段式实时体验分析类的系统业界常见的做法是分段处理采集端负责数据产生与初步加工传输层负责缓冲与削峰存储与计算层负责聚合和查询。我们最终选定的链路是前端SDK → 网关 → 消息队列 → 消费与清洗 → 实时聚合/OLAP存储 → 查询API与看板。这个三段式结构解决了三个核心问题解耦采集与消费。前端产生的事件量是脉冲式的白天活动期间可能每秒上万条凌晨可能只有几十条。如果采集端直连数据库要么数据库扛不住高峰要么闲时资源浪费。中间加一层消息队列天然起到了削峰填谷的作用。让实时和离线并存。同一份数据进入消息队列后可以同时被实时链路和离线链路消费不用维护两套采集逻辑。容错与重放。数据管道上游挂了消息队列里积压的数据不会丢恢复后可以继续消费这是直接写入数据库无法天然实现的。2.2 关键组件的选型和参数心得这里逐个说说每个环节的具体选型思路。先说前端SDK我们选择了自研一个轻量级的SDK而不是直接嵌入第三方商业方案。原因很简单数据主权和灵活性。我们需要采集特定的业务事件比如用户点击了某个业务模块并且要把SDK的体积控制在很小的范围内第三方方案很难同时满足这两点。后端语言选了Java和Spring Boot不是因为它最“潮”而是团队存量技术栈就是这组上手快、排查问题资料多。模块间通信用了Spring的异步事件机制跨进程的部分依赖消息队列。消息队列选了Kafka。选型对比时也看过RocketMQ等方案最终因为Kafka吞吐高、生态成熟、消费模型灵活而定。容量规划上我们做了一个粗略估算假设日均5000万事件峰值是均值的5倍单事件平均1KB那么峰值每秒约3000条消息Kafka集群三节点足够。这个估算在后面性能测试中验证过基本准确。OLAP存储我们选了ClickHouse。这个选择是经过两类方案对比后的结果一类是传统MySQL分库分表一类是ClickHouse。MySQL对于这种带有大量维度字段、需要秒级聚合的查询场景即使分了库表查询性能和扩展性也会随着数据量增长迅速恶化。ClickHouse的列式存储和向量化执行在处理这种分析型查询上有数量级的优势。当然代价是我们得为它配套独立的冷热备份机制这个后面会讲到。环节选型核心考量数据采集自研轻量JS SDK体积可控、事件自定义、采样率可控异步缓冲Kafka高吞吐、可重放、多消费者清洗加工Java/Spring Boot消费者组与团队技术栈一致、生态完善存储ClickHouse列式存储支持秒级聚合查询与看板Spring Boot API Web快速搭建、灵活定制3. 核心模块的实操实现3.1 前端埋点SDK的设计与实现SDK设计的第一原则是“不要阻碍主业务”。这意味着脚本必须异步加载不能同步阻塞页面渲染上报必须走SendBeacon或图片请求这类不干扰主线程的方式所有内部错误必须捕获并静默处理绝不能让埋点代码的异常暴露到用户控制台。我们实现了几种常见的采集项。性能指标用浏览器的PerformanceTiming和PerformanceObserver事件监听用原生addEventListener会话标识用cookie或者localStorage存储一个UUID每次页面加载生成新的会话ID。一个比较关键的细节是采样率控制。全量埋点数据量太大而且很多用户的行为特征高度相似所以我们对普通访问做了动态采样默认50%采样率当某个页面流量突然增大时自动降低采样率到10%。这个逻辑放在SDK内部后端通过配置接口下发切流量非常方便。SDK的代码结构大致是这样的思路// sdk核心入口收集数据后统一走report管道 class ReaSDK { constructor(config) { this.config Object.assign({ endpoint: , sampleRate: 0.5 }, config); this.sessionId this.getSessionId(); this.bindEvents(); } bindEvents() { // 监听点击、错误、性能等事件 window.addEventListener(click, this.handleClick.bind(this), true); window.addEventListener(error, this.handleError.bind(this), true); } handleClick(e) { if (Math.random() this.config.sampleRate) return; const payload { type: click, sessionId: this.sessionId, path: location.pathname, target: e.target ? e.target.tagName : , timestamp: Date.now() }; this.report(payload); } report(data) { const blob new Blob([JSON.stringify(data)], { type: application/json }); navigator.sendBeacon navigator.sendBeacon(this.config.endpoint, blob); } }实操中注意几个点事件监听建议用捕获阶段而不是冒泡阶段因为捕获阶段能更早拿到事件且不会被业务侧的stopPropagation拦截上报数据要做数组批量打包前端攒够10条或2秒时间窗口再发一次能显著减少请求量。3.2 后端数据接入与聚合的方案后端主要分两个部分数据接入和实时聚合。数据接入层负责接收SDK上报的HTTP请求做基本的格式校验、字段补全、内容过滤然后写入Kafka。这一步设计得尽量简单避免复杂的业务逻辑目的只有一个高并发写入时不丢不重不阻塞。实时聚合这一层我们用了两种路径。路径一是流式聚合消费Kafka后直接做窗口计算比如每分钟计算一次某个页面的平均加载耗时结果写入Redis或ClickHouse的汇总表供看板查询路径二是明细存储原始事件全量写入ClickHouse明细表用于事后下钻分析。两条路径并行互不干扰。流式聚合这块我们用了一个比较朴素的方案消费者线程在内存中维护一个ConcurrentHashMap作为窗口计数器窗口大小定为10秒每个窗口结束后把计数结果批量写入聚合表。用10秒这个值的考量是窗口太大指标的实时性打折窗口太小状态管理和持久化成本高。实际运行下来10秒窗口在实时性和开销之间取得了不错的平衡。聚合写入ClickHouse时为了避免高频小批量写入引发Too many parts的问题我们攒批到5000条或5秒才提交一次。这两个参数可以直接写在ClickHouse的异步插入配置里也可以由应用层控制。我们选择了应用层控制因为这样能更灵活地调节批量大小和吞吐量。数据接入流程前端SDK以JSON格式批量POST到/collect接口网关层做Basic Auth校验和限流每IP每秒100次接入服务校验字段完整性补齐客户端IP、UserAgent、服务端时间数据序列化后发送到Kafka的rea-events-topic话题消费者组实时消费一路走聚合写Redis一路原样写ClickHouse这套流程上线后高峰期每秒能够稳定处理5000条数据P99延迟在120ms以内。支撑这个吞吐量的关键在于每个环节都做了解耦任何一环的抖动都不会直接拖垮整体的采集链路。4. 数据可靠性建设从“丢数据”到“可追责”4.1 消费幂等与数据补偿机制消息队列用久了大家都会遇到一个经典问题Consumer挂了重启或者上游重复发送数据到底会不会丢会不会重复Kafka的At Least Once语义保证的是“至少一次”也就是说它不保证“正好一次”在极端场景下重复消费是可能的。我们在线上的确踩到过一次重复数据导致计数翻倍的故障。排查了半天发现是消费者在处理过程中抛了一个异常Kafka把消息重新入队而我们的聚合逻辑没有做去重判断于是同一批点击事件被统计了两次。解决的方法是幂等写入。ClickHouse有一个ReplacingMergeTree引擎它允许指定一个版本列相同排序键下只保留版本最大的那条记录。我们把事件ID作为排序键消费时间戳作为版本号这样即使同一事件被消费两次存储层也会自动去重。但这并不是治本的办法。我后来在代码规范里加了一条消费者必须在下游写入前生成一个全局唯一的事件唯一标识并且把去重逻辑同时放在应用层和存储层两道防线中。应用层维护一个最近处理过的布隆过滤器命中则跳过存储层用合并树兜底。双保险之后这个类问题基本绝迹。4.2 延迟与乱序数据的处理策略实时系统的另一个隐形杀手是数据乱序。前端SDK上报的数据在网络拥塞时可能出现乱序到达比如点在先的数据因为网关重试结果后到。直接按时间戳排序会得到错误的结果。一种简单的思路是采用“事件时间”而不是“到达时间”。每条数据在SDK端就打上客户端时间戳后端所有聚合计算都以这个时间为准。但客户端时间有可能因为用户本机时间设置错误而偏差因此在接入层我们会额外记录服务端收到时间两个时间差超过5分钟的记录直接标记异常并降级处理。另一个必须应对的场景是延迟数据。消费者从Kafka读取到一条迟到超过窗口边界的数据时正常窗口计算早就结束了直接把数据丢弃会丢失有效信息。我们的方案是用延迟缓冲队列加补偿任务延迟数据先打入一个侧输出流落到ClickHouse延迟表然后一个定时任务每隔10分钟扫描延迟表发现窗口尚未关闭的把数据补算进对应的汇总指标里。虽然补算的指标晚了一些但数据是完整的看板展示时标记为“修正后数据”避免误导用户。数据可靠性速查问题表现我们的应对重复消费指标翻倍、计数膨胀应用层布隆过滤器 存储层ReplacingMergeTree数据丢失窗口指标断层Kafka保留时间延长至7天消费位点可回退乱序到达转化链路错乱、漏斗不准以客户端事件时间为准网关时间辅助校验延迟过高看板指标滞后延迟补偿任务 修正后数据标记这套机制上线后再也没有发生过“数据对不上账”的扯皮。基本能做到任意一条数据都能追溯到它来自哪个会话、什么时间被采集、什么时候被消费这大大提升了团队排查问题的效率。5. 运维期踩过的坑与排查实录5.1 ClickHouse运维的“三把火”第一次在生产环境接入ClickHouse时我们想当然地把它当成MySQL来用结果第一个晚上就出了幺蛾子插入数据时ClickHouse报错“Too many parts”整个写入链路都堵了线上看板指标直接变成一条平线。原因是ClickHouse后台的Merge任务速度赶不上高频小批量插入产生的parts数量。这个问题的教训是ClickHouse不擅长高频小批量写入它擅长大批量低频写入。解决办法有两个一是攒批让每次插入的数据量达到几千条以上二是调低后台后台Merge的触发阈值让parts更频繁地被合并。这两个手段我们最终都用了写入侧在应用层配置了攒批逻辑同时建表时设置了专门的Merge参数。经验数据是单次写入5000条以上ClickHouse的写入性能才有最好表现。第二把火是存储空间膨胀。明细表保留30天原始数据但因为采样率和事件类型逐渐变多存储一度飙到600GB。后来做了冷热分层1天以内的数据保留在热存储全量明细1天以上的数据按天分片超过7天的从分区表迁移到归档表只保留聚合指标。这样热数据查询依然很快冷数据只是留档访问频率极低。第三把火是查询超时。看板页面加载要十几秒排查发现是聚合查询扫描了全表。优化手段有二一是把查询字段都建在排序键上让ClickHouse只扫描必要的分区二是聚合结果预热把常用的指标提前算好放进Redis用户打开看板直接读缓存。优化后看板首屏时间降到1秒以内。5.2 三个排查过的最“诡异”的问题第一个问题线上某段时间突然没有数据但系统一切正常。后来查到原因是前端SDK上报的域名证书过期了浏览器拦截了所有上报请求。这个问题的诡异之处在于它不在服务端日志里留下任何错误痕迹。排查过程从“服务端采集链路是否正常”入手最后发现页面控制台有证书报错。修复方案是监控SDK内部的上报失败率失败率超过阈值自动告警证书有效期提前30天自动提醒。第二个问题某一类事件的数据量比预期高出十倍。查了Kafka消费日志发现某台服务器上的SDK初始化代码被重复执行了多次每次初始化就会重新绑定一次点击事件导致同一用户的一次点击被上报了多次。修复方案是SDK内部做防重复初始化判断绑定事件前先检查标志位。这就是一个很典型的“上报端bug”而不是“接收端bug”。第三个问题监控看板显示某接口P95耗时正常但业务方坚持说该接口很卡。后来把P95拆成P50、P90、P99对比才发现问题出在P99上P99每次都会出现一个4秒左右的尖峰这个尖峰被平均数给掩盖了。聚合指标如果只看平均数和P95很容易漏掉真正影响体验的尾延迟。从那以后我们所有接口性能看板都强制展示P50、P90、P99三档并提供尾延迟分布的直方图。5.3 常规运维清单给还在用这套架构跑数据的小伙伴提几个建议Kafka消费者如果长期不消费重启后从最新偏移量开始而不是从之前的偏移量继续程序启动时必须明确设置偏移量策略ClickHouse的表引擎分区键定成日期字段toYYYYMMDD查询和删除老数据都方便明细表和聚合表的TTL分开设置明细表保留7天聚合表保留60天采集网关的限流阈值宁可设高一些也不要设太低否则活动突发流量进来直接误伤正常上报前端SDK的发布要做到向后兼容旧版本SDK上报的数据格式如果已经变更后端接收逻辑必须兼容旧字段至少一个版本周期6. 从rea到团队协作项目推进中的管理心得6.1 节奏把控与分工建议技术上聊了这么多项目落地过程中实际最难的部分往往是进度管理和跨角色协作。我们的团队很精简一位前端两位后端一位测试。四个人把rea拆成了三个里程碑。第一个里程碑只做最小闭环前端采集后端接收简单看板。这个阶段的目标是让业务方能看到实时数据哪怕指标不全。第二个里程碑补上性能指标和告警这是业务方最痛的点。第三个里程碑才做完整的行为链路回溯和漏斗分析。这种节奏的好处是每个里程碑都有可以演示的成果业务方会持续给你反馈而不是憋了三个月拿出一个没人要的东西。团队分工上有两点值得特别强调前端和后端之间接口契约必须先定义清楚。我们用一个JSON Schema描述所有事件字段前后端共享这份定义任何一方的改动都要改schema并通知对方。这避免了很多联调事故。测试人员从一开始就参与而不是做完了才介入。针对这种实时数据系统我们专门搭建了一个测试用的模拟流量服务可以按脚本生成各种类型和频率的事件测试在开发过程中就能验证消费者逻辑是否健壮。6.2 数据指标定义远比技术选型重要我刚做这个项目的时候把大量精力花在选型、调参、性能优化上后来被业务方问了一个问题你们这个“体验指数”到底想表达什么我愣住了。我们一直在实现“采集什么数据”我几乎没有认真思考过“这些数据组合在一起应该变成什么结论”。这个问题直接推动了指标体系的重新设计。我们最终敲定了三个核心指标加载体验首屏时间P50/P90分别反映一般用户和较差网络用户的体验交互活跃度会话中的有效点击/有效操作次数衡量用户是否真的在“用”产品转化流失从访问到关键动作完成的漏斗转化率定位流失最严重的环节技术再好如果指标体系说不清楚业务方照样觉得这项目没什么用。这让我深刻认识到数据项目的第一步永远是“业务和产品定义”第二步才是技术实现。7. 想继续做下去我会先动这些地方7.1 实时计算引擎替换与算法升级如果这个项目继续往下做我认为最重要的改动是放弃手写窗口累加逻辑换成Flink这样的流式计算框架。原因很简单手写统计逻辑在业务规则变复杂后可维护性会迅速恶化。Flink的窗口机制、状态管理、精确一次语义都是成熟开箱即用的能力引入它能省掉很多我们自己维护的边界逻辑。除此之外异常检测算法也要升级。目前我们靠阈值告警比如“接口P95超过3秒发告警”这种静态阈值在业务高峰期很容易误报半夜又可能漏报。后续想引入动态基线和波动识别让告警能结合历史数据自动调整阈值真正做到发现“与往常不一样”而不是简单超过某个数。7.2 前端视角的增强能力体验分析如果只停留在“性能指标”上说实话有点浪费。我一直觉得如果能把用户的具体操作路径可视化出来比任何报表都更有说服力。比如用户进入页面筛选条件、点击多个商品、加入购物车、最后没有提交订单这条链路如果能用一张图还原出来产品和运营立刻就能找到优化点。这块目前的技术实现可以基于已有明细数据和会话ID把同一会话的所有事件按时间排列然后前端渲染成轨迹图。难点不在后端而在于前端在大量事件渲染时的性能。会话较少时可以全量渲染事件很多的会话可以做聚类降维只展示关键节点。7.3 成本控制与资源调优最后提一下成本。实时数据系统最容易被忽视的就是成本。我们算过一笔账ClickHouse三节点集群的机器费用加上Kafka的磁盘费用一年下来是一笔不小的开支。如果业务量没有指数级增长完全可以做垂直优化比如降低明细表保留天数、压缩Kafka日志保留时间、将部分低价值事件降级为离线采集。控制成本这件事不是省出来的是所有技术选型和架构决策的底层约束。几点真实的个人体会做“rea”这个项目收获最大的一条教训是面对一个模糊的代号不要急着写代码先花时间把“它到底该解决什么问题”聊透。技术选型、数据管道、性能优化都是在这个前提之下自然生长出来的。还有一条实操层面的体会在实时系统的开发中数据可靠性不是靠某一个机制就能完成的需要从SDK的采集策略到存储层的去重机制做全链路设计。任何一环的疏忽都会在数据量上涨后变成不可忽略的故障。如果你也在做类似的项目希望这篇文章里的选型思路、参数细节和踩坑经验能帮你少走一些弯路。尤其是ClickHouse的写入抖动、Kafka消费幂等、前端埋点防重复这些问题都是文档里很难看到但实际一定会遇到的内容。