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

1.f(record)，f作用於集合的每一條記錄，每次只作用於一條記錄

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

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

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

2.減少OOM的產生

3.最大化的有利於並發

4.可以精準的控制每一個Partition本身(Dependency)及其內部的計算(compute)

5.基於lineage的算子流動式函數式計算，可以節省中間結果的產生，可以最快的恢復

不會產生網絡流量，因為用的是pipeline。

--------------------------------------------------------------------------------------------------------------------------------------------------------------

物理執行過程

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

Spark是MapReduce思想的一種更加精致和高效的實現，MapReduce有很多不同的具體實現，例如Hadoop的MapReduce基本的計算流程，如下：首先是並發，以JVM為對象的並發Mapper，Mapper中的map的執行會產生輸出數據，輸出的數據會經由Partitioner指定的規則，放到localFileSystem中，然後再經由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把Partition中的所有的Record計算完畢，才整體完後流動數據進行計算。這極大地提高了計算速率。

--------------------------------------------------------------------------------------------------------------------------------------------------------------

寬依賴的物理執行

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

Spark Job具體的物理執行