跳到主要内容

实时数据延迟排查

场景描述​

实时看板显示的 GMV 数据比实际延迟了 30 分钟，正常应该在 1 分钟以内。

实时链路全景​

分段排查​

① 采集端延迟​

原因排查方法
客户端批量上报检查 SDK 上报间隔配置
网络波动检查上报成功率
服务端接收瓶颈检查接入层 QPS 和延迟

② Kafka 消费延迟​

# 查看 consumer group lag
kafka-consumer-groups.sh --bootstrap-server broker:9092 \
  --describe --group flink-realtime-job

# 关键指标：LAG = LOG-END-OFFSET - CURRENT-OFFSET
# LAG 持续增长 = 消费跟不上生产

常见原因：

  • 消费者并行度不够 → 增加 Flink 并行度
  • 单条消息处理太慢 → 优化处理逻辑
  • Kafka 分区数太少 → 增加分区

③ Flink 处理延迟（背压）​

Flink Web UI → Job → Task → BackPressure
- OK：正常
- LOW：轻微背压
- HIGH：严重背压 ← 需要关注

背压排查：

  1. 从 Sink 往上看：如果 Sink 背压最高 → 下游写入瓶颈
  2. 中间算子背压：某个窗口聚合太慢 → 优化聚合逻辑或加并行度
  3. Source 背压：读取本身就慢 → 检查 Kafka 分区分配

常见修复：

// 增加 Flink 并行度
env.setParallelism(16);  // 从 4 调到 16

// 优化 Checkpoint 间隔（太频繁会拖慢处理）
env.enableCheckpointing(60000);  // 从 10s 改为 60s

// 异步写入 Sink
AsyncDataStream.unorderedWait(stream, asyncSink, 5, TimeUnit.SECONDS, 100);

④ 查询端延迟​

原因处理
ClickHouse MergeTree 合并慢减少写入频率，批量写入
Redis 查询超时检查连接池、大 Key
BI 缓存过期策略调短缓存 TTL

常见面试问题​

Q1: 如何监控实时数据链路的端到端延迟？​

答案：

在消息中嵌入 event_time（事件发生时间），在各节点记录 process_time（处理时间）：

端到端延迟 = BI 查询时间 - 事件发生时间

按段拆分：

  • 采集延迟 = Kafka 入队时间 - 事件时间
  • 消费延迟 = Flink 消费时间 - Kafka 入队时间
  • 处理延迟 = 写入 OLAP 时间 - Flink 消费时间

答案：

  • Flink 背压 → Kafka lag 增长：Flink 处理不过来，消费速度下降，导致 lag 增长
  • 反过来不一定：Kafka lag 大也可能是 Flink 任务挂了、consumer group 被 rebalance

排查顺序：先看 Flink 任务是否正常运行 → 再看背压 → 最后看 Kafka lag。

相关链接​