我第一次看到“rea”这个代号时就意识到这肯定不是一个随手敲出来的缩写。团队内部通常有个习惯新项目先起小名再谈架构后来小名变成全线文档里的关键词。rea是某个内部项目的代号全称后来补成了实时事件分析系统Real-time Event Analytics。它解决的事情很简单把用户在产品里的关键行为例如登录、点击、切换页面、付款尝试用最低的成本实时收集起来然后按秒级延迟加工成业务能直接查看的看板和预警。如果你正在做埋点、数据管道、实时计算这一类工作或者正被“数据要等第二天才能看”折磨那这篇文章应该能给你几套可落地的方案。我在这个项目里负责从端上采集到最终查询的全链路搭建。整个过程谈不上花哨但踩过的坑、回过头再看值得坚持的设计取舍我觉得比一份漂亮的架构图更有参考价值。下面按项目推进的顺序把rea从需求到实施再到排障讲清楚。1. 项目整体设计与思路拆解1.1 核心需求为什么放弃T1批处理rea这个项目不是凭空立项的。当时线上已经跑着一套传统埋点系统前端按自定义格式发日志服务端做日志落盘每天凌晨跑离线任务第二天上午十点才能更新指标。对运营来说看前一天的数据几乎等于看历史活动上线后有没有效果流量瞬间冲高或者崩溃都要等十几个小时才能确认。尤其是大促和紧急变更的场景这种延迟完全不可接受。所以rea的第一步不是选技术而是把需求钉死端上事件从发生到进入分析系统延迟不能超过5秒看板页面上的关键指标例如活跃用户、页面点击率、转化率刷新后1秒内出数数据链路故障时不能直接丢数据宁可延迟不能丢失。查询不能只支持固定报表要能自助筛选维度和时间范围。这三个约束一旦写清楚后续的架构选型就都有了判断标准。批处理被放弃不是因为离线分析没用而是它满足不了“秒级看到新事件”和“紧急情况下快速定位”这两个场景。我们最终采用的是“端上实时上报消息队列临时缓冲流式计算持续聚合分析型数据库存储明细”的方案。1.2 技术选型链路中各层为什么是这些组件选型过程拉扯了很久核心争论在于自研和开源搭配的边界。我们最终形成的技术栈如下端上采集原生TypeScript SDK负责校验、采样、会话标识和发送传输层HTTP接口上报按事件类型走不同Topic缓冲层Kafka所有原始事件先进消息队列避免后端处理速度抖动直接拖垮采集端流处理层Flink做清洗、去重、维度补齐和实时聚合存储与查询层ClickHouse存明细Redis存高频计数查询服务统一走Java API。这个组合在2021年之后几乎是实时数据链路的标配。但每一项都有必须如此的理由。Kafka的作用是削峰填谷就算前端瞬间爆发百万条事件后端的Flink消费能力也能被队列缓存调节。Flink负责真正麻烦的事乱序事件、迟到数据、时间窗口聚合。ClickHouse则解决明细存储的查询性能问题亿级数据下按时间字段过滤加聚合基本能做到秒内响应。如果不用这套组合自己做队列和流处理引擎开发量至少翻三倍而且难以保证exactly-once的语义。市面上开源的方案已经经过大量生产环境验证没必要重复造轮子。rea当时的经验是选主流组件遇到问题的概率远小于选小众方案。2. 核心细节解析与实操要点2.1 事件协议设计埋点数据的通用语言事件协议是整个链路最容易被低估的部分。许多项目一开始觉得不就是前端传个JSON后端解析吗但一旦涉及多端接入、多业务方就会明白没有一套严格协议的后果。rea没有用嵌套很深的JSON而是设计了扁平结构公共字段和业务字段分开公共字段事件ID、会话ID、用户ID、时间戳、所在页面、设备信息、客户端版本、app版本业务字段通过一个独立的properties对象承载包含事件名和具体属性扩展字段预留map类型方便业务方临时补充字段但不能超过5个键。时间戳统一用毫秒级Unix时间戳所有端都传同一字段。注意这个时间戳指的是事件发生时端上的系统时间不是到达服务器的时间。服务端会额外记录一个接收时间两个时间分开存。这样排查问题的时候才能区分端上延迟和链路延迟。另一个关键约定是事件名枚举管理。允许业务方自由传字符串会让后续的清洗和统计变成噩梦。rea规定所有事件名必须先在管理端注册由数据平台统一分配SDK在端上做校验不合法的事件直接忽略并上报错误日志。这个约束虽然让业务方多了一步操作但换来的是指标命名高度收敛后续聚合查询不用到处处理异构数据。协议版本也必须有。客户端每次上报事件时带上schemaVersion服务端保存每个版本对应的字段说明。因为客户端版本陈旧问题一定会出现老SDK可能上报缺失字段或事件名变更有schemaVersion才能知道怎么解析和兼容。2.2 采样与降噪不是所有事件都值得实时计算实时计算成本不低尤其是Flink和ClickHouse的集群资源。rea上线两个月后我意识到如果所有事件不分青红皂白都进实时链路资源和价值的比例很容易失衡。解决的思路是分级处理关键事件登录、注册、支付、下单、加购必须全量采集实时处理一般事件页面浏览、元素点击默认全量采集但在传输端按事件名走不同topic流量过高时可以动态调整采样率低频噪声事件例如自动保存、后台心跳、音频播放进度这些通常对业务分析意义不大直接裁掉或按1%采样。做这个分级时我们实现了一套简单的配置下发逻辑。SDK在启动时从配置服务拉取采样规则规则里包含事件名、采样比例和生效时间段。例如大促期间需要全量保留点击数据就把比例改成1无需发版。而平时为了让链路不过载可以按10%采样。这里需要特别注意采样不能只在前端做随机数很容易破坏漏斗分析的数值关系。如果想要某个漏斗路径完整可计算那么属于同一个会话ID的事件必须要么全部保留要么全部丢弃。我们在SDK里用会话ID的哈希值做采样判断也就是按会话整体采样。后台统计时再根据会话的采样比例做加权还原能明显减轻偏差。2.3 实时性保证从端上到看板的秒级目标实时性不是端上发送频率决定的是整个链路每个环节都必须控制延迟。rea的目标是5秒内看到事件实际调优后稳定在3秒左右。拆解下来端上要做两件事。第一避免频繁的网络请求。我们采用批量发送策略事件先进内存队列最多攒20条或每2秒发送一次先到者触发。第二在页面切换或关闭的瞬间用sendBeacon接口把待发送的数据发出去。这样能避免很多因为页面卸载导致的数据丢失。服务端链路里Kafka的topic分区数、消费者的并行度、ClickHouse的批次写入大小三者要协同调优。如果分区数是12但Flink算子并行度只有4那么最多只有4个分区在被消费其余分区会积压。当时我们的经验是分区数至少设置为消费并行度的1.5倍并且尽量让每个分区单条消息体积接近避免某个分区因为消息特别大而延迟。流处理阶段Flink开启事件时间watermark乱序时间容忍设为2秒。事件到达后先做完整性校验再根据时间戳分配窗口。这就能把端上因为网络抖动造成的乱序数据归到正确的时间窗口里。ClickHouse侧使用批量异步写入每5000条或1秒刷一次通过控制批量大小来兼顾写入延迟与吞吐。3. 实操过程与核心环节实现3.1 端上采集SDK的实现先看SDK的核心逻辑。我们用TypeScript写了一个轻量采集模块对外暴露track方法。整体思路是事件进入一个内存队列队列由发送线程消费发送前做采样判断、数据补全和序列化。下面是简化后的代码逻辑type TrackEvent { eventName: string; properties: Recordstring, unknown; timestamp: number; sessionId: string; userId?: string; }; class Tracker { private queue: TrackEvent[] []; private maxBatchSize 20; private flushInterval 2000; private samplingRatio: Recordstring, number {}; track(eventName: string, properties: Recordstring, unknown) { const event: TrackEvent { eventName, properties, timestamp: Date.now(), sessionId: getSessionId(), userId: getUserId(), }; // 按会话采样同一个会话的事件要么全保留要么全丢弃 if (!this.shouldSample(event)) return; this.queue.push(event); if (this.queue.length this.maxBatchSize) { this.flush(); } } private shouldSample(event: TrackEvent): boolean { const ratio this.samplingRatio[event.eventName] ?? 1; if (ratio 1) return true; const hash hashString(event.sessionId event.eventName); return hash % 100 ratio * 100; } private flush() { const batch this.queue.splice(0, this.maxBatchSize); if (batch.length 0) return; this.sendBatch(batch); } }这里有几个容易被忽略的细节。第一sample逻辑中hash的作用范围是整个会话和事件名的组合如果只随机数判断同一个session的漏斗事件可能一半被保留一半被丢弃后期加权还原根本算不回来。第二事件队列必须设置上限不能是无界队列否则极端情况下会占用大量内存。我们在rea的实现里设置队列上限为200条超出后抛弃新事件保证应用本身不受影响。发送失败后的重试也很讲究。不能无限重试否则堆积会越来越大。我们的策略是第一次失败后间隔500毫秒重试最多重试3次仍然失败就把事件写入IndexedDB的本地缓存等下一次会话启动时再补发。这样既避免高频重试影响页面性能也尽量保住数据。sendBeacon是保证页面关闭时不丢数据的核心navigator.sendBeacon(url, new Blob([JSON.stringify(batch)], { type: application/json }));sendBeacon适合小批量数据不适合塞几十KB内容。rea的做法是只在页面visibilitychange和beforeunload时把当前队列里剩余的事件用sendBeacon发送。3.2 数据管道的Flink清洗与聚合Flink作业是整个实时链路最核心的部分。我们做两件大事一是清洗二是聚合。清洗阶段其实不是flink开始的而是在解析JSON时就处理。每条事件到Flink后反序列化proto或JSON校验必填字段、时间戳合法性、eventName是否在注册表里。非法数据写入特殊的脏数据topic方便定期对账。聚合阶段采用状态编程Flink SQL结合的方式。最常用的是计算每分钟的活跃用户数和页面点击事件数。下面这段是基于Flink Table API配置的实时聚合思路Table events tableEnv.fromDataStream( eventStream, Schema.newBuilder() .column(eventName, DataTypes.STRING()) .column(userId, DataTypes.BIGINT()) .column(eventTime, DataTypes.BIGINT()) .build() ); Table minutelyStats events .window(Tumble.over(lit(1).minute()).on(eventTime).as(window)) .groupBy(eventName, window) .select( eventName, window.start AS windowStart, COUNT(DISTINCT userId) AS uv, COUNT(*) AS pv );实际生产里我们很少用HOP窗口和TUMBLE窗口混用因为会让状态无限扩张。最稳妥的做法是用Tumble窗口做分钟级聚合结果写进Redis业务查询直接读Redis的分钟计数再在展示层累加为小时或天级数据。需要明细时再回ClickHouse查。Flink的状态清理也必须配置TTL。否则聚合状态会无限增长最终OOM。我们的状态TTL设为2分钟远大于乱序容忍时间既能兜住迟到数据又不至于吞掉全部内存。3.3 ClickHouse表设计明细存储与聚合查询ClickHouse在rea里的定位是明细查询引擎。主要两张表事件明细表和分钟级聚合表。事件明细表采用MergeTree引擎按事件时间分区按用户ID事件名进行一级排序。建表语句大致如下CREATE TABLE events_detail ( event_time DateTime64(3), event_name String, user_id UInt64, session_id String, page_url String, device_type String, properties_json String ) ENGINE MergeTree PARTITION BY toYYYYMMDD(event_time) ORDER BY (event_time, user_id, event_name) TTL event_time INTERVAL 30 DAY;ORDER BY的顺序非常影响查询性能。如果查询经常按event_name过滤就应该把event_name提前。rea的实践经验是主查询场景总是带时间和用户再按事件名聚合所以这个排序顺序是合理的。分钟级聚合表是为了让看板不需要偶尔扫明细表。我们在Flink里把聚合结果写入Kafka再由另一条链路写入ClickHouse的聚合表CREATE TABLE events_minutely ( event_time DateTime, event_name String, uv AggregateFunction(uniq, UInt64), pv UInt64 ) ENGINE AggregatingMergeTree PARTITION BY toYYYYMMDD(event_time) ORDER BY (event_time, event_name);注意这里的AggregateFunction类型uv列存的是uniq状态而不是原始值。写入时调用来插入查询时用uniqMerge聚合。这种方式保持了增量计算能力新的分钟数据不断插入旧数据也能参与查询而不需要反复去重。这里有一个我踩过的坑如果直接把Flink算好的UV数值写入普通列而不是AggregateFunction列AggregatingMergeTree并不会自动合并去重只会保留最后一行的值导致重复计数。正确做法始终是写入uniqState对应的中间状态。3.4 实时看板与报警规则的落地看板不是把数据拉到前端就完了。rea的看板数据接口只负责三件事从Redis读最近几小时的分钟计数、从ClickHouse查询明细聚合、从配置系统读取指标口径。指标口径问题如果不趁早定义后期会吵死。例如“订单转换率”的分母是页面浏览用户数还是会话数这将导致不同版本的看板数据完全不同。我们的解决办法是维护一个口径说明文档并在指标命名中带上维度缩写例如conv_user_order表示“用户维度下从浏览到下单的转化率”这样看到名字就清楚口径不会混。报警则使用核心指标阈值加同比降幅逻辑。要监控的不只是绝对值掉零更多是突降或突升。我们设置了两级报警初级五分钟内UV相比前一分钟下降超过30%触发提醒高级一分钟内支付成功率低于50%直接钉钉/短信通知值班人。报警规则里还必须考虑时间窗口。凌晨两点流量本身就低下降30%可能是因为自然波动而不是故障。因此我们增加了同比比较与过去7天同时段平均值比超过三倍标准差才触发。4. 常见问题与排查技巧实录4.1 数据倾斜一个事件名拖垮整个Flink任务rea发生过一次典型的数据倾斜。某个业务方把大量逻辑都埋成同一个事件名导致这个key的消息量是其他key的一百倍。Flink的Keyed State集中在某个子任务上CPU和内存都被打满整个作业从12个并行度变成只有两个并行度在干活端到端延迟飙到三分钟。排查手段是看Flink Web UI里的子任务输入量。有没有某个子任务的numRecordsIn特别高而其他子任务几乎为零基本就能确认数据倾斜。解决办法没有一步到位我们做了两个调整给热点事件名增加二级分区维度例如加上用户ID哈希值让Key变成“事件名_用户ID哈希”这样聚合并行度分散开在聚合前先做本地预聚合把同一个子任务内部相同事件名和窗口的数据先合并一部分减少向上游发送的条数。第一种调整直接缓解了倾斜第二种减少了网络开销。但要注意加userID哈希后按分钟窗口算UV会受影响因为同一用户在窗口内可能被分到不同的哈希段。rea最终在计算UV时改用HyperLogLog跨子任务合并才保留精确去重能力。如果你没有这个需求按事件名加哈希是可以接受的。4.2 端上数据丢失页面进入后台与浏览器崩溃上线两周后我们调查了一个转化率忽高忽低的投诉发现移动端用户切到后台再回来时一批事件没有被发送。原因是浏览器在页面进入后台后会挂起定时器导致我们队列里的flush定时器不再执行。等到页面恢复队列早已被新事件占满老事件被新策略丢弃。修复方案有两个层面。第一层是发送时机调整不仅依赖定时器还要监听visibilitychange事件在页面变为hidden时立即执行flush尽量用sendBeacon把剩余队列发出去。第二层是离线持久化如果sendBeacon失败或因为网络断开无法发送就把事件写入IndexedDB。下次会话启动时读出来补发。这段代码是rea早期版本中就有的补发逻辑document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) { this.flush(); } });但是补发功能也不能盲目写。有段时间我们遇到重复事件因为页面在发送过程中服务端已经处理了一次但部分事件因网络超时被SDK重发。这两个环节会叠加导致同一条事件被统计多次。最终的解决方式是基于事件ID做幂等。SDK给每条事件生成一个全局唯一的eventId例如时间戳加随机数服务端在Flink清洗阶段对eventId做布隆过滤器去重已出现过的事件直接丢弃。布隆过滤器有极低的误判概率对于指标统计来说可以接受在热点数据上还能显著减少状态存储。4.3 指标对不上版本不一致和时区问题一个特别常见但也特别令人头大的问题是看板和离线报表的数据总是差一点点。经常是实时链路显示的成交数是1000第二天离线跑出来的数是1030。业务方就会质疑实时系统是不是丢了数据。rea排查了几次之后发现两组问题。第一组问题来源于客户端版本不统一。某个老版本app还在用旧的字段命名例如把channel传成channel_id导致Flink清洗时把一批事件判成脏数据踢掉。这个不是数据丢失是可以修复的。我们后来在清洗任务里做了一份“历史兼容映射表”把老字段名映射到新字段名同时记录schemaVersion查询时也能知道口径是来自哪个版本。第二组问题是时区。端上时间戳是用户本地的Unix时间戳Unix时间是时区无关的但如果页面JS里做了dayjs格式化字符串字段例如“2025-03-09”后端在解析时又默认用了服务器时区就会产生偏差。rea最终约法三章所有内部字段时间一律用Unix毫秒只有展示层再把时间戳转为业务时区绝不在传输和清洗层格式化日期字符串。还有一个常见的隐性坑事件时间与入库时间不一致。有些事件在断网情况下经过补发事件时间是10分钟前但入库时间在10分钟之后。如果用入库时间做统计实时看板的“当前时刻活跃用户”就会被拉低。正确做法是统一使用事件时间做聚合和过滤服务端只保留事件到达时间作为运维监控指标。4.4 在线排查速查表真实项目里问题不会按文档顺序出现。下面这张表是rea运行期间总结出来的高频事件排查步骤可以算作一份低配版的SOP。现象可能原因排查方式处理建议看板数据长时间不动Kafka topic消费积压查看消费者LagFlink各算子反压状态检查Flink是否数据倾斜追加大分区或并行度单条事件缺失端上采样或队列丢弃看SDK日志确认采样比例和队列上限调整采样策略增加队列上限或缩小批量间隔指标突降超过阈值服务端接口异常或被限流检查采集服务错误率、响应时间扩容采集服务检查Nginx限流配置查询ClickHouse超时聚合表排序不合理查看SQL执行计划是否走索引字段调整ORDER BY字段顺序增加物化视图实时看板与离线差数补发/重复/时区/版本问题抽样比对一个小时的明细数据确认事件ID去重、时间字段一致、schema兼容Redis计数清零了键过期或重启丢失检查TTL设置与持久化策略将热点指标键设置更大TTL或使用AOF持久化这张表不是万能的它只能帮助新接手的人快速定位方向。真正的根因分析通常需要同时看端到端的日志和链路追踪。我们在rea中给SDK上报时需要加trackingId每次发送批量事件都带一个batchId这样后续在Kafka、Flink和ClickHouse里都能用batchId来追踪一整批数据的生命周期。5. 扩展方向与架构取舍思考5.1 长周期留存分析实时系统不能包办一切实时链路解决了时效性但它不适合做全量留存分析。留存计算涉及几个月的数据跨度和大量用户去重如果全部塞进实时聚合状态存储成本高到难以接受。所以rea没有把离线数仓干掉而是让两套链路并行实时链路负责分钟级、小时级的趋势和异常离线链路负责日、周、月的精细留存与归因。两条链路共用同一份清洗逻辑只是存储引擎不同。这能避免“实时说涨、离线说跌”的口径冲突。我们能给出的经验是实时系统要先定准核心指标而不是把所有指标都往实时迁移。不是所有实时都会有价值有些指标半小时偏差不大离线完全够用。5.2 数据回放与校验机制运营有时会反馈“昨天活动期间的指标明显不对能不能重新算一遍”rea一开始没有这个能力后来加了数据回放。做法是把Kafka里的原始事件保留一定周期并且定期把日志落盘到对象存储。当指标异常需要重算时可以重启一条Flink作业从指定时间戳重新读取Kafka或对象存储数据输出到新的结果表。这样不仅修复了问题也不会影响正在运行的线上任务。重算作业要注意不能直接覆盖线上结果表而是先写入一个临时结果集确认数据合理后再切换访问指向。这个机制上线后我们处理过三次指标口径调整带来的历史数据重算效率比以前手动写SQL改表高很多。6. 写在最后一点个人使用体会重新复盘rea项目我最想强调的一点是实时系统真正难的从来不是引擎配置而是上游数据质量和下游口径共识。Kafka挂了大不了重启Flink状态坏了还能回放但埋点字段名写错、事件时间各自为政、采样逻辑不分场景这些问题会以各种隐蔽形式出现在看板里让你半夜排查都找不到源头。如果你也要做一个类似rea的系统我建议从第一天就把事件协议、时间字段、事件ID幂等和会话级采样规则定好最好写进团队约定文档里。这些琐碎的约定比任何大数据组件都更能决定系统的可用性。最后分享一个实操小技巧在开发环境里不用真的搭建整套实时链路来验证SDK是否正常工作。我通常会准备一个本地接口SDK直接上报到本地再写一个几十行的脚本把收到的数据打出来专门验证批量、重试、sendBeacon和本地缓存这些行为。这套轻量验证法帮我省掉了至少一半的联调排障时间。希望这篇分享对你有用也欢迎你拿着踩坑记录再回来交流。