项目代号叫rea全称其实是当时我们团队内部随手起的Real-time Event Analytics也就是实时事件分析。为什么起这个名字纯粹是因为大家开会时天天喊“那个实时项目”嫌费口舌干脆缩写成rea叫着叫着就成正式代号了。这个项目要解决的核心问题很直白业务侧每天都离不开各类指标比如用户点击、下单转化、交易成功、系统异常但如果全依赖离线跑批早上看数据只能看到昨天甚至前天的遇到大促活动或线上故障等你看到异常影响面早就扩散了。rea要做的就是把事件从产生到被看见的延迟压到秒级同时保证实时口径和离线口径基本对齐不能今天实时看一个数、明天离线看另一个数。这篇文章我会把这个项目从设计思路、技术选型、核心编码到线上踩坑的完整过程梳理一遍。适合正在搭实时链路、或者准备把离线数仓升级成实时数仓的开发者参考就算你团队还没到要上实时计算的阶段里面关于数据模型设计和排查思路的部分也能给你一些启发。1. 项目定位和整体设计思路1.1 为什么偏偏要上实时离线报表哪里不够用先扯个场景。之前做的是电商类业务用户从进入首页到下单支付中间要经过曝光、点击、加购、提交订单、支付成功好几个环节。产品同学非常关心每个环节的转化率领导也关心实时成交额。以前的做法是每天凌晨跑离线任务第二天早上十点前把报表刷新出来大家围着数看。这在平时没问题可一到双十一这类大促场景问题就非常明显。大促当天的流量曲线是分钟级变化的凌晨开场一小时冲得最高然后回落晚上再来一波。如果离线报表要到第二天早上才能看到转化漏斗等发现某个环节点击率掉了促销活动早就结束了。还有一类场景更致命支付成功率突然掉了一半这时候必须马上看到是哪个支付渠道出了问题、影响多少订单。离线的响应速度根本扛不住这种容灾需求。所以rea的定位不是要替代离线数仓而是补齐离线缺失的那一段“当下视角”。离线算的是历史累计实时算的是此刻状态两边并行用一套口径去约束。这个定位想清楚之后整个项目的边界就定了不做全量历史数据的实时重算只对增量事件做流式处理。1.2 从事件产生到指标可见拆成四段链路rea的整体链路可以分成四段采集、缓冲、计算、输出。采集端负责接入各业务系统上报的事件数据这一层最大的问题不是技术难度而是业务系统五花八门有直接HTTP上报的有通过日志采集器推过来的还有跨部门之间通过消息队列转接的。所以接入层必须足够“钝感”不能因为某个业务方接得慢就阻塞其他链路。第二段是缓冲层我直接用了消息队列。原因很简单采集端流量是波动的可能白天每秒几百条活动开场瞬间每秒几万条要是让计算引擎直接扛流量成本会非常高而且计算引擎的扩缩容没有消息队列灵活。消息队列在这里扮演的是水库角色洪峰来了先蓄水下游按自己的节奏消费。第三段是流式计算引擎负责把原始事件做清洗、关联、聚合产出业务能直接看的指标。这一段是整个项目里最耗时的部分不是说配置有多难而是你需要同时操心乱序、延迟、状态、容错一堆问题后面我会详细展开。第四段是输出计算结果既要写实时数仓供即席查询也要推给告警模块做阈值触发还要落到在线缓存里让大屏和看板实时刷新。四段链路互相解耦任何一段挂了都不能让事件源阻塞这也是rea在设计上最先确定下来的原则。2. 技术选型与关键组件解析2.1 消息队列选型吞吐量还是有序性缓冲层我评估过几个主流选择包括以日志型存储为核心的队列和偏传统发布订阅型Broker。先说结论最后选了Kafka。理由有三个第一它的吞吐量在同量级方案里是最稳的单分区能支撑的写入速度足够我们用了第二日志段存储让消费位点可以回退出问题时能从几天前的位点重新消费这在排查数据质量问题时是救命能力第三生态最完整上下游组件都有现成连接器不需要自己写底层对接。但Kafka也有自己的脾性最明显的是分区内有序、分区间无序。如果某个业务方对事件顺序非常敏感比如同一个订单必须先有创建事件再有支付事件那就要在生产者端按订单ID做分区键保证同一订单的所有事件进同一个分区。我们在接入规范里把这条定成了硬性要求凡是进入rea的事件必须带上业务主键生产者按主键哈希选分区。这样虽然牺牲了一点分区均衡性但换来了下游处理逻辑的简化。还有一件事必须提前做容量预估。Kafka的磁盘占用取决于保留策略和写入速率我们最初只给消息队列配了三天保留期日均事件量大概几十亿条算下来单台Broker的磁盘要有足够余量。但更关键的是消费端积压告警一旦消费者挂了消息队列里堆积量会指数级增长。所以rea上线第一天我就配了消费延迟监控延迟超过阈值直接报警宁可误报也要先知道。2.2 流式计算引擎状态与精确一次语义计算引擎是整个rea的“脑子”这里的选择直接决定项目能不能落地。我当时重点看了两类引擎一类是批流一体的引擎支持SQL写实时任务另一类是原生流式引擎以Java/Scala API为主。团队里写SQL的人多写Java的人也能凑几个于是折中选了Flink因为它既能跑SQL也保留了底层DataStream API复杂逻辑还能写UDF兜底。选Flink还有一个关键点状态管理。实时计算中大量场景需要跨事件维护状态比如计算某个用户一分钟内点击了多少次你得在内存里记住这个用户的上下文。Flink的状态后端支持内存和RocksDB两种状态量大的场景用RocksDB它把状态落盘到本地磁盘内存只做缓存算是性价比最高的方案。但RocksDB的读写性能比纯内存慢所以我们在设计聚合逻辑时尽量让每个算子的状态范围变小能用滚动窗口解决的问题就不用全局累加器。实时计算还有一条硬门槛精确一次语义。消息从Kafka消费出来如果处理到一半作业挂了重启后可能会重复消费如果先输出结果再保存位点就会漏数据。Flink的检查点机制解决了这个问题它把状态和Kafka位点一起做快照恢复时保证每条消息对状态的影响恰好一次。但注意这只保证引擎内部恰好一次如果结果写到外部存储时又发生了故障外部存储侧还是可能出现重复写。所以我们在输出层又叠加了一层幂等具体做法放在后面。2.3 结果存储实时数仓与在线缓存分工计算结果往哪放我们分了两条路。一条是写到列式存储引擎ClickHouse负责实时数仓的明细查询和聚合查询。选ClickHouse是因为它在聚合查询上的性能太突出了几亿行数据做多维度Group By只要查询写得不离谱基本都能在秒级返回。另一条是写到Redis供大屏、看板这类需要毫秒级响应的场景读取指标直接按key存好前端每次轮询都是读缓存压力很小。这里容易踩的一个坑是不要把ClickHouse当OLTP用它是分析型数据库不适合频繁更新单行。我们所有写入都是批量追加式比如一分钟一个批次用Kafka表的物化视图或异步批量插入把结果写进去。如果业务侧需要查单个订单的最新状态那应该走在线缓存或者原始库查而不是查实时数仓。这个界限一开始没跟业务讲清楚导致好几次有人反馈“怎么实时明细里查不到刚发生的那条”其实就是写入延迟和存储定位的问题。3. 核心细节与实操要点3.1 事件模型设计以及字段命名的那些规则rea处理的是业务事件不是数据库表变更日志。事件模型如果设计得不好后面每条SQL都会写得难受。我总结下来的核心原则是少嵌套、平铺字段、统一类型、别省时间戳。先说嵌套。很多业务系统为了图省事上报事件时习惯带一个大的JSON对象里面再套好几层。这在我们接入端就得一层层拆每拆一层都要处理字段不存在的情况。所以接入规范里明确要求所有事件必须是扁平化结构最多允许一层数组不能有对象套对象。数组这种结构在实时计算里处理起来也很麻烦尤其是做UNNEST展开后还要和原事件关联容易产生数据膨胀所以能用多个事件表达的就别塞数组。类型统一同样重要。同一个字段“用户ID”有的业务方上报字符串有的上报数字字符串里还可能混着空格和后缀。我们上线初期没有强制校验结果到计算层做关联时明明是一个用户左边是数字型“12345”右边是字符串型“12345”关联不上转化率直接算错。后来加了一个前置清洗算子对核心字段强制做类型归一化非法的数据进不去计算层这才把问题断了根。时间戳这一块要说一下。每个事件必须带两个时间事件产生时间和业务时间。事件产生时间一般是客户端或服务端打点时间业务时间是指这个事件对应的业务行为发生时间。这俩经常不一样原因有很多客户端离线缓存、网络重传、消息队列重试都会导致事件时间漂移。rea的一切滚动窗口都基于业务时间计算只有这个时间才代表真实行为发生顺序。3.2 时间语义的坑处理时间和事件时间第一次写实时任务的人最容易踩的坑就是默认用了处理时间。处理时间很好理解就是消息到达计算引擎的当前机器时间。问题在于同一个事件如果因为网络抖动在队列里待了几秒那么它的处理时间就会往后挪落在哪个窗口就取决于它运气好不好。用处理时间算出来的统计值乍一看没问题但波动会非常诡异。rea里全量使用事件时间语义消息从Kafka读出来后第一步就是提取业务时间字段把它声明成Watermark的基准。Watermark这个概念可以理解成引擎对数据进度的估计它说“我目前收到的数据里最晚的业务时间已经到了T而且我认为小于T的数据不该再来了”。Flink用Watermark触发窗口计算比如每五分钟一个窗口只有Watermark超过窗口结束时间才会触发这个窗口的输出。Watermark周期设置直接决定结果延迟。设短了比如一秒好处是数据很快出结果坏处是乱序数据还没到就触发计算了窗口结果会偏低。设长了比如五分钟结果准确性好了但看到数据的延迟也会拉长。我们在rea里给它设置了三秒的延迟容忍绝大多数业务事件的乱序都在三秒以内个别迟到很久的数据走侧输出流单独处理不让它污染主结果。这个取舍要结合业务场景说明白不是所有场景都适合同一个值。3.3 状态、去重与外部存储协同实时链路里最脏的活就是去重。Kafka消费重启之后可能重复读数据源本身也可能重复上报。因为rea的上游系统非常多一个个要求它们保证精确上报根本不现实只能自己在计算层挡。去重方案我评估过两种用Flink状态和用外部去重表。用Flink状态去重的好处是快内存或RocksDB里存一个Set重复数据直接过滤掉。问题是作业状态会无限增长如果按订单ID去重订单量无限多状态哪天超了会直接把作业压死。所以只适合去重基数可控的场景。外部去重表用的是一张存储主键和写入时间的表进来一条数据先查主键是否存在存在就跳过。好处是状态在外部、不占作业内存坏处是每一条数据都要多一次网络IO吞吐量会下降。我们最终的动作是分层对核心交易链路要求上游绝对精确一次引擎侧只做容错兜底对日志类、行为类数据用外部去重表配合批量查询做去重。这里有个优化点不要一条条查可以按微批攒几百个主键一次查性能会好很多。踩过几次坑之后我得到一个体会实时系统的去重方案一定要在设计期想清楚不要在故障期才临时加临时加十有八九会让吞吐量崩掉。4. 实操过程与关键环节实现4.1 最小可用链路从零搭建到第一个指标上屏如果你只是想先跑通一个最小可用链路不需要一上来就铺全部集群。我在项目初期是这么干的一台测试机器的组件模拟消息队列和引擎本地起了作业消费数据源计算结果打到本机窗口终端上看输出。等逻辑验证没问题了再往集群环境平移。第一步是建Topic和准备数据源。Topic名称命名规范是项目名加事件名分区数按日事件量和消费者并行度算。举一个例子某业务的下单事件日均一亿条写入流量大概每秒一千条读流量是计算作业并行度乘以单分区吞吐这个我们自己控制的。初始建了24个分区给了后续扩展空间。第二步是搭流计算作业骨架从Kafka读事件解析成结构化对象暂时不做任何聚合只把两个时间戳字段打印出来目的是验证读取和解析链路是通的。第三步就是上手写一个最简单的五分钟滚动窗口统计。SQL范式大概是从Kafka表读取事件流按事件类型过滤对窗口内的事件做计数结果写到结果表中。这个跑通了意味着链路打通了能在一个小时之内把一个实时指标推到看板上。当时我用了很多时间在看板服务上其实看板不重要重要的是链路里每个环节都能告诉我们“数据走到哪了”。4.2 核心流处理逻辑的代码级解析为了让讲解更具体我简化一段rea里实时转化漏斗的伪代码。它的作用是统计从点击到支付的每一步转化人数窗口一分钟滚动一次。// 伪代码省略工程化细节 val events kafkaSource() .filter(_.eventType in (click,cart,order,pay)) .assignTimestampsAndWatermarks( forMono ) // 按用户ID和业务类型分流 val keyed events .keyBy(e e.userId) // 在一个滚动窗口内为每个用户保留最近行为序列 val funnel keyed .window(Tumble.over(1.minutes).on(e e.bizTime)) .aggregate(new FunnelAggregate) funnel .map(convertToResultRow) .sinkTo(clickhouseSink)这段代码里最关键是aggregate函数。在实时场景下不能等到窗口结束才去扫所有事件那样内存消耗太大。正确做法是在窗口每个事件进来时增量更新一个状态机如果遇到click事件就标记这个用户有点击如果已点击、又来了cart就认为点击到加购转化成功以此类推。每个用户一分钟窗口内只保留一个很小的状态值内存开销可控。我还想强调窗口聚合里的一个细节——增量聚合和全量聚合作业的差别。增量聚合是每个事件都更新当前结果比如计数器加一窗口结束时把结果发出去。全量聚合则要缓存窗口内所有事件结束时一次性遍历计算。后者在数据量大时基本不能用内存会爆。所以我们所有窗口计算都尽量写成增量聚合实在需要全量逻辑的也要控制窗口内数据量在百万以下。4.3 参数调优与资源预估的经验值Flink作业的并行度和资源配置我摸索了一套经验值。先说并行度它不能拍脑袋要看两件事Kafka Topic分区数和单算子吞吐瓶颈。如果你的Topic是24个分区Source并行度设24是合理的再少浪费分区再多也是空跑。后续KeyBy算子并行度可以大于24因为KeyBy之后数据会按Key重新分配这时候瓶颈往往在聚合逻辑和状态访问上而不是Kafka源。内存配置上如果状态用的是RocksDB堆内存主要给计算和网络缓冲RocksDB自身的内存是堆外管理的。我们曾经把作业总内存设得很大但堆外没调结果RocksDB性能上不去频繁落盘整个作业延迟飙升。后来按标准经验把堆内和堆外分开调才稳定下来。还有一个特别容易被忽视的点Checkpoint间隔。默认一分钟一次是比较稳的但频繁Checkpoint会影响性能。rea把Checkpoint间隔设成三分钟配合Flink的增量Checkpoint机制对正常流量几乎没有影响。但要注意Checkpoint失败是会累积的如果连续失败几次作业会自动重启你必须在监控页里盯着这个指标不要等业务方来问“实时数据怎么不动了”。5. 常见问题与排查技巧实录5.1 消费积压先判断瓶颈在哪个环节rea上线后遇到最多的问题就是消息队列积压。现象很典型监控页面上Kafka消费延迟从几十条涨到几百万条实时指标变成“半实时”大屏数字停在一个值不动了。排查遵循的顺序是先看计算作业是不是还活着再看资源使用率最后看输出存储是不是写不动了。资源使用率这条最迷惑人。很多时候CPU没满、内存没满但吞吐量就是上不去这时候十有八九是本地磁盘或临时文件的IO卡住了。我遇到过一次RocksDB的线程池打满导致所有状态读写排队表现就是Source端消费速度骤降。解决办法不是盲目加并行度而是先看是否有热点Key导致某个子任务负载失衡再加资源才有效。输出存储卡住也很隐蔽。特别是ClickHouse插入变慢时下游反压会顺着链路传导到计算引擎最终表现为Kafka消费变慢。这个不细看真想不到所以我们后来给每个下游存储都单独加了写入耗时监控哪个环节慢了立刻能对上。5.2 重复结果往往是幂等没做到位实时计算结果偶尔出现重复是另一类高频问题。明明上游没有重复消息但业务侧看到同一笔订单被统计了两次。这种问题大多出在“输出重试”上。Flink写ClickHouse或Redis时如果网络抖动导致写入超时引擎会重试重试可能成功也可能失败。如果第一次实际写成功了但响应超时引擎重试就会写第二次于是结果重复。解决思路是在结果表结构里加一个唯一键。ClickHouse本身不擅长去重写入我们用了它的ReplacingMergeTree表引擎相同主键的多行会自动合并。这个表引擎不是强实时去重最终会在后台合并但查询时用一个Final关键字就能拿到去重后的数据对多数业务足够用。Redis那边更简单指标Key的值是幂等的后面写入覆盖前面天然不会重复。这类问题告诉我一个原则实时系统的输出端永远不能假设“恰好一次”所有结果消费方都要设计成能容忍重复。业务方如果对精确度有硬要求就必须在结果表里设计唯一键或幂等合并策略。5.3 数据倾斜窗口聚合为什么老慢一个子任务实时流里数据倾斜比离线环境更恶心因为它不会像离线一样能在日志里看到某个Reduce卡住很久而是表现为整个作业吞吐下降但一看每个子任务的负载发现某个TaskManager忙到100%其他都闲着。常见原因之一是Key分布不均。比如我们按用户ID做KeyBy理论上很均匀但某个超级大促的活动页可能有一个用户疯狂点击了几十万次导致一个子任务要处理海量数据。这种情况就要做两阶段聚合先加一个随机后缀打散Key做一轮局部聚合再去掉后缀做全局聚合。这个优化对热点Key效果立竿见影。另一个倾斜来源是状态读取不均衡比如某些用户长期在窗口状态里占用大量RocksDB空间读写都慢。对这块我们做了监控定期拉取各子任务状态大小分布一旦发现某几个子任务状态明显偏大就检查逻辑是不是该加长窗口或者改用外部状态。数据倾斜不可能完全消除但至少要做到看得见、能缓解。写在最后的几点体会rea这个项目从我接手到稳定运行周期不算长但中间踩的坑全部累积成了团队内部文档。我个人的体会是实时项目最大的挑战并不是技术框架本身而是“对实时性的预期管理”。业务方以为实时就是零点零几秒出数据实际上绝大多数指标做到分钟级甚至几十秒级就非常有价值了。这个预期如果不提前对齐后面你会被各种“怎么还没刷新”的追问埋掉。另外一点如果你团队是第一次从离线转实时不要追求一步到位把所有指标都实时化。先把最有业务价值的几个核心指标跑通形成一套从接入、计算到展示的规范再逐步扩展到其他领域。实时链路每多一个指标维护成本不是线性增加的而是像滚雪球一样涨所以规范化比数量重要。最后再分享一个小技巧实时作业的监控一定要比作业先上线。你哪怕只跑一个最简单的WordCount作业也要把Kafka消费延迟、Checkpoint成功数、作业重启次数这几个指标接到告警上。因为这些是最底层的地基地基不牢后面做再多业务逻辑都是沙上城堡。