Spark Shuffle Read階段是如何讀取數據的
- Reduce去拉取Map的輸出數據，Spark提供了兩套不同的拉取數據框架：通過socket連接去取數據；使用netty框架去取數據。
- 每個節點的Executor會創建一個BlockManager，其中會創建一個BlockManagerWorker用于響應請求。當Reduce的GET_BLOCK的請求過來時，讀取本地文件將這個blockId的數據返回給Reduce。如果使用的是Netty框架，BlockManager會創建ShuffleSender用于發送Shuffle數據。
- 并不是所有的數據都是通過網絡讀取，對于在本節點的Map數據，Reduce直接去磁盤上讀取而不再通過網絡框架。
Spark shuffle reducer的結果是如何存儲的？
- Reduce拖過來數據之后以什么方式存儲呢？Spark Map輸出的數據沒有經過排序，Spark Shuffle過來的數據也不會進行排序，Spark認為Shuffle過程中的排序不是必須的，并不是所有類型的Reduce需要的數據都需要排序，強制地進行排序只會增加Shuffle的負擔。Reduce拖過來的數據會放在一個HashMap中，HashMap中存儲的也是<key, value>對，key是Map輸出的key，Map輸出對應這個key的所有value組成HashMap的value。Spark將Shuffle取過來的每一個<key, value>對插入或者更新到HashMap中，來一個處理一個。HashMap全部放在內存中。
- Shuffle取過來的數據全部存放在內存中，對于數據量比較小或者已經在Map端做過合并處理的Shuffle數據，占用內存空間不會太大，但是對于比如group by key這樣的操作，Reduce需要得到key對應的所有value，并將這些value組一個數組放在內存中，這樣當數據量較大時，就需要較多內存。
- 當內存不夠時，要不就失敗，要不就用老辦法把內存中的數據移到磁盤上放著。Spark意識到在處理數據規模遠遠大于內存空間時所帶來的不足，引入了一個具有外部排序的方案。Shuffle過來的數據先放在內存中，當內存中存儲的<key, value>對超過1000并且內存使用超過70%時，判斷節點上可用內存如果還足夠，則把內存緩沖區大小翻倍，如果可用內存不再夠了，則把內存中的<key, value>對排序然后寫到磁盤文件中。最后把內存緩沖區中的數據排序之后和那些磁盤文件組成一個最小堆，每次從最小堆中讀取最小的數據，這個和MapReduce中的merge過程類似。
Spark中不需要排序的hash shuffle是否一定比需要排序的sort shuffle速度快？
- 當數據規模小，Hash shuffle快于Sorted Shuffle數據規模大的時候；當數據量大，sorted Shuffle會比Hash shuffle快很多，因為數量大的有很多小文件，不均勻，甚至出現數據傾斜，消耗內存大，1.x之前spark使用hash，適合處理中小規模，1.x之后，增加了Sorted shuffle，Spark更能勝任大規模處理了。
Spark中的HashShufle的有哪些不足？
1）shuffle產生海量的小文件在磁盤上，此時會產生大量耗時的、低效的IO操作；
2）.容易導致內存不夠用，由于內存需要保存海量的文件操作句柄和臨時緩存信息，如果數據處理規模比較大的化，容易出現OOM；
3）容易出現數據傾斜，導致OOM。
Spark中Sort-based shuffle的缺陷?
- 如果mapper中task的數量過大，依舊會產生很多小文件，此時在shuffle傳遞數據的過程中reducer段，reduce會需要同時大量的記錄進行反序列化，導致大量的內存消耗和GC的巨大負擔，造成系統緩慢甚至崩潰；
- 2）如果需要在分片內也進行排序，此時需要進行mapper段和reducer段的兩次排序。
