关于RDD之间的转换逻辑的存储

转载

qingliangdexiar 2017-05-13 20:19:43 博主文章分类：big data

文章标签 关于RDD之间的转换逻辑的存储 文章分类 代码人生

我们再编程的时候，经常会出现这样的代码，你是否有过疑惑？
//第一句代码返回了一个RDD
Val a=sc.parallelize(List("bit","linc","xwc","fjg","wc","spark"),3)
//这句代码疑惑在这里，计算每个元素的单词长度呢？
Val b=a.map(word=>word.length)
//上面的代码a,与b都是RDD，从a-到b它的RDD是如何转换的，里面的信息之间的内在联系是什么？带着这个问题就是得了解什么才是真正的RDD，RDD里面都包含了那些东西，以及它们之间的关联是什么？
RDD内部数据结构？
1)分区信息的列表
2)对父RDD的依赖信息
3)对Key-value键值对数据类型的分区器
4）计算分区的函数
5)每个数据分区的物理地址列表
RDD内部5个属性重要讲解
     RDD的5个主要属性对应的代码主要为：
分区　　 protected def getPartitions: Array[Partition] 以及 final def partitions: Array[Partition]
计算每个partition 　　def compute(split: Partition, context: TaskContext): Iterator[T]
对其它RDD的依赖　　构造函数中的 deps: Seq[Dependency[_]] 以及 protected def getDependencies: Seq[Dependency[_]] = deps 以及 final def dependencies: Seq[Dependency[T]]
kv类型RDD的partitioner 　　@transient val partitioner: Option[Partitioner] = None
preferred location 　　protected def getPreferredLoations(split: Partition): Seeq[String] = Nil 以及 final def preferredLocations(split: Partition): Seq[String]
其中的这些final方法: partitions, dependencies, preferedLocations都是考虑了checkpoint的结果。可见，checkpoint机制会对这些属性有所改变。
以下是对于这个注释的内容的思考：
1. RDD把定语去掉了，就是数据集；但是Spark作为一个分布式计算的框架，“数据集的转换”与“数据集”都是不可缺少的。Spark并没有把transformation这个概念抽象成一个基类，在我们写rdd.filter(func1).map(func2)这样的语句的时候，得到的最终结果是一个RDD，而scheduler使用的也只是这个RDD，因此，func1和func2这样的转换操作，作为一种元信息，肯定被RDD记录，作为RDD的属性。具体的讲，转换操作的信息会被记录在RDD的第二个属性“一个用于计算每个split的函数”中。所以，RDD不仅是弹性分布式数据集，也包括了数据集之间进行转换所需要的函数。
2. RDD的第三个属性“对其它RDD的依赖”，提供了以下信息：
　　　　a. 对这个RDD的父RDD的引用
　　　　b. 这个RDD的每个partition跟父RDD的partition的映射关系。
    假设有RDD X和RDD Y， X可以转换为Y，即 X -> Y。这是一个链式的构造，要获得Y，需要X和->。 ->即是转换操作，被记录于第二个属性，那么X在何处呢？X即是Dependency，是RDD的第三个属性。也就是说第二和第三个属性，使得RDD成为一个链式结构， X -> Y -> Z，知道Z，就可以上溯到作为源头的X，就能从X计算出Z来。这个就是为什么我们在最后一个RDD上调用action， Spark就可以开始执行，而不再需要提供其它的RDD。
下面看一下Spark对于以上两点具体的实现。
转换逻辑的存储
以常用的map操作为例 X -> Y， -> 在这里就是map。
复制代码
/**
   * Return a new RDD by applying a function to all elements of this RDD.
   */
def map[U: ClassTag](f: T => U): RDD[U] = withScope {
    val cleanF = sc.clean(f)
    new MapPartitionsRDD[U, T](this, (context, pid, iter) => iter.map(cleanF))
}
复制代码
作为map参数的f和map的语义一起指明了从当前RDD到MapPartitionsRDD转换的逻辑。而这个逻辑，作为参数被传递给MapPartitionsRDD，即 (context, pid, iter) => iter.map(cleanF))。下面看一下MapPartitionsRDD是如何储存这个逻辑的。
复制代码
private[spark] class MapPartitionsRDD[U: ClassTag, T: ClassTag](
    prev: RDD[T],
    f: (TaskContext, Int, Iterator[T]) => Iterator[U], // (TaskContext, partition index, iterator)
    preservesPartitioning: Boolean = false)
extends RDD[U](prev) {
override val partitioner = if (preservesPartitioning) firstParent[T].partitioner else None
override def getPartitions: Array[Partition] = firstParent[T].partitions
override def compute(split: Partition, context: TaskContext): Iterator[U] =
    f(context, split.index, firstParent[T].iterator(split, context))
}
复制代码
注意它的compute方法，首先，它调用了f, f就是我们在RDD的map方法中传给MapPartitionsRDD构造器的函数。也就是说MapPartitionsRDD储存了从父RDD转换的逻辑，即 ->
另外，注意compute方法中的 firstParent[T].iterator(split, context)。firstParent即是在map函数中传进来的this，也就是MapPartitionsRDD的父RDD，即X。
-> 和 X就这样被储存在了Y，即MapPartitionsRDD中。
关于Iterator
当compute方法被调用时，实际上会调用firstParent.iterator.map(cleanF)。那么此时，父RDD的迭代器会进行迭代和map计算吗？
答案是否，而且，可以看出Spark的RDD间的转换和Scala的迭代器间的转换是类似的，它们都可以认为是惰性的，即在x -> y中，储存了x和->，只有在需要计算时才会计算。
下面是scala.collection.Iterator的map方法的代码
def map[B](f: A => B): Iterator[B] = new AbstractIterator[B] {
    def hasNext = self.hasNext
    def next() = f(self.next())
}
在这里被返回的Iterator相当于y, 而调用map的Iterator相当于x。y持有对x的引用"self"，也持有转换的函数f，这就使得x -> y的链是完备的，因此Iterator上的map, filter等操作也构成了一个链式结构。
由于Iterator的这种特性，使得RDD的计算过程构成一个由函数组成的管道，在不对中间RDD进行persist的操作时，初始RDD的每个元素经过所有转换函数的处理后，再开始处理第二个元素；而不是所有元素都经过第一个函数处理后，形成一个数据集，这个数据集再进行转换。
比如，有三个RDD， X -> Y -> Z，都是使用的map进行转换，所使用的函数依次为f和g。
那么Z的compute方法的调用过程就成为了X.iterator.map(f).map(g)。
依据Iterator的特点， Z的迭代器的hasNext方法会返回X.iterator.hasNext.hasNext, Z的迭代器的next方法会返回g(f(X.iterator.next))。
因此，在一系列转过程中的中间的RDD如果没有被persist, 是不会作为一个数据集存在的。
另外，需要注意
trait Iterator[+A] extends TraversableOnce[A]
注意这个TraversableOnce的含义。所以，在自己实现RDD时，需要确保compute方法被调用时，它所使用的父RDD的迭代器没有在其它地方被使用过，不然一个已经被迭代过的迭代器再次被使用时，可能不会返回所有元素，或者干脆就不能继续迭代了(俺就曾经在compute里加了条日志，记了下iteartor.size(), 就悲剧了)。
父子关系的存储
先看下RDD的主构造器
abstract class RDD[T: ClassTag](
    @transient private var _sc: SparkContext,
    @transient private var deps: Seq[Dependency[_]]
) extends Serializable with Logging {
RDD的这个构造器展示了Dependency对于RDD定义的重要作用。 Dependency包含了这个RDD对其父RDD的依赖，这个依赖不仅包括其父RDD是什么，还包括子RDD的分区和父RDD的
分区之间的对应关系。
需要注意到，deps是一个Seq, 这说明单个的Dependency可能不足以描述父子RDD之间的依赖关系，得通过一系列的Dependency才能描述此关系。结合Dependency的定义，每个
Dependency只包含了一个父RDD的信息，但是一个RDD可能依赖多个RDD，所以这里用Seq[Dependency[_]]是有必要的。
如果使用
class NarrowDependency[T](parent: RDD[T], deps: List[List[Int]]) extends Dependency[T]{
override def _rdd: RDD[T] = parent
def getDependency(partition: Int) = deps(partition)
}
这种定义。在Dependency中提供子RDD的每个分区所依赖的父RDD的分区，那么NarrowDependency和ShuffleDependency就都可以用这一种方式来定义。
但是，Spark中却把NarrowDependency和ShuffleDependency分开定义，是为了区分什么呢？
或许是在NarrowDependency的定义中是定义的每个父RDD的分区被哪一个子RDD的分区依赖。
或许是在ShuffleDependency中不仅要提供子RDD的每个分区的依赖，还要提供父RDD的每个分区被哪些子RDD的分区依赖，这样进行shuffle时，才好由父RDD
的分区计算出对于不同子RDD分区的数据。
let us see see.
ShuffleDependency
之所以不像俺想的那样，是因为ShuffleDependency包括了与shuffle有关的更多的信息，这些信息包括：
partitioner 决定父RDD的每个record进入哪个子RDD分区。同时，它包含了reduce的个数的信息。
aggeragator 可选，对value进行聚合
mapSideCombine 是否要在map侧调用aggeragator，这是一个布尔类型值
keyOrdering 可选，决定key的顺序，用来对key排序。
serializer ？可选，或许是用来对key-value做序列化的，现在不能确定
以上是构造函数里的信息，此外ShuffleDependency的方法也提供了一些信息：
* shuffleId 还不确定有什么用
* shuffleHandle 提供与shuffle有关的信息。目前只看到它的一个实现: BaseShuffleHandler，构造器为(shuffleId, numTasks,
Dependency:[ShuffleDependency]) 不确定其具体作用
这些信息被shuffle过程使用，具体怎么用，得看shuffle的实现。
NarrowDependency
而NarrowDependency包括的情况更少，因为如果用List[List[Int]]来表示NarrowDependency的话，会把NarrowDependency的范围括大，比如多对多的关系也能用这种形式来表示。
Spark的实现里，NarrowDependency是个abstract class ,由不同的子类来应对具体的NarrowDependency的情况，每种情况用不同的方法来表示窄依赖。在NarrowDependency同
一个文件里，有两种NarrowDepdency的子类。在其它的RDD实现中，还有会其它的NarrowDependency，比如CoalescedRDD在一个匿名内部类里实现了自己的NarrowDependency。
OneToOneDependency 这种情况父RDD的分区跟子RDD的分区是一致的，每个子RDD分区依赖于同样索引号的父RDD的分区
RangeDependency 子RDD的一个分区依赖于父RDD的某个连续的分区段，比如0-3， 4-5这种。
其实现为：
class OneToOneDependency[T](rdd: RDD[T]) extends NarrowDependency[T](rdd) {
override def getParents(partitionId: Int): List[Int] = List(partitionId)
}
可见，父RDD的index为partitionId的分区被同样index的子RDD的分区依赖，父子RDD的分区是一对一的关系
class RangeDependency[T](rdd: RDD[T], inStart: Int, outStart: Int, length: Int)
extends NarrowDependency[T](rdd) {
override def getParents(partitionId: Int): List[Int] = {
    if (partitionId >= outStart && partitionId < outStart + length) {
      List(partitionId - outStart + inStart)
    } else {
      Nil
    }
}
}
它述描了子RDD的一些分区对父RDD的一些分区依赖关系，在父子RDD对应的分区间是OneToOne的关系，但这种关系只对父子RDD的一个区间有效。比如，
子RDD从index为2开始的分区，以OneToOne的关系依赖于父RDD从index为8开始的分区，这种依赖关系对于连续的3个分区有效，即(子2依赖父8), (子3依赖父9),
(子4依赖父10)
在UnionRDD中会使用RangeDependency
总结：
RDD储存了DAG Scheduler进行调度所需的信息(比如可以在RDD链中寻找ShuffleDependency来划分Stage)，也储存了生成目标RDD所需要的计算逻辑。也就是说RDD对于Spark这个框架，在某种程度上相当于元数据。可以看到，在driver往executor发送的作为task的字节数组中就包括了RDD。
在ShuffleMapTask中，反序列化后的taskBinary为：
    val (rdd, dep) = ser.deserialize[(RDD[_], ShuffleDependency[_, _, _])]( //返回结果是(RDD, ShuffleDependency)
      ByteBuffer.wrap(taskBinary.value), Thread.currentThread.getContextClassLoader)
在ResultTask中，反序列化后的taskBinary为：
    val (rdd, func) = ser.deserialize[(RDD[T], (TaskContext, Iterator[T]) => U)](
      ByteBuffer.wrap(taskBinary.value), Thread.currentThread.getContextClassLoader)
可以看到，RDD始终是作为计算逻辑的主要携带者被传给executor。
而RDD能做到这些，就是因为它储存了所需的信息在自己的定义中, 前边分析了一部分其实现的细节。RDD这个类的实现有很长很长的代码，也有更多有意思的细节需要进一步看一下。