分析&回答
这是 Flink 相关工作中最常出现的问题,值得大家搞明白。
1. 先找到超时的subtask序号
图有点问题,因为都是成功没失败的,尴尬了。
借图:
2. 找到对应的机器和任务
方法很多,这里看自己习惯和公司提供的系统。
3. 根据日志排查问题
- netstat -nap| grep 端口号 就找到对应的pid了,
- 然后ps aux | grep pid 就找到任务目录和日志了。
比如下一种情况:
- 接着去jobmanager上查看这个checkpoint的一些延迟信息
- 根据这些失败的task的id去查询这些任务落在哪一个taskmanager上,经过排查发现,是同一台机器,通过ui看到该机器流入的数据明显比别的流入量大
- 因此是因为数据倾斜导致了这个问题,追根溯源还是下游消费能力不足的问题
反思&扩展
Flink Checkpoint 失败有很多种原因,常见的失败原因如下:
- 用户代码逻辑没有对于异常处理,让其直接在运行中抛出。比如解析 Json 异常,没有捕获,导致 Checkpoint失败,或者调用 Dubbo 超时异常等等。
- 依赖外部存储系统,在进行数据交互时,出错,异常没有处理。比如输出数据到 Kafka、Redis、HBase等,客户端抛出了超时异常,没有进行捕获,Flink 任务容错机制会再次重启。
- 内存不足,频繁GC,超出了 GC 负载的限制。比如 OOM 异常
- 网络问题、机器不可用问题等等。
Checkout 在 Flink 中非常重要,其他指标大家也需要多关注。
喵呜面试助手:一站式解决面试问题,你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] -> 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享!