spark分区

 一，前言

1，概念

• 输入文件可能是一个或者多个文件file。
• 而一个文件是划分成多个文件块来处理的，文件块就是block。
• spark读取文件的时候会设置解析文件的格式，一般是将若干个Block合并成一个输入分片，称为InputSplit。注意InputSplit不能跨越文件。
• 随后将为这些输入分片生成具体的Task。InputSplit与Task是一一对应的关系。
• Task经过机器的处理产生结果放到partition，Task和partition不是绝对相等。Task个数相当于任务数个数，partition相当于干了一轮活产生的结果数，干活的是节点里面的Executor里面的core，core相当于工人，有几个工人就一轮能干几个结果放到partition里面。

•  每个节点（work node一台计算机，类似于一个工厂）可以有一个或多个Executor（一个执行器也称为计算节点，类似于一个房间，一个工厂有很多房间）。
• 每个Executor由若干core（类似于一个工人，一个房间有很多工人）组成，每个Executor的每个core一次只能执行一个Task（类似于做好的一个凳子）。

每个Task执行的结果就是生成了目标RDD的一个partiton。
注意： 这里的core是虚拟的core而不是机器的物理CPU核，可以理解为就是Executor的一个工作线程。
Task被执行的并发度 = Executor数目 * 每个Executor核数（=core总个数）

即：逻辑：把一个文件分到几个区去处理，并且可以定义我这块数据分到哪个区去的方法，然后系统自动安排多少task，给机器的几个工人core去处理，结果保存到区里面。

2，partition的数目设置

对于数据读入阶段，例如sc.textFile，输入文件被划分为多少InputSplit就会需要多少初始Task。
在Map阶段partition数目保持不变。

（eg：map阶段：把原来一行单词以空格划分单词，并且给每个单词加一个数字1变成<he,1>）
在Reduce阶段，RDD的聚合会触发shuffle操作，聚合后的RDD的partition数目跟具体操作有关，

（eg：reduce阶段:把<he,1>，<he,1>变成<he,2> ,并且会对key排序）

例如repartition操作会聚合成指定分区数，还有一些算子是可配置的。
RDD在计算的时候，每个分区都会起一个task，所以rdd的分区数目决定了总的task数目。
申请的计算节点（Executor）数目和每个计算节点核数，决定了你同一时刻可以并行执行的task。

比如：

RDD有100个分区，那么计算的时候就会生成100个task，设置task间并行的参数是

conf spark.sql.shuffle.partitions=100

你的资源配置为10个计算节点，（执行器excutor）  --num-executors 10    默认为2一般设置在50-100之间

每个2个核，executor-cores 2   一般 2~4 为宜

同一时刻可以并行的task数目为20，计算这个RDD就需要5个轮次。

如果计算资源不变，你有101个task的话，就需要6个轮次，在最后一轮中，只有一个task在执行，其余核都在空转。

如果资源不变，你的RDD只有2个分区，那么同一时刻只有2个task运行，其余18个核空转，造成资源浪费。

这就是在spark调优中，增大RDD分区数目，增大任务并行度的原因。
 

二，前提

使用repartition 使得任务能够并行执行的话（一轮就把活干完），分配的core的数量一定要略微大于最大的分区数，才能使得所有的task能够并行执行。
这里举个例子，比如当前RDD有100个分区，如果我分配的是50个core（spark.executor.instances * spark.executor.cores）,那么同时执行的任务最多只有50。同一个操作需分成两部分串行执行，。这个时候如果有一个节点有问题（并行度是50 -1*2 = 48），那么就需要再次申请资源，如果资源紧张，需要等待，如果申请的时候申请的是54个core，虽然看起来有点浪费，但是对于任务的稳定性而言，却可能会有很大的提升。当然最好的视情况是分配102-110比较合理。

repartition适用场景

1、单个分区处理能力不够

        RDD单个分区数据量比较大，或者单个分区处理比较慢，都可以通过repartition进行操作，这个时候numPartitions自然是要比当前的分区数要大一些。
单个分区数据量比较大，这种case在读取和处理hdfs文件的时候并不常见，因为默认spark读取hdfs文件的分区数和hdfs文件的block的数量是一致的。这个mr的mapper数量类似。但是对于Spark Streaming 任务，如果是window窗口较长，就比较容易出现单个分区数据量较大的情况。
还有一种case，比如每个需要有外部的一些读写操作，这个时候大量数据在一个partition中，会因为外部存储、单机处理能力，网络等的性能瓶颈导致数据每个partition的数据处理变慢，举个例子，往redis里写数据，如果每个partition数据量特别大，如果使用的是redis的非批量的，基本每个数据需要一次数据请求，假设采用的是pipleline的形式，依然会因为数据量很大导致这个分区的写入很慢，从而导致任务执行时间较长。这种问题在Spark Streaming的任务中影响比较大。这个时候通过repartition增加分区数量效果也会很明显。

2、数据倾斜

        数据倾斜，这个自然不不用说了，使用repartition可以将数据进行打散，避免倾斜导致的执行耗时不均匀的问题。虽然这种情况是完全可以减少任务执行的时间，但是对于数据量比价小的分区而言，很快就能处理完，此时如果executor空闲的话，其实是比较浪费资源的。所以如果是通过这个处理数据倾斜的话，建议开启动态资源分配。另外使用reapartition处理数据倾斜的时候，最好提前统计一下key的分布，这个比较常见的方法就是:

1 如果是hive的数据

select  count(1)  from table group by key

2 如果是rdd中统计

val keyCount =rdd.map((k,v) =>(k,1)).reduceByKey((a,b) =>(a+b)).sortBy(_._2,false).take(100)
print keyCount

总结
repartition是spark开发中使用非常多的一个操作，而且使用的是否合理直接影响到任务执行的快慢以及成功与否。是否需要进行repartition，以及repartition的数量是一个需要开发的同学多方面综合考虑的结果，并没有一成不变的经验。但是我这儿依然给出一个具体的思路以供参考：确定原始数据分区数量，以及分区大小，key的分布式，参考集群资源的是否充足以及资源使用分布（cpu和内存使用比例），然后综合考虑。

RDD分区的一个分区原则：尽可能是得分区的个数等于集群核心数目

无论是本地模式、Standalone模式、YARN模式或Mesos模式，我们都可以通过spark.default.parallelism来配置其默认分区个数，若没有设置该值，则根据不同的集群环境确定该值

 三，Spark数据分区方式简要

        在Spark中，RDD（Resilient Distributed Dataset）是其最基本的抽象数据集，其中每个RDD是由若干个Partition组成。在Job运行期间，参与运算的Partition数据分布在多台机器的内存当中。这里可将RDD看成一个非常大的数组，其中Partition是数组中的每个元素，并且这些元素分布在多台机器中。图一中，RDD1包含了5个Partition，RDD2包含了3个Partition，这些Partition分布在4个节点中。

                                                                                 图1 rdd&partition

      Spark包含两种数据分区方式：HashPartitioner（哈希分区）和RangePartitioner（范围分区）。一般而言，对于初始读入的数据是不具有任何的数据分区方式的。数据分区方式只作用于<Key，Value>形式的数据。因此，当一个Job包含Shuffle操作类型的算子时，如groupByKey，reduceByKey etc，此时就会使用数据分区方式来对数据进行分区，即确定某一个Key对应的键值对数据分配到哪一个Partition中。在Spark Shuffle阶段中，共分为Shuffle Write阶段和Shuffle Read阶段，其中在Shuffle Write阶段中，Shuffle Map Task对数据进行处理产生中间数据，然后再根据数据分区方式对中间数据进行分区。最终Shffle Read阶段中的Shuffle Read Task会拉取Shuffle Write阶段中产生的并已经分好区的中间数据。图2中描述了Shuffle阶段与Partition关系。下面则分别介绍Spark中存在的两种数据分区方式。

 
 

                                                         图二  the shuffle process in spark

1，HashPartitioner（哈希分区）

HashPartitioner采用哈希的方式对<Key，Value>键值对数据进行分区。其数据分区规则为 partitionId = Key.hashCode % numPartitions，其中partitionId代表该Key对应的键值对数据应当分配到的Partition标识，Key.hashCode表示该Key的哈希值，numPartitions表示包含的Partition个数。图3简单描述了HashPartitioner的数据分区过程。

2、HashPartitioner源码详解

在Spark中分区器直接决定了RDD中分区的个数；也决定了RDD中每条数据经过Shuffle过程属于哪个分区；也决定了Reduce的个数。这三点看起来是不同的方面的，但其深层的含义是一致的。

　　我们需要注意的是，只有Key-Value类型的RDD才有分区的，非Key-Value类型的RDD分区的值是None的。

　　在Spark中，存在两类分区函数：HashPartitioner和RangePartitioner，它们都是继承自Partitioner，主要提供了每个RDD有几个分区（numPartitions）以及对于给定的值返回一个分区ID（0~numPartitions-1），也就是决定这个值是属于那个分区的。

class HashPartitioner(partitions: Int) extends Partitioner {
  require(partitions >= 0, s"Number of partitions ($partitions) cannot be negative.")
 
  /**
    * 包含的分区个数
    */
  def numPartitions: Int = partitions
 
  /**
    * 获得Key对应的partitionId
    */
  def getPartition(key: Any): Int = key match {
    case null => 0
    case _ => Utils.nonNegativeMod(key.hashCode, numPartitions)
  }
 
  override def equals(other: Any): Boolean = other match {
    case h: HashPartitioner =>
      h.numPartitions == numPartitions
    case _ =>
      false
  }
 
  override def hashCode: Int = numPartitions
}
 
def nonNegativeMod(x: Int, mod: Int): Int = {
  val rawMod = x % mod
  rawMod + (if (rawMod < 0) mod else 0)
}

        根据上述代码，HashPartitioner增加了一个名为partitions的构造器参数作为分区数，重写的numPartitions方法只是返回了partitions。重写的getPartition方法实际以key的hashCode和numPartitions作为参数调用了Utils工具类的nonNegativeMod方法（具体实现可以参阅附录A）。nonNegativeMod方法将对key的hashCode和numPartitions进行取模运算，得到key对应的分区索引。使用哈希和取模的方式，可以方便的计算出下游RDD的各个分区将具体处理哪些key。由于上游RDD所处理的key的哈希值在取模后很可能产生数据倾斜，所以HashPartitioner并不是一个均衡的分区计算器。equals方法先不用关注。

3、RangePartitioner源码详解

1、RangePartitioner原理简介 

        Spark引入RangePartitioner的目的是为了解决HashPartitioner所带来的分区倾斜问题，也即分区中包含的数据量不均衡问题。HashPartitioner采用哈希的方式将同一类型的Key分配到同一个Partition中，因此当某一或某几种类型数据量较多时，就会造成若干Partition中包含的数据过大问题，而在Job执行过程中，一个Partition对应一个Task，此时就会使得某几个Task运行过慢。RangePartitioner基于抽样的思想来对数据进行分区。图4简单描述了RangePartitioner的数据分区过程。

                                                      图四RangePartitioner的数据分区

2、RangePartitioner源码详解

 ① 确定采样数据的规模：RangePartitioner默认对生成的子RDD中的每个Partition采集20条数据，样本数据最大为1e6条

// 总共需要采集的样本数据个数，其中partitions代表最终子RDD中包含的Partition个数
val sampleSize = math.min(20.0 * partitions, 1e6)

② 确定父RDD中每个Partition中应当采集的数据量：这里注意的是，对父RDD中每个Partition采集的数据量会在平均值上乘以3，这里是为了后继在进行判断一个Partition是否发生了倾斜，当一个Partition包含的数据量超过了平均值的三倍，此时会认为该Partition发生了数据倾斜，会对该Partition调用sample算子进行重新采样。
 

// 被采样的RDD中每个partition应该被采集的数据，这里将平均采集每个partition中数据的3倍
val sampleSizePerPartition = math.ceil(3.0 * sampleSize / rdd.partitions.length).toInt

③ 调用sketch方法进行数据采样：sketch方法返回的结果为<采样RDD的数据量，<partitionId, 分区数据量，分区采样的数据量>>。在sketch方法中会使用水塘抽样算法对待采样的各个分区进行数据采样，这里采用水塘抽样算法是由于实现无法知道每个Partition中包含的数据量，而水塘抽样算法可以保证在不知道整体的数据量下仍然可以等概率地抽取出每条数据。图4简单描述了水塘抽样过程。

                                                         图4水塘抽样