從物理執行角度透視Spark Job（23）

  一、再次思考pipeline

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

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

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

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

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

    2， 減少OOM的發生；

    3， 最大化的有利于并發；

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

    5， 基于lineage的算子流動式函數式編程，節省了中間結果的產生，并且可以最快的恢復；

 二：思考Spark Job具體的物理執行

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

    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。

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

     三：窄依賴的物理執行內幕

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

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

 四：寬依賴物理執行內幕

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