Spark数据本地性

一. 概述

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调度后: 
    
   观察到本地性有较大的提升，运行时间缩短了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将能分布到更多的节点上，获取更好的数据本地性。

当磁盘io成为程序瓶颈的解决方法：

1.使用多块硬盘（最简单有效）,可以使用ssd存放部分spark计算的中间结果。

2.通过压缩减少本地磁盘IO,对计算的中间结果压缩，在取数据时还要进行解压。

spark.shuffle.spill.compress true（默认）

3.优化程序，减少shuffle

通过压缩的两个配置其实使用cpu换磁盘io和网络io,如果在磁盘io不是瓶颈的计算密集型作业中，如此设置反而会降低运行效率。所以应观察应用，根据情况进行调整。

网络IO优化

通过压缩减少网络IO，减少即将进行shuffle的本地数据。 
这样需要shuffle的数据就需要压缩->网络传输->解压缩三个步骤

spark.shuffle.compress true（默认）