一. 概述
Spark中的数据本地性分为两种
- executor 层面的数据本地性
- task 层面的数据本地性
在两种本地性中，task层面的数据本地性是由Spark本身决定的，而executor的分发则是Cluter Manager控制的，因此下文主要描述在不同Cluster Manager中的executor分发机制。
-
Spark Standalone
Standalone提供了两种executor的分发模式。
由参数spark.deploy.spreadOut控制，默认为true，将会把executor分配到尽可能多的worker上，因此通常都能提供非常良好的数据本地性。如果设置为false(不建议)，会将executor优先分配到一台机器中，能提供更高的机器使用率。
Spark on Yarn
在Spark on Yarn方式下，如果启用了Dynamic Allocation并设置spark.dynamicAllocation.initialExecutors为一个较低的值（例如0）。则在pending task申请executor时，就会判断任务的数据本地性，并且在有数据的节点上启动executor。-
Spark on Mesos
mesos会先offer给spark一个空闲的slave，spark会在上面启动executor，直到slave占满，mesos会再发一个新的offer过来。这种做法类似于standalone关闭spreadOut的效果，因此会导致某些节点load非常高，而一些节点异常空闲情况。
解决方式有2个：- 修改spark源码解决这个问题（接收到一个offer的时候只启动一个executor），在spark2.0的基础上只需要改动
MesosCoarseGrainedSchedulerBackend中buildMesosTasks那段代码即可。 - 配合docker,marathon解决。
- 修改spark源码解决这个问题（接收到一个offer的时候只启动一个executor），在spark2.0的基础上只需要改动
修改mesos调度前:
修改mesos调度后:
观察到本地性有较大的提升，运行时间缩短了25%左右。
同时离线任务运行时间波动减少，趋于稳定
二. 结语
通过上述来看，目前Spark on Yarn + Dynamic Allocation的方式在executor的数据本地性上有着一定的优势。
分布式计算的瓶颈往往出现在IO上，因此良好的数据本地性能提高程序的整体运行速度。在机器较多的集群中，为了拥有更好的数据本地性，最简单的一种方式就是通过启动更多的executor来实现。
例如需要一个<4 cores, 20G RAM>的Spark Application。如果只启动一个executor，那么只会运行在一台节点上，其他机器的数据则需要通过网络IO来获取。如果启动4个executor,每个executor使用<1 cores,5G RAM>，那么executor将能分布到更多的节点上，获取更好的数据本地性。
