spark中rdd的高效與dag圖有著莫大的關係，在dag排程中需要對計算過程劃分stage，而劃分依據就是rdd之間的依賴關係。針對不同的轉換函式，rdd之間的依賴關係分類窄依賴（narrow dependency）和寬依賴（wide dependency, 也稱 shuffle dependency）.
寬依賴和窄依賴如下圖所示：
相比於寬依賴，窄依賴對優化很有利 ，主要基於以下兩點：
寬依賴往往對應著shuffle操作，需要在執行過程中將同乙個父rdd的分割槽傳入到不同的子rdd分割槽中，中間可能涉及多個節點之間的資料傳輸；而窄依賴的每個父rdd的分割槽只會傳入到乙個子rdd分割槽中，通常可以在乙個節點內完成轉換。
當rdd分割槽丟失時（某個節點故障），spark會對資料進行重算。
對於窄依賴，由於父rdd的乙個分割槽只對應乙個子rdd分割槽，這樣只需要重算和子rdd分割槽對應的父rdd分割槽即可，所以這個重算對資料的利用率是100%的；
對於寬依賴，重算的父rdd分割槽對應多個子rdd分割槽，這樣實際上父rdd 中只有一部分的資料是被用於恢復這個丟失的子rdd分割槽的，另一部分對應子rdd的其它未丟失分割槽，這就造成了多餘的計算；更一般的，寬依賴中子rdd分割槽通常來自多個父rdd分割槽，極端情況下，所有的父rdd分割槽都要進行重新計算。
如下圖所示，b1分割槽丟失，則需要重新計算a1,a2和a3，這就產生了冗餘計算(a1,a2,a3中對應b2的資料)。
區分這兩種依賴很有用。首先，窄依賴允許在乙個集群節點上以流水線的方式（pipeline）計算所有父分割槽。例如，逐個元素地執行map、然後filter操作；而寬依賴則需要首先計算好所有父分割槽資料，然後在節點之間進行shuffle，這與mapreduce類似。第二，窄依賴能夠更有效地進行失效節點的恢復，即只需重新計算丟失rdd分割槽的父分割槽，而且不同節點之間可以平行計算；而對於乙個寬依賴關係的lineage圖，單個節點失效可能導致這個rdd的所有祖先丟失部分分割槽，因而需要整體重新計算。【誤解】之前一直理解錯了，以為窄依賴中每個子rdd可能對應多個父rdd,當子rdd丟失時會導致多個父rdd進行重新計算，所以窄依賴不如寬依賴有優勢。而實際上應該深入到分割槽級別去看待這個問題，而且重算的效用也不在於算的多少，而在於有多少是冗餘的計算。窄依賴中需要重算的都是必須的，所以重算不冗餘。參考：
rdd：基於記憶體的集群計算容錯抽象
spark技術內幕：stage劃分及提交原始碼分析
spark分布式計算和rdd模型研究
spark 闊依賴 和窄依賴 transfer action lazy策略之間的關係
每天進步一點點
很多朋友總喜歡問 成功靠什麼？其實，成功很難單一的歸納為靠什麼條件，如果一定要回答，只能從某種意義上說 很多人的成功就是靠他們每天比別人 多做一點點 正如古人有云 業精於勤，荒於嬉。這裡所說的勤，也就是比別人多做一點點，即付出多一點的勞動和努力。不要小看這一點點，又如古語說 集腋成裘，積沙成丘。如果...
每天進步一點點
在模組化程式設計時，在子模組中宣告變數 例如unsigned char aa 不需要在標頭檔案中宣告 要在主函式中呼叫，要寫成 extern unsigned char aa 而不能寫成 extern aa 寫成extern aa 則無法改變aa的值。2014年9月22日 21 12 00 品質因數...
每天進步一點點（一）
最近接了第乙個商業專案，一人獨立完成從前台到後台，做了有幾天的時間，每天進步一點點，把每天看到的學到的記錄下來，以後也堅持。後台繼續用自己的extjs老本行，因為相比其他js庫，extjs用的比較熟，現成的 也有所以開發起來也比較容易，今天學到了兩個ext的新東西。一 ext和後台進行互動大部分用的...