这期内容当中小编将会给大家带来有关如何进行Spark Shuffle 原理分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
10年积累的网站制作、成都网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有江北免费网站建设让你可以放心的选择与我们合作。
Spark Shuffle原理分析
Shuffle就是对数据进行重组，由于分布式计算的特性和要求，在实现细节上更加繁琐和复杂。
在MapReduce框架，Shuffle是连接Map和Reduce之间的桥梁，Map阶段通过shuffle读取数据并输出到对应的Reduce；而Reduce阶段负责从Map端拉取数据并进行计算。在整个shuffle过程中，往往伴随着大量的磁盘和网络I/O。所以shuffle性能的高低也直接决定了整个程序的性能高低。Spark也会有自己的shuffle实现过程。
在DAG调度的过程中，Stage阶段的划分是根据是否有shuffle过程，也就是存在wide Dependency宽依赖的时候,需要进行shuffle,这时候会将作业job划分成多个Stage，每一个stage内部有很多可以并行运行的task。
stage与stage之间的过程就是shuffle阶段，在Spark的中，负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager，也即shuffle管理器。ShuffleManager随着Spark的发展有两种实现的方式，分别为HashShuffleManager和SortShuffleManager，因此spark的Shuffle有Hash Shuffle和Sort Shuffle两种。
HashShuffle机制
在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。
该ShuffleManager-HashShuffleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO操作影响了性能。因此在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。
SortShuffleManager相较于HashShuffleManager来说，有了一定的改进。主要就在于每个Task在进行shuffle操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并(merge)成一个磁盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。
Hash shuffle
一种是普通运行机制
另一种是合并的运行机制。
HashShuffleManager的运行机制主要分成两种
合并机制主要是通过复用buffer来优化Shuffle过程中产生的小文件的数量。
Hash shuffle是不具有排序的Shuffle。
普通机制的Hash shuffle
图解
这里我们先明确一个假设前提：每个Executor只有1个CPU core，也就是说，无论这个Executor上分配多少个task线程，同一时间都只能执行一个task线程。
图中有3个ReduceTask，从ShuffleMapTask 开始那边各自把自己进行 Hash 计算(分区器：hash/numreduce取模)，分类出3个不同的类别，每个 ShuffleMapTask 都分成3种类别的数据，想把不同的数据汇聚然后计算出最终的结果，所以ReduceTask 会在属于自己类别的数据收集过来，汇聚成一个同类别的大集合，每1个 ShuffleMapTask 输出3份本地文件，这里有4个 ShuffleMapTask，所以总共输出了4 x 3个分类文件 = 12个本地小文件。
shuffle Write阶段
主要就是在一个stage结束计算之后，为了下一个stage可以执行shuffle类的算子(比如reduceByKey，groupByKey)，而将每个task处理的数据按key进行“分区”。所谓“分区”，就是对相同的key执行hash算法，从而将相同key都写入同一个磁盘文件中，而每一个磁盘文件都只属于reduce端的stage的一个task。在将数据写入磁盘之前，会先将数据写入内存缓冲中，当内存缓冲填满之后，才会溢写到磁盘文件中去。
那么每个执行shuffle write的task，要为下一个stage创建多少个磁盘文件呢? 很简单，下一个stage的task有多少个，当前stage的每个task就要创建多少份磁盘文件。比如下一个stage总共有100个task，那么当前stage的每个task都要创建100份磁盘文件。如果当前stage有50个task，总共有10个Executor，每个Executor执行5个Task，那么每个Executor上总共就要创建500个磁盘文件，所有Executor上会创建5000个磁盘文件。由此可见，未经优化的shuffle write操作所产生的磁盘文件的数量是极其惊人的。
shuffle Read阶段
shuffle read，通常就是一个stage刚开始时要做的事情。此时该stage的每一个task就需要将上一个stage的计算结果中的所有相同key，从各个节点上通过网络都拉取到自己所在的节点上，然后进行key的聚合或连接等操作。由于shuffle write的过程中，task给Reduce端的stage的每个task都创建了一个磁盘文件，因此shuffle read的过程中，每个task只要从上游stage的所有task所在节点上，拉取属于自己的那一个磁盘文件即可。
shuffle read的拉取过程是一边拉取一边进行聚合的。每个shuffle read task都会有一个自己的buffer缓冲，每次都只能拉取与buffer缓冲相同大小的数据，然后通过内存中的一个Map进行聚合等操作。聚合完一批数据后，再拉取下一批数据，并放到buffer缓冲中进行聚合操作。以此类推，直到最后将所有数据到拉取完，并得到最终的结果。
注意
（1）buffer起到的是缓存作用，缓存能够加速写磁盘，提高计算的效率,buffer的默认大小32k。
（2）分区器：根据hash/numRedcue取模决定数据由几个Reduce处理，也决定了写入几个buffer中
（3）block file：磁盘小文件，从图中我们可以知道磁盘小文件的个数计算公式：
block file=M*R
(4) M为map task的数量，R为Reduce的数量，一般Reduce的数量等于buffer的数量，都是由分区器决定的
Hash shuffle普通机制的问题
（1).Shuffle阶段在磁盘上会产生海量的小文件，建立通信和拉取数据的次数变多,此时会产生大量耗时低效的 IO 操作 (因为产生过多的小文件)
（2).可能导致OOM，大量耗时低效的 IO 操作 ，导致写磁盘时的对象过多，读磁盘时候的对象也过多，这些对象存储在堆内存中，会导致堆内存不足，相应会导致频繁的GC，GC会导致OOM。由于内存中需要保存海量文件操作句柄和临时信息，如果数据处理的规模比较庞大的话，内存不可承受，会出现 OOM 等问题
合并机制的Hash shuffle
合并机制就是复用buffer缓冲区，开启合并机制的配置是spark.shuffle.consolidateFiles。该参数默认值为false，将其设置为true即可开启优化机制。通常来说，如果我们使用HashShuffleManager，那么都建议开启这个选项。
![]()
图解
这里有6个这里有6个shuffleMapTask，数据类别还是分成3种类型，因为Hash算法会根据你的 Key 进行分类，在同一个进程中，无论是有多少过Task，都会把同样的Key放在同一个Buffer里，然后把Buffer中的数据写入以Core数量为单位的本地文件中，(一个Core只有一种类型的Key的数据)，每1个Task所在的进程中，分别写入共同进程中的3份本地文件，这里有6个shuffleMapTasks，所以总共输出是 2个Cores x 3个分类文件 = 6个本地小文件。
注意
（1).启动HashShuffle的合并机制ConsolidatedShuffle的配置
spark.shuffle.consolidateFiles=true（2).block file=Core*R
Core为CPU的核数，R为Reduce的数量
Hash shuffle合并机制的问题
如果 Reducer 端的并行任务或者是数据分片过多的话则 Core * Reducer Task 依旧过大，也会产生很多小文件。
Sort shuffle
Sort shuffle的普通机制
在该模式下，数据会先写入一个数据结构，聚合算子写入Map，一边通过Map局部聚合，一边写入内存。Join算子写入ArrayList直接写入内存中。然后需要判断是否达到阈值（5M），如果达到就会将内存数据结构的数据写入到磁盘，清空内存数据结构。
在溢写磁盘前，先根据key进行排序，排序过后的数据，会分批写入到磁盘文件中。默认批次为10000条，数据会以每批一万条写入到磁盘文件。写入磁盘文件通过缓冲区溢写的方式，每次溢写都会产生一个磁盘文件，也就是说一个task过程会产生多个临时文件
。
最后在每个task中，将所有的临时文件合并，这就是merge过程，此过程将所有临时文件读取出来，一次写入到最终文件。意味着一个task的所有数据都在这一个文件中。同时单独写一份索引文件，标识下游各个task的数据在文件中的索引start offset和end offset。
这样算来如果第一个stage 50个task，每个Executor执行一个task，那么无论下游有几个task，就需要50*2=100个磁盘文件。
好处
1. 小文件明显变少了，一个task只生成一个file文件
2. file文件整体有序，加上索引文件的辅助，查找变快，虽然排序浪费一些性能，但是查找变快很多
bypass模式的sortShuffle
bypass机制运行条件
![]()
好处
该机制与sortshuffle的普通机制相比，在shuffleMapTask不多的情况下，首先写的机制是不同，其次不会进行排序。这样就可以节约一部分性能开销。
总结
在shuffleMapTask数量小于默认值200时，启用bypass模式的sortShuffle(原因是数据量本身比较少，没必要进行sort全排序，因为数据量少本身查询速度就快，正好省了sort的那部分性能开销。)
该机制与普通SortShuffleManager运行机制的不同在于：
第一: 磁盘写机制不同；
第二: 不会进行sort排序；
Shuffle调优
Shuffle核心组件
碰到ShuffleDenpendency就进行stage的划分，ShuffleMapStage: 为shuffle提供数据的中间stage，ResultStage: 为一个action操作计算结果的stage。
Shuffle原理剖析
MapOutputTracker
解决的一个问题是resut task如何知道从哪个Executor去拉取Shuffle data
ShuffleWriter
（1）HashShuffleWriter
![]()
特点：根据Hash分区，分区数是m * n 个。
val counts: RDD[(String, Int)]
= wordCount.reduceByKey(new HashPartitioner(2), (x, y) => x + y)
（2）SortShuffleWriter
![]()
特点：
a、文件数量为m
b、如果需要排序或者需要combine，那么每一个partition数据排序要自己实现。（SortShuffleWriter里的sort指的是对partition的分区号进行排序）
c、数据先放在内存,内存不够则写到磁盘中,最后再全部写到磁盘。
（3）BypassMergeSortShuffleWriter
这种模式同时具有HashShuffleWriter和SortShuffleter的特点。因为其实HashShufflerWriter的性能不错，但是如果task数太多的话，性能话下降，所以Spark在task数较少的时候自动使用了这种模式，一开始还是像HashShufflerWriter那种生成多个文件，但是最后会把多个文件合并成一个文件。然后下游来读取文件。默认map的分区需要小于spark.shuffle.sort.bypassMergeThreshold(默认是200),因为如何分区数太多，产生的小文件就会很多性能就会下降。
Spark Shuffle参数调优
spark.shuffle.file.buffer
默认值：32k
参数说明：该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前，会先写入buffer缓冲中，待缓冲写满之后，才会溢写到磁盘。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如64k），从而减少shuffle write过程中溢写磁盘文件的次数，也就可以减少磁盘IO次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。
spark.reducer.maxSizeInFlight
spark.shuffle.io.maxRetries
默认值：3
参数说明：shuffle read task从shuffle write task所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败。
调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现，对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数可以大幅度提升稳定性。
spark.shuffle.io.retryWait
spark.shuffle.memoryFraction
（Spark1.6是这个参数，1.6以后参数变了，具体参考上一讲Spark内存模型知识）
spark.shuffle.manager
默认值：sort
参数说明：该参数用于设置ShuffleManager的类型。Spark 1.5以后，有三个可选项：hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项，但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。Spark1.6以后把hash方式给移除了，tungsten-sort与sort类似，但是使用了tungsten计划中的堆外内存管理机制，内存使用效率更高。
调优建议：由于SortShuffleManager默认会对数据进行排序，因此如果你的业务逻辑中需要该排序机制的话，则使用默认的SortShuffleManager就可以；而如果你的业务逻辑不需要对数据进行排序，那么建议参考后面的几个参数调优，通过bypass机制或优化的HashShuffleManager来避免排序操作，同时提供较好的磁盘读写性能。这里要注意的是，tungsten-sort要慎用，因为之前发现了一些相应的bug。
spark.shuffle.sort.bypassMergeThreshold
默认值：200
参数说明：当ShuffleManager为SortShuffleManager时，如果shuffle read task的数量小于这个阈值（默认是200），则shuffle write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。
调优建议：当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task的数量。那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。
上述就是小编为大家分享的如何进行Spark Shuffle 原理分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
网站题目：如何进行SparkShuffle原理分析
分享地址：
http://cdkjz.cn/article/iioidh.html
