54.性能调优之调节数据本地化等待时长

本文为《Spark大型电商项目实战》 系列文章之一，主要介绍在实际项目中通过调节数据本地化等待时长进行性能优化。

数据本地化等待时长

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

但是呢，通常来说，有时事与愿违，可能 task 没有机会分配到它的数据所在的节点，可能那个节点的计算资源和计算能力都满了，通常来说，这时 Spark 会等待一段时间，默认情况下是3s钟（不是绝对的，还有很多种情况，对不同的本地化级别，都会去等待），到最后，实在是等待不了了，就会选择一个比较差的本地化级别，比如说，将 task 分配到靠它要计算的数据所在节点比较近的一个节点，然后进行计算。

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

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

数据本地化级别

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

NODE_LOCAL：节点本地化，代码和数据在同一个节点中。比如说，数据作为一个HDFS block 块就在节点上，而 task 在节点上某个 executor 中运行，或者是数据和 task 在一个节点上的不同 executor 中，此时数据需要在进程间进行传输，性能稍次，不过也还不错。

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

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

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

需调节参数的情况

我们什么时候要调节这个参数？
首先观察 spark 作业的运行日志，推荐大家在测试的时候先用 client 模式，在本地就直接可以看到比较全的日志。日志里面会显示：starting task……，PROCESS LOCAL、NODE LOCAL，观察大部分task的数据本地化级别。

如果大多都是PROCESS_LOCAL，那就不用调节了，性能已经很好了，如果是发现好多的级别都是NODE_LOCAL、ANY，那么最好就去调节一下数据本地化的等待时长。要反复调节，每次调节完以后，再来运行，观察日志，看看大部分的 task 的本地化级别有没有提升，然后看看整个 spark 作业的运行时间有没有缩短。不要本末倒置，本地化级别倒是提升了，但是因为大量的等待时长，spark 作业的运行时间反而增加了，那就还是不要调节了。

参数调节方法

怎么调节？
spark.locality.wait默认是3s这个参数是综合性的，还有三个子参数分别为spark.locality.wait.process，spark.locality.wait.node和spark.locality.wait.rack，默认情况下，这3个的等待时长和spark.locality.wait是一样的，都是3s，可以调节为6s或10s，具体调节数值需要根据日志信息和调节后的结果调整。

在代码中可以使用

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

进行设置等待时长，在项目中不再演示。

《Spark 大型电商项目实战》源码：https://github.com/Erik-ly/SprakProject

本文为《Spark大型电商项目实战》系列文章之一,
更多文章：Spark大型电商项目实战：http://blog.csdn.net/u012318074/article/category/6744423