|NO.Z.00097|——————————|BigDataEnd|——|Hadoop&Spark.V13|——|Spark.v13|Spark 原理 源码|Shuffle详解&Hash Shuffle V1&Hash Shuffle V2 -- File Consolidation|

一、Hash Shuffle V1

### --- Hash Shuffle V1

~~~     相对于传统的 MapReduce，
~~~     Spark 假定大多数情况下 Shuffle 的数据不需要排序，强制排序反而会降低性能。
~~~     因此不在 Shuffle Read 时做 Merge Sort，如果需要合并的操作的话，则会使用聚合（agggregator），
~~~     即用了一个HashMap （实际上是一个 AppendOnlyMap）来将数据进行合并。
~~~     在 Map Task 过程按照 Hash 的方式重组 Partition 的数据，不进行排序。
~~~     每个 Map Task 为每个 Reduce Task 生成一个文件，
~~~     通常会产生大量的文件（即对应为 M*R 个中间文件，其中 M 表示 Map Task 个数，
~~~     R 表示 Reduce Task个数），伴随大量的随机磁盘 I/O 操作与大量的内存开销。

二、Hash Shuffle V1

### --- Hash Shuffle V1的两个严重问题：

~~~     生成大量文件，占用文件描述符，
~~~     同时引入 DiskObjectWriter 带来的 Writer Handler 的缓存也非常消耗内存
~~~     如果在 Reduce Task 时需要合并操作的话，会把数据放在一个 HashMap 中进行合并，
~~~     如果数据量较大，很容易引发 OOM

三、Hash Shuffle V2 -- File Consolidation

### --- Hash Shuffle V2 -- File Consolidation

~~~     针对上面的第一个问题，Spark 做了改进，引入了 File Consolidation 机制。
~~~     一个 Executor 上所有的 Map Task 生成的分区文件只有一份，
~~~     即将所有的 Map Task 相同的分区文件合并，这样每个 Executor 上最多只生成 N 个分区文件。

### --- Hash Shuffle V2

~~~     这样减少了文件数，但是假如下游 Stage 的分区数 N 很大，
~~~     还是会在每个 Executor 上生成 N 个文件，同样，如果一个 Executor 上有 K 个 Core，
~~~     还是会开 K*N 个 Writer Handler，这里仍然容易导致OOM。

---

 

 

 

 

 

 

 

 

 

---

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

                                                                                                                                                   ——W.S.Landor

---