物理執行的角度透視Spark Job

一：即便採用pipeline的方式，函數f對依賴的RDD中的數據集合的數據操做也會有兩種操做也會有兩種方式
1.f(record)，f做用於集合的每一條記錄，每次之做用於每一條記錄：
2.f(record), f做用於集合的所有數據：
    spark採用的是第一種方式緣由是：1:無需等待，能夠最大化的使用集羣的計算資源。2：減小OOM的發生。3：最大化的有利於併發。4:能夠精準控制每個Partion自己（Dependency）和內部的計算（compute）。5:基於linepage算子流動式函數編程，節省了中間結果的產生，而且能夠最快的恢復。不會增長網絡通訊，由於在pipeline

二：思考Spark Job具體的物理執行：
    spark Application裏面會產生一個或則多個Job，例如spark-shell默認啓動的時候內部沒有job，只會做爲資源分配程序，能夠在裏面寫代碼產生若干個job，普通程序中通常而言能夠有不一樣的Action，每個Action也會產生一個Job
    spark是MapReduce思想的一種實現，MapReduce有不少不一樣實現好比Haddoop的MapReduce的計算過程以下：
    1：首先是以jvm爲對象的併發執行的mapper，mapper中的map的執行會產生輸出數據，輸出數據會產生partitione指定的規則放到Local FileSystem中，而後再由Shuffle，Sort，Aggregate，編程reducer的reduce輸入，執行reduce產生結果

spark算法構造和物理執行時最基本的核心：最大化pipeline，基於pipeline的思想，數據被使用的時候纔開始計算，從數據角度看是數據流到計算的位置！！！！實際上從邏輯的角度看是算子在數據上流動！！！！！！
1:從算子構建的角度而言：算子做用於數據，因此是算子在數據上流動，方便算法構建
2:從物理執行的角度而言：是數據流動到數計算位置，方便高效執行
對於pipeline而言，數據計算的位置就在每一個Stage中最後的RDD，真相是：每一個State中（除了最後一個），前面的的算子都是假的


三：窄依賴的物理執行內幕
    遇到shuffle級別的依賴造成Stage，一個stage內部的RDD都是窄依賴，窄依賴計算自己是邏輯上看是從State內部最左側的RDD開始當即計算的，根據Competing Chain，數據（Record）從一個計算步驟流動到下一個計算步驟，以此類推，直到計算到Stage內部的最後一個RDD產生數據結果
    Computing Chain的構建是從後往前回溯構成的，而實際的物理計算是數據從前日後在算子上流動，直到流動到不能流動的位置，纔開始計算下一個Record，這就產生了一個美好的結果：後面的RDD對前面的RDD的依賴是Partition級別的數據集合的依賴，可是並不須要父RDD的全部的Record計算完才總體流動數據進行計算，這就極大的提升了計算效率



四：寬依賴物理執行內幕
   必須等到依賴的父State中的最後一個RDD所有計算完畢纔可以通過shuffle來計算當前的State
   查看源碼：MapPartitionRDD,RDD閱讀getPartitions,getDependencies