一、思考pipeline
即使采用pipeline的方式,函数f对依赖的RDD中的数据集合的操作也会有两种方式:
1、f (record) ,f作用于集合的每一条记录,每次只作用于一条记录
2、f(records),f 一次性作用于集合的全部数据。
Spark采用的是第一种方式,原因:
1、无需等待,可以最大化的使用集群的计算资源。
2、减少OOM的发生。
3、最大化的有利于并发。
4、可以精准的控制每一个Partition本身(Dependency)及其内部的计算(compute)。
5、基于lineage的算子流动式函数式编程,节省了中间结果的产生。并且可以最快的恢复。
疑问:会不会增加网络通信? 不会!因为在pipeline(在stage内部把很多算子合并成一个)
二、思考Spark Job具体的物理执行
SparkApplication里面可以产生1个或者多个job,例如spark-shell默认启动的时候内部就没有job,只是作为资源的分配程序,可以在spark-shell里面写代码产生若干个job,普通程序中一般而言可以有不同的Action,每一个Action一般也回触发一个Job .
Spark是MapReduce思想的一种更加精致和高效的实现,MapReduce有很多具体不同的实现,例如Hadoop的MapReduce基本的计算流程如下:首先是以JVM为对象的并发执行的mapper,Mapper中的map的执行会产生输出数据,输出数据会经过Partitionner指定的规则放到Local FileSystem,然后再经由shuffle,sort,aggregate变成Reducer中reduce的输入,执行reduce产生最终的执行结果;hadoop MapReduce执行的流程虽然简单,但是过于死板,尤其是在构造复杂算法(迭代)时候非常不利于算法的实现,且执行效率极为低下。
Spark算法构造和物理执行是最最基本的核心:最大化pipeline
基于pipelien的思想,数据被使用的时候才开始计算,
从数据流动的视角来说,是数据流动到计算的位置。实质上从逻辑的角度来看,是算子在数据上流动。
从算法构建的角度而言:肯定是算子作用于数据,所以是算子在数据上流动,方便算法的构建;
从物理执行的角度而言,是数据流动到计算的位置。方便系统最为高效的运行。
对于pipeline而言,数据计算的位置就是每个stage中最后的RDD,每个stage中除了最后一个RDD算子是真实的意外,前面的算子都是假的。
由于计算的lazy特性,导致计算从后往前回溯,形成computing Chain(链条计算),导致的结果就是需要首先计算出具体一个stage内部最左侧的RDD中本次计算依赖的Partition
三、窄依赖的物理执行内幕
一个stage内部的RDD都是窄依赖,窄依赖计算本身是从逻辑上看是从stage内部最左侧的RDD开始立即计算的,根据computing chain,数据(Record)从一个计算步骤流动到 下一个计算步骤,以此类推,直到计算到 stage内部的最后一个RDD 来产生计算结果。
Computing Chain的构建是从后往前回溯构建而成的,而实际的物理计算则是让数据从前往后在算子上流动,直到流动 到不能再流动为止才开始计算下一个Record。后面的RDD 对前面RDD的依赖虽然是Partition级别的数据集合的依赖,但是并不需要父RDD把Partition中所有的Records计算完毕才整体往后流动数据进行计算。这就极大的提高了计算效率 源码为
class MapPartitionsRDD
override def compute(split: partition,context:TaskContext):Iterator[U] = f(context,split.index,firstParent[T].iterator(split,context))
四:宽依赖物理执行内幕:
必须等到依赖的父Stage中的最后一个RDD把全部数据彻底计算完毕,才能够经过Shuffle来计算当前的Stage.