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. 数据倾斜：