【FFA 2026】Real-Time Analysis 2 心跳× Watermark 小红书基于Flink 的实时日志传输架构演进实践

小红书基于Flink的实时日志传输架构演进实践赵宝珠(库奇)赵宝珠(库奇)小红书实时引擎工程师Hear士bea士独立于业务数据的链路进度信号统一的数据进度透传方案通用的数据完整度信号connector生产落地保障方案落的语义正确和效率背景&痛点背景-日志采集服务Agentsmith介绍uuAgentsmith是为后端埋点数据提供流/批入仓通道的服务u支撑的核心业务数据需求包括商业化广告、社区DAU、u采集节点以DaemonSet方式部署，数量约10wu数据经跨云专线分别写Kafka和对象存储，吞吐200+GB/s背景-老架构痛点采集脆弱流批分叉扩展触顶u整机共享一块磁盘，隔离性差采集脆弱流批分叉扩展触顶u整机共享一块磁盘，隔离性差容灾不足u单节点磁盘容量、IO瓶颈u单节点磁盘容量、IO瓶颈u对象存储ListObjects瓶颈u跨云带宽瓶颈解法&定位解法-基于Flink的实时日志传输架构数据传输数据处理数据采集数据传输数据处理聚合Kafka统一汇聚单元聚合Kafka统一汇聚单元Kafka高可用FlinkFlink处理流批一体链路简化：通过Mirror将各单元Kafka数据汇聚到聚合Kafka，实现统一处理从源头消除数据不一致问题生产保障：自动感知和异常恢复支持数据传输进度信号的感知、监控和管理，具备大规模生产落地能力语义输出：进度透传到下游不同Sink把数据进度转为Flink可识别的信号并支持向下透传核心变化：感知上游传输进度感知数据从client写入到最终消费中间链路的延迟，明确数据传输进度基础能力：低延迟的分流管道低延迟完成数据从Kafka到Kafka|Iceberg|Hive的传输截然不同，精准区分才能保证数据完整性和时效性Watermark的生成依赖有数据，无数据会导致watermark不推进，block下游离线调度无数据不等于无进度，无数据不等于无进度，引入【心跳】跟踪数据传输进度，埋点sdk自动发送心跳，跟随业务埋点数据一起流动进入Flink，再由Flink过滤心跳避免影响下游心跳数据格式//header//下游直接解析header即可message_type=“agentsmith3-heartbeat”heartbeat_version=1//body{“cluster_name”:“clusterA”,"topic":"topic1","hb_event_time":1747033550780,"hostname":"ads-service-1","podip":"xx.xx.xx.xx","zone":"qcsh5","region":"qc-sh"}心跳消息携带单元信息和时间戳，心跳消息携带单元信息和时间戳，表示当前单元链路的数据进度取所有期望单元的最小心跳生成WatermarkWatermarkWatermark和StreamRecord都是Watermark(T)：代表时间≤T数据都已到达u扩展能力支持watermark写入u扩展能力支持快照时从watermark反推分区路径并创建u基于2次checkpoint的watermark区间补全丢失的全部分区应对追数场景u低峰期无业务数据时也可以补全空分区并commit，不阻塞下游离线调度u扩展能力支持快照时把watermark写入表、快照属性u下游消费通过watermarkSensor感知watermark进度新架构中元数据决定“应该等待哪些单元心跳”新架构中元数据决定“应该等待哪些单元心跳”，直接影响数据正确性元数据格式元数据格式{"data":{"cluster_name":"cluster_name","topic":"topic","unit_cluster_name":["unit_cluster_name1","unit_cluster_name2","unit_cluster_name3"]}}单元Kafka集群需要从3个扩展到4个，Flink作业能否自动识别？u禁用语法`u禁用语法`watermarkforevent_timeasevent_time`避免watermark污染正确聚合并过滤心跳&推进watermarkuSplitReader层识别心跳，基于单元splitrawwatermark，经乱序逻辑转为watermark生成per-split心跳record转发到emitteruSplitReader层识别业务数据正常反序列化转发到emitterrecord走emitWatermark，业务数据走常规collect对齐对齐Flinkwatermark聚合语义u在SplitReader层[L1]新增“cluster内MIN聚合”以让watermark反映心跳真实进度u[L2/L3的Watermark聚合仍复用FLIP-27Source现有能力u下游看到的Watermark流与原生Flink语义保持一致uoutOfOrderness(简写oOO)配置为30s（数据展示忽略了1ms的diff)u聚合Kafka中有A、B两个单元Kafka数据，A链路始终正常，B链路在10:00异常，10:15恢复收益&展望新架构覆盖度已达85%级提升到分钟级级提升到分钟级量SLO从99%到99.9%运维效率：运维人力节约80%用户体验：用户体验：端到端接入从4h降到0.5h展望:真正做到“一份数据”从“链路语义流批统一”到“全链路流批统一”Kafka-c1Kafka-c2聚合KafkaKafka-c3KafkaSource业务podKafka-c1-clientKafka-c2-clientKafka-c3-clientKafkaSinkIcebergSinkHiveSink业务pod实时KafkaSourceKafka-c1-clientfka-c1FlussSink聚合Kafkafk