Spark不同Cluster Manager下的数据本地性表现

一. 概述

Spark中的数据本地性分为两种

• executor 层面的数据本地性
• task 层面的数据本地性

在两种本地性中，task层面的数据本地性是由Spark本身决定的，而executor的分发则是Cluter Manager控制的，因此下文主要描述在不同Cluster Manager中的executor分发机制。

1. Spark Standalone
   Standalone提供了两种executor的分发模式。
   由参数spark.deploy.spreadOut控制，默认为true，将会把executor分配到尽可能多的worker上，因此通常都能提供非常良好的数据本地性。

   如果设置为false(不建议)，会将executor优先分配到一台机器中，能提供更高的机器使用率。

2. Spark on Yarn
   在Spark on Yarn方式下，如果启用了Dynamic Allocation并设置spark.dynamicAllocation.initialExecutors为一个较低的值（例如0）。则在pending task申请executor时，就会判断任务的数据本地性，并且在有数据的节点上启动executor。

3. Spark on Mesos
   mesos会先offer给spark一个空闲的slave，spark会在上面启动executor，直到slave占满，mesos会再发一个新的offer过来。这种做法类似于standalone关闭spreadOut的效果，因此会导致某些节点load非常高，而一些节点异常空闲情况。
   解决方式有2个：

   1. 修改spark源码解决这个问题（接收到一个offer的时候只启动一个executor），在spark2.0的基础上只需要改动MesosCoarseGrainedSchedulerBackend中buildMesosTasks那段代码即可。
   2. 配合docker,marathon解决。

修改mesos调度前:

修改mesos调度前
修改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将能分布到更多的节点上，获取更好的数据本地性。