task的locality有五种

1）、PROCESS_LOCAL：进程本地化，代码和数据在同一个进程中，也就是在同一个executor中。计算数据的task由executor执行，数据在executor的BlockManager中，性能最好。

2）、NODE_LOCAL：节点本地化，代码和数据在同一个节点中。比如说，数据作为一个HDFS block块，就在节点上，而task在节点上某个executor中运行，或者是，数据和task在一个节点上的不同executor中，数据需要在进程间进行传输。

3）、NO_PREF：对于task来说，数据从哪里获取都一样，没有好坏之分。

4）、RACK_LOCAL：机架本地化，数据和task在一个机架的两个节点上，数据需要通过网络在节点之间进行传输。

5）、ANY：数据和task可能在集群中的任何地方，而且不在一个机架中，性能最差。

调节本地等待时长背景

Spark在Driver上，对Application的每一个stage的task进行分配之前都会计算出每个task要计算的是哪个分片数据。Spark的task分配算法优先会希望每个task正好分配到它要计算的数据所在的节点，这样的话，就不用在网络间传输数据。

但是，有时可能task没有机会分配到它的数据所在的节点。为什么呢，可能那个节点的计算资源和计算能力都满了。所以这种时候， Spark会等待一段时间，默认情况下是3s到最后，实在是等待不了了，就会选择一个比较差的本地化级别。比如说，将task分配到靠它要计算的数据所在节点比较近的一个节点，然后进行计算。

对于第二种情况，通常来说，肯定是要发生数据传输，task会通过其所在节点的BlockManager来获取数据，BlockManager发现自己本地没有数据，会通过一个getRemote()方法，通过TransferService（网络数据传输组件）从数据所在节点的BlockManager中，获取数据，通过网络传输回task所在节点。

对于查询时，并不希望是类似于第二种情况的发生。最好的，当然是task和数据在一个节点上，直接从本地executor的BlockManager中获取数据，纯内存，或者带一点磁盘IO。如果要通过网络传输数据的话，性能会下降。大量网络传输，以及磁盘IO，都是性能的杀手。

调节数据本地等待时长的适合场景

观察spark作业的运行日志。推荐大家在测试的时候，先用client模式在本地就直接可以看到比较全的日志。日志里面会显示：starting task…，PROCESS LOCAL、NODE LOCAL。观察大部分task的数据本地化级别，如果大多都是PROCESS_LOCAL，那就不用调节了。如果是发现，好多的级别都是NODE_LOCAL、ANY，最好就去调节一下数据本地化的等待时长。要反复调节，每次调节完以后再运行并观察日志，看看大部分的task的本地化级别有没有提升，看看整个spark作业的运行时间有没有缩短。注意，不要本末倒置，不要本地化级别是提升了，但是因为大量的等待时长，spark作业的运行时间反而增加了，那还是不要调节了。

调节方式

spark.locality.wait，默认是3s。6s，10s

默认情况下，下面3个的等待时长，都是跟上面那个是一样的，都是3s

spark.locality.wait.process

spark.locality.wait.node

spark.locality.wait.rack

new SparkConf().set("spark.locality.wait", "10")