Spark Sort Shuffle (二)

Spark Sort Shuffle (二)

[睡着的水-hzjs-2016.08.19]

一、为什么使用Sort-Based Shuffle?

------# Shuffle一般包含两阶段的任务：

1、产生Shuffle数据的阶段（map阶段；需要实现ShuffleManager中getWriter来写数据【数据可以BlockManager写到Memory\Disk\Tachyon等，例如像非常快的Shuffle,此时可以考虑把数据写在内存中，但是内存不稳定，建议采用MEMORY_AND_DISK方式】）；

2、使用Shuffle数据的阶段(reduce阶段，需要实现ShuffleManager的getReader,Reader会向Driver去获取上一个Stage产生的Shuffle数据)。#Spark的job会被划分成很多的Stage阶段：1、如果只有一个Stage，则这个Job就相当于只有Mapper阶段，当然不会产生Shuffle.适合于简单的ETL；2、如果不只有一个Stage,则最后一个Stage 就是最终的Reducer,最左侧的是一个mapper,中间的任意一个Stage都是其父Stage的Reducer,是其子Stage的mapper.

------# Spark Shuffle 在最开始的时候只支持hash-based Shuffle;默认mapper阶段会为Reduce阶段的每一个Task单独创建一个单独文件来保存该Task中要使用的数据，但是在一些情况下（例如在数据量非常大的情况下，产生大量小文件），会造成大量的随机磁盘I/O操作且会消耗大量的Memory。

这是很严重的问题，第一，不能处理大规模的数据，第二不能够运行在法规模的分布式集群上！后来加入Shuffle Consolidate 机制来将Shuffle 时候的文件数量减少到Core（核数） * R（并行任务数量） 个，但是当Reducer端并行数据分片过多的话C*R依然很大，依旧可能产生很多的问题，未逃脱打开文件过多的问题。

------# 为了让Spark在更大规模的集群上更高性能处理更大规模的数据，于是就引入了Sort-Based Shuffle.从此以后，Spark可以胜任任意规模的大数据的处理，尤其是随着钨丝计划的引入和优化，把spark更快速的在更大规模的集群处理更海量的数据的能力推向了一个新的巅峰。1.6版本至少支持三种类型的Shuffle.

------# 实现ShuffleManager接口可以根据自己的业务实际需要最优化的使用自定义的Shuffle。

------# Sort-Based Shuffle 会产生2M(M代表mapper阶段中并行的partition的总数数量，其实就是mapper的task的总数量)个Shuffle临时文件。1.6 版本默认采用的就是Sort-based Shuffle 的方式

------#修改conf/spark-default.conf 加入 spark.shuffle.manager SORT 进行配置。Sort-basedShuffle 不会为每个Reducer中的task生成一个单独的文件，相反，sort-based shuffle 会把mapper中每个ShuffleMapTask所有的输出数据data只写到一个文件中，因为每个ShuffleMapTask中的数据会被分类，所以Sort-based Shuffle使用了index文件存储具体ShuffleMapTask 输出数据在data文件中是如何分类的信息，所以说基于Sort-based 的Shuffle会在mapper中的每一个ShuffleMapTask 中产生两个文件：data文件与index文件，其中data文件是存储当前Task的Shuffle输出;Index存储data文件的数据通过partition 的分类信息，此时下一个阶段的Stage中task就是根据这个Index 文件获取自己所要抓取的数据。

# 回顾Shuffle的历史，产生的数据文件的个数为：

Basic Hash Shuffle : M * R

Condalidate 方式的Hash Shuffle : C * R

Sort-based Shuffle : 2M

二、Sort-Based Shuffle （针对的是shuffle过程,而不是数据本身）实战

------# 在Sort-based Shuffle的Reducer是是如何获取自己的数据的呢？？具体而言，Reducer首先找Driver去获取父Stage 中每个ShuffleMapTask 输出的位置信息，根据位置信息获取Index 文件，解析index 文件，从解析的index文件中获取data 文件中属于自己的那本分内容。

三、Sort-Based Shuffle 不足

1、如果Mapper中Task的数量过大，依旧会产生很多的小文件，此时shuffle传递数据的过程中到Reducer 端，reduce会需要同时id啊亮的记录进行反序列化，导致大量的内存消耗和GC的巨大负担，造成系统缓慢甚至崩溃！

2、如果需要在分片内也进行排序的话，此时就需要Mapper端和Reducer端的两次排序