23.从物理执行的角度透视 spark job

即使采用pipeline的方式，函数f对依赖的RDD中的数据操作也会有两种方式：

1，f（record），f作用于集合的每一条记录，每次只作用于一条记录

2，f(records), f一次性作用于集合的全部数据

spark的实现，是采用第一种方式，为什么采用第一种方式，

原因 1，无需等待，可以最大化的使用集群的计算资源

        2，可以减少oom的发生，

        3，最大化的有利于并发

        4，可以精准的控制每个partiton本身（Dependency）及其内部的计算（compute）

        5，基于lineage的算子流动式函数式编程，节省了中间结果的产生，并且可以最快的恢复

疑问：会不会增加网络的通信？当然不会，因为在pipeline，在一个stage中

        

二：思考spark job具体的物理执行

        spark Application里面可以产生1个或者多个job，

        例如spark-shell默认启动的时候内部就没有job，只是作为资源的分配程序，

        可以在里面写代码产生若干个job，普通程序中一般而言可以有不同的Action，每个Action一般也会触发一个job（当然也有二般的情况一个action可以触发其他的action）

        spark是MapReduce思想的一种更加精致和高效的实现，mapreduce有很多具体不同的实现，例如Hadoop的mapreduce基本的计算流程如下：首先是以jvm为对象的并发执行的mapper，mapper中map的执行会产生输出数据，输出的数据会经过partitioner指定的规则放到local Filesystem，然后在经由shuffle。sort。Aggregate变成Reducer中的reduce的输入，执行reduce产生最终执行过程；hadoop Mapreduce执行的流程虽然简单，但是过于死板，尤其是在构造复杂算法（迭代）时候非常不利于算法的实现，且执行的效率极为低下！

spark算法构造和物理执行时最基本的核心：最大化pipeline

      基于pipeline的思想，数据被使用的时候才开始计算，从数据流动的视角来书，数据流动到计算的位置！！！

实质上从逻辑的角度来看，是算子在数据上流动！

    从算法构建的角度而言：肯定是算子作用于数据，所以是算子在数据上流动，方便算法的构建

    从物理执行的角度而言：是数据流动到计算的位置，方便系统最为高效的运行！

对于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把partiton中所有的Records计算完毕才整体往后流动数据进行计算，这就极大的提高了计算速率

四： 宽依赖物理执行内幕

    必须等到依赖的父Stage中的最后一个RDD全部数据彻底计算完毕，才能够经过shuffle来计算当前的stage，

下一个stage只需接受上个stage部分的数据就可以开始计算，并不是把上个stage中的全部数据接受过来就开始计算的。