Shuffle 操作

 

在spark中的主要操作，触发一个叫作shuffle的事件。shuffle是spark对于重新分布数据的机制，因此数据
能在partitions上进行不同的分组。Shuffle包含在executors和machines上的数据复制，使得
shuffle成为一个复杂的和昂贵的操作。

    backgroud

     为了理解在shuffle期间发生了什么，参照reduceByKey操作。reduceByKey操作产生新的RDD，单
个key的所有的value被放入到一个tuple中 -- 这个key和对所有的values执行一个减函数的结果。这个挑战
是并不是单个key的所有的values驻留在相同的partition，或者甚至相同的机器，但是它们必须被共同定位来
计算结果。
    在spark中，数据通常并不是分布在相同一个partition，为了在必要的地方指定的操作。在计算期
间，单个task将运行在单个partition - 因此，为单个reduceByKey的reduce任务执行去组织所有的数据，
Spark需要去执行个多对多的操作。它必须读取所有的partition来找到所有key的所有value，然后在
partition获取values到一起,来为每个key计算最终的结果--这就叫作shuffle。
   虽然在每个分区的新的shuffle的数据的一系列元素将被确定，partition是排序的，元素是无序的。如
果希望在shuffle之后进行排序，可能通过如下方式：
      1.mapPartitions 用来排序每个partition，例如：.sorted
      2.repartitionAndSortWithinPartitions  重新分区的同时，也重新排序
      3.sortBy 全局排序Rdd
      可能引起shuffle的操作有 
      repartition -- repartition coalesce
      'ByKey' -- groupByKey reduceByKey
      join -- cogroup join 

    性能影响

    shuffle是一个昂贵的操作，因此它包含 Disk I/O，数据序列化，网络I/O。为shuffle组织数据，
spark产生了一系列的任务 -- map任务来组织数据，一系列的reduce任务来聚合数据。这个命名来自于
MapReduce，并不直接关联Spark的map和reduce操作。
    本质上，每个map任务的结果是被保存在内存，除非内存不能容纳。然后，结果是基于目标分区进行排序，并
且写入到单个文件中。在Reduce端，task读取相关排序的blocks。
    shuffle操作能够消耗大量的 heap内存。因此在shuffle之前，在on-heap中申请了数据结构去组织记
录，然后再去转换这个记录。特别是，reduceByKey和aggregateByKey产生这些数据结构在map
端，’ByKey'操作产生数据结果在reduce端。
    当内存不能容纳数据时，Spark溢写这些表到disk，引进额外的disk I/O吞吐和增加GC。shuffle也产生
大量的中间文件在磁盘上。在Spark1.3时，这些文件是被保存，直到相关的RDDs是不再使用并且GC。这样做的
目的是，如果lineage是被重新计算时，shuffle的文件是不需要重新创建的。GC也可能只发生在一个很长的期
间之后的，如果application保持这个RDD的引用，或者如果GC不是很频繁。这意味着长时间的运行spark job
可能消耗大量的disk空间。临时存储的路径是通过spark.local.dir进行指定，在配置spark Context时。
    shuffle行为优化通过调整一些配置参数。 
    http://spark.apache.org/docs/1.6.0/configuration.html