一、再次思考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！