Spark大数据处理之 RDD粗粒度转换的威力

在从WordCount看Spark大数据处理的核心机制（2）中我们看到Spark为了支持迭代和交互式数据挖掘，而明确提出了内存中可重用的数据集RDD。RDD的只读特性，再加上粗粒度转换操作形成的Lineage，形成了它独立的高效容错机制。

RDD的粗粒度的转换是否有足够的表达能力，来支持多种多样的应用需求呢？先看看RDD究竟有哪些API，然后看它们如何模拟Google经典的MapReduce和图数据处理框架Pregel。

RDD的API

转换

def map[U](f: T => U): RDD[U]

将RDD[T]经过f转换成RDD[U]，T和U一一映射，两个RDD元素个数相等

def flatMap[U](f: T => TraversableOnce[U]): RDD[U]

将RDD[T]经过f闭包转换成RDD[U]，一个T可以映射成0到多个U，两个RDD元素通常不等

def mapPartitions[U: ClassTag](
      f: Iterator[T] => Iterator[U]): RDD[U]

mapPartitions是partition级的转换，多元素到多元素或单元素的转换。

还记得从WordCount看Spark大数据处理的核心机制（1）中我们扒开的countByValue函数吗？它就是通过mapPartitions来统计每个partition上所有单词的计数。

def union(other: RDD[T]): RDD[T]

将两个RDD[T]合并成一个RDD[T]。

可能一开始会觉得union操作会耗时较大，实际上这个操作非常廉价。RDD的元信息中包含了Partition/Lineage等信息，union只是合并元信息，而并不涉及具体的数据，so easy。

def distinct(): RDD[T]

将原RDD[T]转换成新的RDD[T]，但每个元素只出现一次。

distinct从业务意义上很容易理解，但消耗却不少，需要通过网络交换各个Partition的数据，小伙伴们要注意了。

以下所有的转换都仅针对RDD[(K, V)]有效，是通过把RDD[(K, V)]隐式转换成PairRDDFunctions[K, V]获得的。使用前一定要导入SparkContext内的隐式转化函数，如下：

import org.apache.spark.SparkContext._

不然找不到下面的函数，不要说一码不负责乱说哈。

隐式转换是Scala带来的好东西，类似于C#或Ruby中可以把类打开的功能，实在是写出优雅代码不可多得的工具。不清楚的小伙伴记得一定要GFSOSO哈。

def groupByKey(): RDD[(K, Iterable[V])]

将RDD[(K, V)]中所有(K, V)键值对按K进行分组，每组一个元素，形成新的RDD[(K, Iterable[V])]。

def reduceByKey(func: (V, V) => V): RDD[(K, V)]

将RDD[(K, V)]中所有(K, V)键值对按K进行分组归并，最终每个K只有一个(K, V)与之对应。

def join[W](other: RDD[(K, W)]): RDD[(K, (V, W))]

将RDD[(K, V)]与RDD[(K, W)做join操作，形成新的RDD[(K, (V, W))，最终形成的RDD中只有两个RDD中共有的K。

def cogroup[W](other: RDD[(K, W)]): RDD[(K, (Iterable[V], Iterable[W]))]

将RDD[(K, V)]与RDD[(K, W)一起分组。

值得注意的是：结果里面包含两个RDD中所有的K，也就是说Iterable[V]和Iterable[W]中可能某个为空。

def mapValues[U](f: V => U): RDD[(K, U)]

仅对(K, V)中的V进行转换，转换后和原先的K一起形成新的(K, U)键值对，通常和groupByKey一起使用。

def partitionBy(partitioner: Partitioner): RDD[(K, V)]

将RDD[(K, V)]按照K进行重新分区。

重新分区对每个分区数据非常少的情况很有帮助。减少分区，任务数量也会随着分区的减少而减少，降低大量任务调度的开销。

所有转换返回的一定是RDD。

动作

def count(): Long

统计RDD[T]中元素T的个数。

def reduce(f: (T, T) => T): T

对RDD[T]中的元素进行两两合并，最终合并成一个值。

比如对RDD[Int]中的所有元素求和:ints.reduce((i1, i2) => i1 + i2)

def collect(): Array[T]

将RDD[T]中所有元素从Slave上收集到Driver上。

该方法应该只应用在元素较少的RDD上，否则Driver一定OutOfMemory。

def saveAsTextFile(path: String): Unit

把RDD[T]中的所有元素保存到磁盘，通常是保存到分布式文件系统。

注意path是个目录，RDD中的每个元素对应了目录下的一个文件。保存后形成：/path/part-00000，

/path/part-00001等文件。最大的好处就是解决了通过collect到Driver再保存到磁盘的问题。

常用的RDD API就上面这些，更多请参考Spark官方文档。

所有动作返回的一定不是RDD。

转换不会加载数据，仅记录Lineage而已，而动作会触发数据的加载，并根据Lineage完成所有的转换，是延迟计算，极大地提升效率。

RDD对MapReduce的模拟

来看这篇文章的小伙伴们应该都清楚MapReduce模型了，它很容易使用RDD进行描述。假设有一个输入数据集（其元素类型为T），和两个函数myMap: T => List[(Ki, Vi)] 和 myReduce: (Ki; List[Vi]) ) List[R]，RDD API模拟代码如下：

data.flatMap(myMap)
	.groupByKey()
	.map((k, vs) => myReduce(k, vs))

如果任务包含combiner，则相应的代码为：

data.flatMap(myMap)
	.reduceByKey(myCombiner)
	.map((k, v) => myReduce(k, v))

RDD对Pregel图计算的模拟

Pregel是面向图算法的基于BSP范式的编程模型。程序由一系列超步（Superstep）协调迭代运行。在每个超步中，各个顶点执行用户函数，并更新相应的顶点状态，变异图拓扑，然后向下一个超步的顶点集发送消息。这种模型能够描述很多图算法，包括最短路径，双边匹配和PageRank等，我们以PageRank为例来说明。

PageRank可是搜索引擎的基础，经典的大数据算法，还不知道的小伙伴请自行GFSOSO哈。

当前PageRank记为r，顶点表示状态。在每个超步中，各个顶点向其所有邻居发送贡献值r/n，这里n是邻居的数目。下一个超步开始时，每个顶点将其分值（rank）更新为 α/N + (1 - α) * Σci，这里的求和是各个顶点收到的所有贡献值的和，N是顶点的总数。

Pregel的通信模式可以用RDD来描述，主要思想是：将每个超步中的顶点状态和要发送的消息存储为RDD，然后根据顶点ID分组，进行Shuffle通信（即cogroup操作）。然后对每个顶点ID上的状态和消息应用用户函数（即mapValues操作），产生一个新的RDD，即(VertexID, (NewState, OutgoingMessages))。然后执行map操作分离出下一次迭代的顶点状态和消息（即mapValues和flatMap操作）。代码如下：

val vertices = // RDD of (ID, Vertice) pairs
val incomingMessages = // RDD of (ID, Message) pairs
val grouped = vertices.cogroup(incomingMessages)
val newData = grouped.mapValues {
    (vert, incomingMsgs) => spreadRank(vert, incomingMsgs)
    // returns (newState, outgoingMsgs)
}.cache()
val newVerts = newData.mapValues((v,ms) => v)
val newMsgs = newData.flatMap((id,(v,ms)) => ms)
def spreadRank(...): ... = {
	// spread the incoming rank to outgoing rank
}

需要注意的是，这种实现方法中，RDD grouped，newData和newVerts的分区方法与输入RDD vertices一样。所以，顶点状态一直存在于它们开始执行的机器上，这跟原Pregel一样，这样就减少了通信成本。因为cogroup和mapValues保持了与输入RDD相同的分区方法，所以分区是自动进行的。

如果觉得上面这一段有难度，请在微信公众号上联系一码。

经过四篇文章，Spark基础知识还剩下共享变量，下一篇文章讲过共享变量后，开始讲开发Spark应用经常遇到的问题，以及如何优化性能。