spark数据本地性-CSDN博客

本文链接：https://blog.csdn.net/weixin_44024821/article/details/97821289

在spark源码(六)–task提交算法的最后，我们提到过决定task运行位置的两个因素：1.task的最佳位置即数据所在位置；2.task的本地化级别。
task的本地化级别有5种：
PROCESS_LOCAL 进程本地化相当于数据（partition）和task在同一个executor中
NODE_LOCAL 节点本地化数据和task在一个worker节点上
NO_PREF 没有本地化级别
RACK_LOCAL 机架本地化数据和task在一个机架下
ANY 任意的本地化级别
由于移动缓存数据的代价比较大，所以task会尽量运行在距离数据更近的地方
在实际的生产环境中，如果RDD数据被cache，在执行任务的时候，大部分的task都会在缓存的这个节点上执行，少部分在其他节点上执行，导致每个executor执行的task个数相差很多，最终执行task多的这部分executor耗费的时间比较长，拖慢整个job的执行时间。这就是数据本地化可能会带来的麻烦之一。

这是我找的一个数据本地性导致性能下降的案例。下图是executor的执行截图
在这里插入图片描述
可以看见的是前三个executor执行的task数是其他executor的12倍以上，说明大部分的task都集中在了部分executor中，出现这种问题的原因很可能就是数据数据本地性导致的。这里要解释一下数据本地性和数据倾斜的区别：
数据倾斜：一部分task很快就执行完毕，同时另部分task执行时间很长，导致整个任务执行时间比较长。出现这种问题是因为大量数据汇集到少部分partition中，这就是数据倾斜。它是task之间执行时间上的差异
数据本地性：大量的task集中到少部分executor上去执行，而其他executor则只执行少量task，部分executor执行任务过多所以耗费时间久最终导致整个job执行慢。它是executor之间执行task数量的区别
在这张图中，我们可以清楚的看到complete tasks上的差异，所以认为这是task数据本地性造成的性能下降。
那怎么解决数据本地性的问题呢？
这里我们还得再明确两个概念，task扩大本地化级别等待的时间和task执行时间。在上个task正在executor中执行的时候，下一个task会等待3s，如果3秒钟之内上个task执行完毕，那么下个task还会接着进入这个executor去执行，如果上个task3s没有执行完毕，那么这个task就会尝试扩大一个本地化级别，试着进入其他executor去执行。所以，如果某个executor内有缓存的数据，而大部分task在这个executor内执行时间又小于3s，那么就会有大量task进入一个executor。
解决这个问题的方法是缩短task扩大本地化级别等待的时间
加入大部分task在executor-01的执行时间时1.5s,我们将task扩大本地化级别等待的时间设置为1s，那么在task执行期间，下一个task就会扩大本地化级别进入其他executor去执行了。
怎么设置我们看一下官网解释

在这里插入图片描述
spark.locality.wait 指的是task扩大本地化级别时等待的时间。如果执行任务花费的时间很长并且本地化位置不佳，就应该增加等待的时间；如果大量task集中到了少部分executor中，那就应该减少等待时间。还可以曾对某个特定本地化级别，比如进程本地化，节点本地化单独设置等待时间