Kafka 监控显示 Lag 为 0Routine Load 状态是RUNNING报表最大业务时间却停在十分钟前。两个绿色指标都是真的但它们没有回答数据什么时候在 Doris 中可见。Kafka Lag 只描述消费位点距离队尾多远不描述消息是否通过过滤、事务是否发布、目标表是否得到正确结果。零 Lag 后面还有三段时间Kafka 最新 Offset → Routine Load Task 拉取并解析 → Doris 事务提交 → 副本发布到 VISIBLE → 查询读到数据Routine Load 任务提交事务时会把消费进度与事务信息一起写入 FE Edit Log。Routine Load 原理文档 的 Exactly-Once 建立在位点和事务共同提交上不是仅靠 Kafka Consumer Group。四个延迟指标不能互相替代这组对比的共同条件是同一条哨兵消息、同一 Kafka Offset 和同一次 Routine Load 写入只观察各层指标何时变化。指标它能证明什么它不能证明什么Kafka LagConsumer 已接近队尾消息已成功解析和提交Routine LoadRUNNINGJob 可调度每个 Task 都在产出可见事务Load 成功率事务没有整体失败脏数据未被过滤、业务时间最新表中MAX(event_time)当前查询看到的最大业务时间时钟正确、所有分区都完整真正的新鲜度应使用源端哨兵事件记录生产时间、Kafka Offset、Doris 首次可见时间再计算端到端延迟。先跑这一组只读检查SHOWROUTINELOADFORtarget_job;SHOWROUTINELOADTASKWHEREJobNametarget_job;SELECTMAX(event_time)ASmax_event_time,COUNT(*)ASrows_last_10mFROMtarget_tableWHEREevent_timeNOW()-INTERVAL10MINUTE;SHOW ROUTINE LOAD重点看 State、CurrentTaskNum、Statistic、ErrorLogUrls、KafkaProgress 与 Lag。检查路径Job 为PAUSED先读暂停原因和错误 URL不要直接 RESUME。Lag 高消费、网络、Task 并行度或 BE 写入能力不足。Lag 低但错误行增长消息被消费后过滤检查格式和容错阈值。Lag 低且事务提交慢检查 FE 发布、BE 副本和 Load 队列。数据可见但报表旧检查查询分区、缓存、时区和业务字段。一个最容易被忽略的案例JSON 上游新增字段并改变嵌套结构。Routine Load 仍能拉取消息Kafka 位点持续前进但路径映射失败的行进入过滤统计。若max_filter_ratio允许部分错误任务可能保持运行报表却缺数据。验证不能只查状态SELECTsource_partition,source_offset,event_id,event_timeFROMtarget_tableWHEREevent_idsentinel-20260827-001;哨兵事件同时携带 Partition、Offset 和唯一 ID能判断它是没被消费、被过滤、未发布还是查询端没读到。Routine Load 与 Flink Connector 的边界需求Routine LoadFlink ConnectorKafka CSV/JSON 直接入表链路短Doris 自己调度多一套 Flink 运维复杂转换、维表 Join、状态计算能力有限更合适位点与 Doris 事务闭环内置依赖 Checkpoint 2PC排障入口FE Job/Task/TransactionKafka、Flink、Connector、Doris 四层少一个 Flink 不等于没有状态机。Routine Load 把状态机放进 FE排障时仍需沿 Job、Task、Transaction、Visible 四层查看。源码只追 Job 到事务的交接Doris4.0.8源码阅读聚焦 FE 的 Routine Load Job 状态迁移、Task 调度、Kafka Progress 更新和事务回调。关键问题只有一个Offset 在什么条件下与成功事务一起持久化。只看 Kafka Consumer 拉取代码无法解释可见性延迟。零 Lag 是消息系统的终点不是实时数仓的终点。报表的新鲜度只由那条哨兵记录何时可见来证明。官方资料Routine LoadRoutine Load Principles and Best PracticesLoad Transactions