在早期版本的Spark中，shuffle程序沒有磁盤讀寫操作，是純記憶體操作，后來發現效率較低，且極易引發OOME，較新版本的Shuffle操作都加入了磁盤讀寫進行了改進，
1、未經優化的HashShuffleManager：上一個stage中每一個task會對下一個stage的每一個task寫一份資料檔案，假定上一個stage有N個task，下一個stage有M個task，此時由上到下形成N個1對M的映射關系，總共產生【N * M】個檔案，這種方式的優點是思路簡單，資料檔案的邏輯隔離性更強，缺點是在磁盤上產生的檔案個數太多，每個檔案的讀寫都需要建立管道等操作，過多的檔案勢必增加額外的開銷，效率較低，【同將多個小檔案打包為一個大檔案再拷貝，比直接拷貝多個小檔案更快，一個道理】
2、優化過的HashShuffleManager：上一個stage中每一個task共同寫下一個stage的每一個task獨有的資料檔案，假定上一個stage有N個task，下一個stage有M個task，此時由上到下形成M個N對1的映射關系，總共產生M個檔案（檔案數量只取決于下一個stage的task數量），由于檔案數量的減少，性能得到了一定的提升，
3、SortShuffleManager：這是當前版本中使用的方式，進一步減少資料檔案個數，階段之間只通過2個檔案來傳遞資料【索引檔案、資料檔案】，在上一個階段中，每個task都將資料在記憶體中進行排序生成檔案（如果記憶體不夠用就溢寫到磁盤），將多個排序后的檔案合并到同一個資料檔案中，配合索引檔案，下游task就能高效的完成讀取操作，
由于排序操作是一個相對低效的操作，所以在小資料量時可以使用Hash演算法來達到快速定位的目的，此時就輪到bypass機制，其內容是當shuffle-map-task數量小于bypassMergeThreshold（默認200個）時或者不是聚合類shuffle，就不采用排序而換為Hash操作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/29386.html
標籤：大數據
上一篇：Spark組件間通信