由于时间久远。该问题十分具有代表性。所以今天将其记录一下。
本人使用的是华为C70集群，spark1.5.1的版本，由于版本问题。原先批处理一个小时的程序变慢一倍。达到2小时的处理时长。以jstack和jstat的方式大量观察，排除了gc和oom的问题。
那么问题到底出在哪里?
截图为内网。我无法拿出来。
我用语言描述一下：
即为可以从spark UI界面观察得出。job界面中 多个stage之间存在了很多空白时间!以下这个图是百度的。就是放这里图个感觉哈哈~~
可以得出每个stage的提交时间和运行时间。但是我的程序当中。即便提交时间+运行时间与下一个stage之间差了几分钟之差，并且跑到大表会更长，小表会短一点，所以就去排查日志。driver的日志是正常的。没有任何报错和延迟信息。我就去查节点网络的io问题，去ping然后查丢包。结果也是正常，到底是什么原因呢？？到底空白时间在做什么？
经过去具体某个节点点开excutor的日志查询，发现底部有大量类似于
deleting …
replacing…
相关字眼。而且info信息的时间戳恰好对应了空白时间的区域。
我去查了相关源码才得知。
当写入hive时候。即便是sparksql任务已经完成。底部还是在进行对hfile块文件，大量的搬运复制，删除操作。由于增量与全量的合并。每次全量的hfile都要进行一次这种hfile相关的大量操作。而其原因是由于底层该表的小文件个数较多。导致系统需要操作就随之变多。回到spark1.5.1，sparksql shuffle过程会产生大量小文件而且，如果不加以控制。全量表的小文件会越来越多。进一步延长程序时间。所以在诊断出这类问题以后，采用coalesce方式动态根据表的数据量控制分区数。
进行减少dataframe的分区的操作，解决了该类问题。此问题是在3个月之前出现的。所以以此记录。让后人减少爬坑时间。
最终数百个stage 每个缩短了具体数分钟的时长。原先程序又恢复了运行1小时的时长。
问题说的不是很好。如果有小伙伴出现这类问题，可以咨询我。
内网工作。截图和相关信息无法贴出。望见谅!
