Hadoop上的文件是集中到master再交给Spark进行计算的吗？
Spark如何获取数据资源，集中从namenode获取？还是从各个datanode分别获取呢？
其实，Spark集群是有衡量数据分布读取的方法的，那就是Locality Level属性。我们来看看不同Locality Level属性的区别：
| PROCESS_LOCAL: 数据在同一个 JVM 中，即同一个 executor 上。这是最佳数据 locality。
NODE_LOCAL: 数据在同一个节点上。比如数据在同一个节点的另一个 executor上；或在 HDFS 上，恰好有 block 在同一个节点上。速度比 PROCESS_LOCAL 稍慢，因为数据需要在不同进程之间传递或从文件中读取
NO_PREF: 数据从哪里访问都一样快，不需要位置优先
RACK_LOCAL: 数据在同一机架的不同节点上。需要通过网络传输数据及文件 IO，比 NODE_LOCAL 慢
ANY: 数据在非同一机架的网络上，速度最慢
|
这个Locality Level属性并不好查询，得在实际任务启动的时候才能查看。因为的Web UI是在任务发起者的host生成的，如下：我们打开spark集群所在host（这里例子即bigmaster）的8080端口查看Web UI
点击运行中的程序名，如图示例为pi
点击pi后就进入到spark程序提交者的host里面来了。此时为4040端口。接下来，我们看看怎么才能找到Locality Level。点击最上面的标签栏中的Stages，然后点击Active Stages中的运行程序的类：
接下来我们就进到Detail Stage界面了，如下会有Locality Level提示
由Locality Level不同的等级分析可知，对于分配到相应节点的spark任务来说，当然是取数据越近越好了。也就是本地性越高越好。大多数情况下，数据本地性可以减少网络的IO，提高程序整体的运行效率。
taskSetManager在分发任务之前会先计算数据本地性，优先级依次是：
process(同一个executor) -> node_local(同一个节点) -> rack_local(同一个机架) -> any(任何节点)
不过在一些比较特殊的情况下(Spark的延时调度)，他反而会拖累整体运行速度：
举个极端例子：运行一个count任务，如果数据全都堆积在某一台节点上，那将只会有这台机器在长期执行任务，集群中的其他机器则会处于等待状态（等待本地性降级）而不执行任务，造成了大量的资源浪费。
判断的公式为：
curTime – lastLaunchTime >= localityWaits(currentLocalityIndex)
其中 curTime 为系统当前时间，lastLaunchTime 为在某优先级下最后一次启动task的时间
如果满足这个条件则会进入下一个优先级的时间判断，直到 any，不满足则分配当前优先级的任务。
数据本地性任务分配的源码在 taskSetManager.scala 。
如果存在大量executor处于等待状态，可以降低以下参数的值（也可以设置为0），默认都是3s。
spark.locality.wait
spark.locality.wait.process
spark.locality.wait.node
spark.locality.wait.rack
当你数据本地性很差，可适当提高上述值，当然也可以直接在集群中对数据进行balance。
参考资料：
扫一扫
194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
