Spark RDD进阶

分析WordCount

sc.textFile("hdfs://train:9000/demo/word") //RDD0
      .flatMap(_.split(" ")) //RDD1
      .map((_,1))   //RDD2
      .reduceByKey(_+_)  //RDD3  finalRDD
      .collect()  //Array  任务提交

将RDD->RDD这种变换关系描述称为RDD血统/lineage。
每个stage中的任务数取决于线程数，也就是分区的数量。 在每个stage之间存在着shuffle阶段。
Spark会尽可能的将执行任务的线程数减少。如果算子之间不会使数据结构变换，则可以共用一个线程，但是如果需要数据发生洗牌等，则进入下一个阶段。这样做可以减少线程之间的通信，避免浪费。

RDD都有哪些特性？

• RDD具有分区-分区数等于该RDD并行度
• 每个分区独立运算，尽可能实现分区本地性运算
• 只读的数据集且RDD与RDD之间存在着相互依赖关系
• 针对于key-value RDD，可以指定分区策略【可选】
• 基于数据所属的位置，选择最优位置实现本地性计算【可选】

RDD容错

在理解DAGSchedule如何做状态划分的前提是需要了解一个专业术语lineage。通常被人们称为RDD的血统。在了解什么是RDD的血统之前，先来看看程序猿进化过程。

上图中描述了一个程序猿起源变化的过程，我们可以近似的理解类似于RDD的转换也是一样，Spark的计算本质就是对RDD做各种转换，因为RDD是一个不可变只读的集合，因此每次的转换都需要上一次的RDD作为本次转换的输入。因此RDD的lineage描述的是RDD间的相互依赖关系。为了保证RDD中数据的健壮性，RDD数据集通过所谓的血统关系(Lineage)记住了它是如何从其他RDD中演变过来的。Spark将RDD之间的关系归类为宽依赖和窄依赖。 Spark会根据Lineage存储的RDD的依赖关系对RDD计算做故障容错。目前Spark的容错策略根据RDD依赖关系重新计算-无需干预、RDD做Cache-临时缓存(内存)、RDD做Checkpoint-持久化手段完成RDD计算的故障容错。

RDD缓存

缓存是一种RDD计算容错的一种手段，程序在RDD数据丢失的时候，可以通过缓存快速计算当前RDD的值，而不需要反推出所有的RDD重新计算。因此Spark在需要对某个RDD多次使用的时候，为了提高程序的执行效率用户可以考虑使用RDD的cache。

scala> var finalRDD=sc.textFile("hdfs://train:9000/demo/word").flatMap(_.split(" ")).map((_,1)).reduceByKey(_+_)
finalRDD: org.apache.spark.rdd.RDD[(String, Int)] = ShuffledRDD[9] at reduceByKey at <console>:24

//进行缓存
scala> finalRDD.cache
res1: org.apache.spark.rdd.RDD[(String, Int)] = ShuffledRDD[9] at reduceByKey at <console>:24

scala> finalRDD.collect
res2: Array[(String, Int)] = Array((this,1), (is,1), (haha,2), (day,2), (hello,2), (up,1), (yes,1), (demo,1), (good,2), (study,1))
//将文件删除后
scala> finalRDD.collect
res3: Array[(String, Int)] = Array((this,1), (is,1), (haha,2), (day,2), (hello,2), (up,1), (yes,1), (demo,1), (good,2), (study,1))

用户可以调用upersist方法清空缓存

scala> finalRDD.unpersist()
res4: org.apache.spark.rdd.RDD[(String, Int)] @scala.reflect.internal.annotations.uncheckedBounds = ShuffledRDD[9] at reduceByKey at <console>:24

除了调用cache之外，Spark提供了更细粒度的RDD缓存方案，用户可以根据集群的内存状态选择合适的缓存策略。用户可以使用persist方法指定缓存级别。

RDD#persist(StorageLevel.MEMORY_ONLY)

目前Spark支持的缓存方案如下：

object StorageLevel {
     
  val NONE = new StorageLevel(false, false, false, false)
  val DISK_ONLY = new StorageLevel(true, false, false, false) #仅仅存储磁盘
  val DISK_ONLY_2 = new StorageLevel(true, false, false, false, 2) #仅仅存储磁盘  存储两份
  val MEMORY_ONLY = new StorageLevel(false, true, false, true)
  val MEMORY_ONLY_2 = new StorageLevel(false, true, false, true, 2)
  val MEMORY_ONLY_SER = new StorageLevel(false, true, false, false) #先序列化在存储内存，费cpu节省内存
  val MEMORY_ONLY_SER_2 = new StorageLevel(false, true, false, false, 2)
  val MEMORY_AND_DISK = new StorageLevel(true, true, false, true)
  val MEMORY_AND_DISK_2 = new StorageLevel(true, true, false, true, 2)
  val MEMORY_AND_DISK_SER = new StorageLevel(true, true, false, false)
  val MEMORY_AND_DISK_SER_2 = new StorageLevel(true, true, false, false, 2)
  val OFF_HEAP = new StorageLevel(true, true, true, false, 1)
...

那如何选择呢？
默认情况下，性能最高的当然是MEMORY_ONLY，但前提是你的内存必须足够足够大，可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避免了这部分的性能开销；对这个RDD的后续算子操作，都是基于纯内存中的数据的操作，不需要从磁盘文件中读取数据，性能也很高；而且不需要复制一份数据副本，并远程传送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种策略的场景还是有限的，如果RDD中数据比较多时（比如几十亿），直接用这种持久化级别，会导致JVM的OOM内存溢出异常。

如果使用MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用MEMORY_ONLY_SER级别。该级别会将RDD数据序列化后再保存在内存中，此时每个partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。这种级别比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算子可以基于纯内存进行操作，因此性能总体还是比较高的。此外，可能发生的问题同上，如果RDD中的数据量过多的话，还是可能会导致OOM内存溢出的异常。

不要泄漏到磁盘，除非你在内存中计算需要很大的花费，或者可以过滤大量数据，保存部分相对重要的在内存中。否则存储在磁盘中计算速度会很慢，性能急剧降低。

后缀为_2的级别，必须将所有数据都复制一份副本，并发送到其他节点上，数据复制以及网络传输会导致较大的性能开销，除非是要求作业的高可用性，否则不建议使用。

Check Point机制

除了使用缓存机制可以有效的保证RDD的故障恢复，但是如果缓存失效还是会在导致系统重新计算RDD的结果，所以对于一些RDD的lineage较长的场景，计算比较耗时，用户可以尝试使用checkpoint机制存储RDD的计算结果，该种机制和缓存最大的不同在于，使用checkpoint之后被checkpoint的RDD数据直接持久化在文件系统中，一般推荐将结果写在hdfs中，这种checpoint并不会自动清空。

val sc = new SparkContext(conf)

    sc.setCheckpointDir("hdfs://train:9000/checkpoints")
    val rdd1 = sc.textFile("hdfs://train:9000/demo/word")
      .map(line=>{
     
        println(line)
      })

    //对当前RDD做标记
    rdd1.checkpoint()

    rdd1.collect()

因此在checkpoint一般需要和cache连用，这样就可以保证计算一次。

sc.setCheckpointDir("hdfs://train:9000/checkpoints")
    val rdd1 = sc.textFile("hdfs://train:9000/demo/word")
      .map(line=>{
     
        println(line)
      })

    rdd1.persist(StorageLevel.MEMORY_AND_DISK) //先cache
    //对当前RDD做标记
    rdd1.checkpoint()

    rdd1.collect()

宽|窄依赖

Spark在执行任务前期，会根据RDD的转换关系形成一个任务执行DAG。将任务划分成若干个stage。Spark底层在划分stage的依据是根据RDD间的依赖关系划分。Spark将RDD与RDD间的转换分类：ShuffleDependency-宽依赖|NarrowDependency-窄依赖，Spark如果发现RDD与RDD之间存在窄依赖关系，系统会自动将存在窄依赖关系的RDD的计算算子归纳为一个stage，如果遇到宽依赖系统开启一个新的stage。

Spark宽窄依赖判断

宽依赖： 父RDD的一个分区对应了子RDD的多个分区，出现分叉就认定为宽依赖(即一对多、多对多)
窄依赖： 父RDD的1个分区(多个父RDD)仅仅只对应子RDD的一个分区认定为窄依赖(一对一、多对一)。

Spark在任务提交前期，首先根据finalRDD逆推出所有依赖RDD，以及RDD间依赖关系，如果遇到窄依赖合并在当前的stage中，如果是宽依赖开启新的stage。