Spark作业运行异常慢的问题定位和分析思路

一直很慢 🐢

运行中状态、卡住了,可以从以下两种方式入手:

如果 Spark UI 上,有正在运行的 Job/Stage/Task,看 Executor 相关信息就好。💻

  1. 第一步,如果发现卡住了,直接找到对应的 Executor 页面:
  2. 第二步,不断的刷新,看看 Task 线程栈执行的内容是什么:

如果 Spark UI 上,没有正在运行的 Job/Stage/Task,看 Driver 相关信息就好。🖥️

  1. 第一选择是看 Driver 的 ThreadDump,分析 Driver 在执行什么逻辑。
  2. 第二选择,如果发现 Driver 的线程栈没异常的时候,可以结合 driver 日志查看日志最后的信息是什么。

运行结束了 🏁

  1. 首先看看是否有执行时间明显比较长(或者对比历史执行时间比较长)的 Job, Stage:
    • 查看 Jobs 页面,寻找运行耗时相对较长的作业(注意:这里的 Duration 时间是 Job 启动时间和结束时间的耗时,不代表真正的耗时,例如可能存在多个 Job 同时运行,就会出现受资源影响的情况,可能 Duration 比较长,实际真正执行时间比较短的情况):
    • 查看 Stages 页面,确定运行时间比较长的 Stage(注意,这里的 Duration 和 Job 的 Duration 是一样的,只代表执行起始时间的跨度,不代表实际执行耗时)
    • 查看 Duration 时间比较长的 Stage 的实际执行时间,找到执行时间较长的 Stage:
    • 还可以查看所有成功 Task 的执行 Metrics 的直方统计图,以便分析数据倾斜等情况,同时注意 GC 时间的占比,分析是否存在内存问题。

注意 ⚠️

上面提到了执行慢可能是 资源问题 也可能是 逻辑或者数据问题,如何确定呢:

  1. 如果上述的 Stage 的详情耗时与历史执行对比,基本一致,那么基本可以判断为资源问题。
  2. 如果直方图中显示的 Task Duration 有可判断为数据倾斜的情况(个别 Task 慢,且输入或输出数据远大于其他 Task),可能是数据倾斜导致的。
  3. 如果并不符合数据倾斜的特征,但是某个节点的 Task 执行都慢,可能是机器负载异常导致。
  4. Spill 指标比较高,可能是内存压力大,spill 至磁盘导致计算变慢,这种情况需要总结和评估是否加内存或者接受稍慢的情况。

比历史慢 🐢

排查步骤:

  1. 首先对比两次执行的 Job 或者 Stage 是否有明显的运行时间区别。
  2. 对比执行逻辑是否有改变(例如 broadcast join 变为 sortmerge join),sql 可以查看执行计划,rdd 可以分区 job 的 dag。
  3. driver 内存压力大,导致调度能力下降(目前可以关注 Driver 的 gc 日志)。
  4. 对比是否有数据量的变动,查看 stage 的输入输出就可以了:
  5. 资源的差异,可以查看对应的 stage 的 executor 统计或者队列资源的监控。
  6. 数据倾斜:
相关推荐
反方向的空9 分钟前
GIt基本操作
大数据·git·elasticsearch
Leo.yuan3 小时前
数据仓库建设全解析!
大数据·数据库·数据仓库·数据分析·spark
活跃的煤矿打工人3 小时前
【星海出品】分布式存储数据库etcd
数据库·分布式·etcd
刘某的Cloud5 小时前
rabbitmq常用命令
linux·运维·分布式·rabbitmq·系统
望获linux6 小时前
智能清洁机器人中的实时操作系统应用研究
大数据·linux·服务器·人工智能·机器人·操作系统
三个蔡7 小时前
Java求职者面试:从Spring Boot到微服务的技术深度探索
java·大数据·spring boot·微服务·kubernetes
慧一居士9 小时前
Zookeeper HA集群搭建
分布式·zookeeper
冼紫菜9 小时前
[特殊字符] 分布式定时任务调度实战:XXL-JOB工作原理与路由策略详解
分布式
Lilith的AI学习日记9 小时前
AI提示词(Prompt)终极指南:从入门到精通(附实战案例)
大数据·人工智能·prompt·aigc·deepseek
白鲸开源10 小时前
任务运维、循环任务死锁.....DolphinScheduler任务配置经验分享
大数据