一、再次思考pipeline
即使採用pipeline的方式，函數f對依賴的RDD中的數據操作也會有兩種方式：
1、f(record) f作用於集合的每一條記錄，每次只作用於一條記錄。
2、f(records) f一次性作用於集合的全部數據。
Spark採用的是第一種方式：原因：
1.無需等待，可以最大化的使用集羣的計算資源；
2.減少OOM的發生；
3.最大化的有利於併發；
4.可以精準的控制每個Partition本身（Dependency）及其內部的計算（compute）
5.基於lineage的算子流動式函數式編程，節省了中間結果的產生，並且可以最快的恢復。
疑問：會不會增加網絡通信？當然不會，因爲在pineline（一個stage）
二、思考Spark Job具體的物理執行
Spark Application裏面可以產生1個或者多個Job,例如spark-shell默認啓動是時候就沒有Job，只是作爲資源的分配程序，可以在裏面寫代碼產生若干個Job，普通程序中一般而言可以有不同的Action，每一個Action一般也會觸發一個Job。
Spark是MapReduce思想的一種更加精緻和高效的實現，MapReduce由很多具體不同的實現，例如Hadoop的MapReduce基本的計算流程如下：首先是以JVM爲對象的併發執行的Mapper,Mapper中map的執行會產生輸出數據，輸出數據會經過Partition指定的規則放到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都是窄依賴，窄依賴計算本身從邏輯上看是從最左側RDD開始立即計算的，根據Computing Chain,數據是從一個計算步驟流到下一個計算步驟，以此類推，直到Stage內部最後一個RDD產生計算結果。
Computing Chain的構建是從後往前回溯構建而成，而實際的物理計算則是讓數據從前往後再算子上流動，直到流動到不能流動爲止纔開始計算下一個Record。後面的RDD對前面的RDD的依賴雖然是Partition級別的數據集合的依賴，但是不需要父RDD把Partition中所有的Records計算完畢才整體往後流動數據進行計算，這就極大的提高了效率。
四、寬依賴的物理執行內幕
必須等到依賴的父Stage中的最後一個RDD全部數據徹底計算完畢，才能夠經過shuffle來計算當前的Stage!
學習於：
ＤＴ大數據夢工廠
新浪微博：www.weibo.com/ilovepains/
微信公衆號：DT_Spark
博客：http://.blog.sina.com.cn/ilovepains
TEL:18610086859
Email:[email protected]
