Spark Shuffle过程的一些小结（译 Shuffle Performance in Apache Spark）

• 题目：
    Shuffle Performance in Apache Spark
• 发表年份：
    February - 2015
• 所在会议：
    International Journal of Engineering Research & Technology
• 作者：
  Nirali Rana Department of Computer Engineering GTU PG School, Gujarat Technological University Ahmedabad , India. Shyam Deshmukh Assistance Professor: dept. of IT Pune Institute of Computer Technology, Pune, India.
• 中文摘要：
    Apache Spark 是一个在内存中运算并且调度、分配、监控其上应用的的集群计算框架。两种类型的因素用于改善Spark的性能：Optimization（最优化）和Latency Hiding（延迟隐藏）。在分布式数据处理平台，通常会通过很流行的、也是很传统的被称作shuffle（洗牌）的阶段来收集数据。这篇论文通过上述两种优化因素来比较Hadoop和Spark之间的性能，且结论是，Apache Spark的Shuffle过程要快于Hadoop的Shuffle过程。

• 本文解决的问题：

  • 问题一
    Spark的Shuffle过程的优化。
    解决思路或方案：
    1.通过merge中间结果来仿真Spark过程
    2.创建大的Shuffle文件
    3.通过列式压缩，将瓶颈传递给CPU（慎重）（在map阶段，Spark也提供参数用来将map的输出数据进行压缩）
    我们就第二种优化方案（创建大的Shuffle文件）的实现进行补充：
    ①引入第二种优化方案的原因：
    产生的FileSegment过多。每个ShuffleMapTask产生R（reducer个数）个FileSegment，M个ShuffleMapTask就会产生M * R个文件。一般Spark job的M和R都很大，因此磁盘上会存在大量的数据文件。如下图：
    ②解决方案：
    在一个slot*（core）上连续执行的ShuffleMapTasks可以共用一个输出文件ShuffleFile。先执行完的ShuffleMapTask形成ShuffleBlock i，后执行的ShuffleMapTask可以将输出数据直接追加到ShuffleBlock i后面，形成ShuffleBlock i’，每个ShuffleBlock被称为FileSegment。下一个stage的reducer只需要fetch整个ShuffleFile就行了。这样，每个worker持有的文件数降为slot* R。过程如下图：

  • 问题二
    Spark的Shuffle过程引起的延迟的优化。
    解决思路或方案：
      Spark采用了prefetch“预取”的延迟隐藏技术：这种方法尽可能地增加任务（tasks）的并行度，通过在数据被需要之前就fetch的方式，进而使得CPU保持忙碌状态。
      预取有很多影响因素，比如，我们要尽量避免将数据或者是服务放置到cloud云端（很明显，这样的话服务会发生延迟）。
      一个实时的“数据预取算法”是当程序将优先的shuffle文件置为map阶段完成状态的时候为基础启动的。此时，reduces可以在map没有执行完毕的时候进行数据的fetch操作（个人理解：该fetch的主体是ShuffleMapTask）。

  • 问题三
    Spark的Shuffle过程的策略选择及与对比分析。
    解决思路或方案：
      Spark的Shuffle过程的可选两种方式：Sort-based Shuffle和Hash-based Shuffle。
      hash-based故名思义也就是在Shuffle的过程中写数据时不做排序操作，只是将数据根据Hash的结果，将各个Reduce分区的数据写到各自的磁盘文件中。这样带来的问题就是如果Reduce分区的数量比较大的话，将会产生大量的磁盘文件（Map*Reduce）（已经有相应的优化策略）。如果文件数量特别巨大，对文件读写的性能会带来比较大的影响，此外由于同时打开的文件句柄数量众多，序列化，以及压缩等操作需要分配的临时内存空间也可能会迅速膨胀到无法接受的地步，对内存的使用和GC带来很大的压力，在Executor内存比较小的情况下尤为突出，例如Spark on Yarn模式。但是这种方式也是有改善的方法的：
      sort-based是Spark1.1版本之后实现的一个试验性（也就是一些功能和接口还在开发演变中）的ShuffleManager，它在写入分区数据的时候，首先会根据实际情况对数据采用不同的方式进行排序操作，底线是至少按照Reduce分区Partition进行排序，这样来至于同一个Map任务Shuffle到不同的Reduce分区中去的所有数据都可以写入到同一个外部磁盘文件中去，用简单的Offset标志不同Reduce分区的数据在这个文件中的偏移量。这样一个Map任务就只需要生成一个shuffle文件，从而避免了上述HashShuffleManager可能遇到的文件数量巨大的问题。上述过程与mapreduce的过程类似。
    【补充】Spark与Hadoop的Shuffle过程的区别：
    ①Spark与Hadoop之间的差别：Hadoop的shuffle过程是明显的几个阶段：map()，spill，merge，shuffle，sort，reduce()等，是按照流程顺次执行的，属于push类型；但是，Spark不一样，因为Spark的Shuffle过程是算子驱动的，具有懒执行的特点，属于pull类型。
    ②Spark的Shuffle过程默认的策略是hash-based；而Hadoop的Shuffle过程默认的策略是sort-based。
    与相关工作相对的优缺点：
      Sort-based Shuffle和Hash-based Shuffle的性能比较，取决于内存，排序，文件操作等因素的综合影响。
      对于不需要进行排序的Shuffle操作来说，如repartition等，如果文件数量不是特别巨大，HashShuffleManager面临的内存问题不大，而SortShuffleManager需要额外的根据Partition进行排序，显然HashShuffleManager的效率会更高。
      而对于本来就需要在Map端进行排序的Shuffle操作来说，如ReduceByKey等，使用HashShuffleManager虽然在写数据时不排序，但在其它的步骤中仍然需要排序，而SortShuffleManager则可以将sort和reduce两个工作合并在一起执行。