從物理執(zhí)行角度透視Spark Job（23）

  一、再次思考pipeline

     即使采用pipeline的方式，函數(shù)f對依賴的RDD中的數(shù)據(jù)集合的操作也會有兩種方式：

     1， f(record),f作用于集合的每一條記錄，每次只作用于一條記錄；

     2， f(records),f一次性作用于集合的全部數(shù)據(jù)；

  Spark采用是是第一種方式，原因：

    1， 無需等待，可以最大化的使用集群的計算資源；

    2， 減少OOM的發(fā)生；

    3， 最大化的有利于并發(fā)；

    4， 可以精準的控制每一Partition本身（Dependency）及其內(nèi)部的計算（compute）；

    5， 基于lineage的算子流動式函數(shù)式編程，節(jié)省了中間結(jié)果的產(chǎn)生，并且可以最快的恢復；

 二：思考Spark Job具體的物理執(zhí)行

    Spark Application里面可以產(chǎn)生1個或者多個Job，例如spark-shell默認啟動的時候內(nèi)部就沒有Job，只是作為資源的分配程序，可以在spark-shell里面寫代碼產(chǎn)生若干個Job，普通程序中一般而言可以有不同的Action，每一個Action一般也會觸發(fā)一個Job。

    Spark是MapReduce思想的一種更加精致和高效的實現(xiàn)，MapReduce有很多具體不同的實現(xiàn)，例如Hadoop的MapReduce基本的計算流程如下：首先是以JVM為對象的并發(fā)執(zhí)行的Mapper，Mapper中map的執(zhí)行會產(chǎn)生輸出數(shù)據(jù)，輸出數(shù)據(jù)會經(jīng)過Partitioner指定的規(guī)則放到Local FileSystem中，然后在經(jīng)由Shuffle、Sort、Aggregate變成Reducer中的reduce的輸入，執(zhí)行reduce產(chǎn)生最終的執(zhí)行結(jié)果；Hadoop MapReduce執(zhí)行的流程雖然簡單，但是過于死板，尤其是在構(gòu)造復雜算法（迭代）時候非常不利于算法的實現(xiàn)，且執(zhí)行效率極為低下！

    Spark算法構(gòu)造和物理執(zhí)行時最最基本的核心：最大化pipeline

     Pipeline的思想，數(shù)據(jù)被使用的時候才開始計算，從數(shù)據(jù)流動的視角來說，是數(shù)據(jù)流動到計算的位置，實質(zhì)上從邏輯的角度來看，是算子在數(shù)據(jù)上流動。

    從算法構(gòu)建的角度而言：肯定是算子作用于數(shù)據(jù)，所以是算子在數(shù)據(jù)上流動；

    從物理執(zhí)行的角度而言：是數(shù)據(jù)流動到計算的位置；

    對于pipeline而言，數(shù)據(jù)計算的位置就是每個stage中的最后RDD。

    由于計算的Lazy特性，導致計算從后往前回溯，形成Computing Chain，導致的結(jié)果就是需要首先計算出具體一個Stage內(nèi)部左側(cè)的RDD中本次計算依賴的Partition

     三：窄依賴的物理執(zhí)行內(nèi)幕

    一個Stage內(nèi)部的RDD都是窄依賴，窄依賴計算本身是邏輯上看是從Stage內(nèi)部最左側(cè)的RDD開始立即計算的，根據(jù)Computing Chain，數(shù)據(jù)（Record）從一個計算步驟流動到下一個結(jié)算步驟，以此類推，直到計算到Stage內(nèi)部的最后一個RDD來產(chǎn)生計算結(jié)果。

    Computing Chain的構(gòu)建是從后往前回溯構(gòu)建而成，而實際的物理計算則是讓數(shù)據(jù)從前往后在算子上流動，直到流動到不能再流動位置才開始計算下一個Record。這就導致一個美好的結(jié)果：后面的RDD對前面的RDD的依賴雖然是Partition級別的數(shù)據(jù)集合的依賴，但是并不需要父RDD把Partition中所有的Records計算完畢才整體往后流動數(shù)據(jù)進行計算，這就極大的提高了計算速率！

 四：寬依賴物理執(zhí)行內(nèi)幕

    必須等到依賴的父Stage中的最后一個RDD全部數(shù)據(jù)徹底計算完畢，才能夠經(jīng)過shuffle來計算當前的Stage！