Spark分布式计算和RDD模型研究

1背景介绍

现今分布式计算框架像MapReduce和Dryad都提供了高层次的原语，使用户不用操心任务分发和错误容忍，非常容易地编写出并行计算程序。然而这些框架都缺乏对分布式内存的抽象和支持，使其在某些应用场景下不够高效和强大。RDD(Resilient Distributed Datasets弹性分布式数据集)模型的产生动机主要来源于两种主流的应用场景：

Ø  迭代式算法：迭代式机器学习、图算法，包括PageRank、K-means聚类和逻辑回归(logistic regression)

Ø  交互式数据挖掘工具：用户在同一数据子集上运行多个Adhoc查询。

不难看出，这两种场景的共同之处是：）稳定存储中的数据；2）其他RDD。

Ø  只读：状态不可变，不能修改

Ø  分区：支持使RDD中的元素根据那个key来分区(从HDFS文件中创建出一个RDD，而行2则衍生出一个经过某些条件过滤后的RDD。行3将这个RDD errors缓存到内存中，然而第一个RDD lines不会驻留在内存中。这样做很有必要，因为errors可能非常小，足以全部装进内存，而原始数据则会非常庞大。经过缓存后，现在就可以反复重用errors数据了。我们这里做了两个操作，第一个是统计errors中包含MySQL字样的总行数，第二个则是取出包含HDFS字样的行的第三列时间，并保存成一个集合。

这里要注意的是前面曾经提到过的Spark的延迟处理。Spark调度器会将filter和map这两个转换保存到管道，然后一起发送给结点去计算。

2.3优势

RDD与DSM(distributed shared memory)的最大不同是：RDD只能通过粗粒度转换来创建，而DSM则允许对每个内存位置上数据的读和写。在这种定义下，DSM不仅包括了传统的共享内存系统，也包括了像提供了共享DHT(distributed hash table)的Piccolo以及分布式数据库等。所以RDD相比DSM有着下面这些优势：

Ø  高效的容错机制：没有检查点(checkpoint)开销，能够通过世族关系还原。而且还原只涉及了丢失数据分区的重计算，并且重算过程可以在不同结点并行进行，而无需回滚整个系统。

Ø  结点落后问题的缓和(mitigate straggler)：RDD的不可变性使得系统能够运行类似MapReduce备份任务，来缓和慢结点。这在DSM系统中却难以实现，因为多个相同任务一起运行会访问同样的内存数据而相互干扰。

Ø  批量操作：任务能够根据数据本地性(data locality)被分配，从而提高性能。

Ø  优雅降级(degrade gracefully)：当内存不足时，大分区会被溢出到磁盘，提供与其他现今的数据并行计算系统类似的性能。

2.4应用场景

RDD最适合那种在数据集上的所有元素都执行相同操作的批处理式应用。在这种情况下，RDD只需记录世族图谱中的每个转换就能还原丢失的数据分区，而无需记录大量的数据操作日志。所以RDD：创建RDD。上面的例子除去最后一个collect是个动作，不会创建RDD之外，前面四个转换都会创建出新的RDD。因此第一步就是创建好所有RDD(内部的五项信息)。

步骤2：创建执行计划。Spark会尽可能地管道化，并基于是否要重新组织数据来划分阶段(stage)，例如本例中的groupBy()转换就会将整个执行计划划分成两阶段执行。最终会产生一个DAG(directed acyclic graph，有向无环图)作为逻辑执行计划。

步骤3：调度任务。将各阶段划分成不同的任务(task)，每个任务都是数据和计算的合体。在进行下一阶段前，当前阶段的所有任务都要执行完成。因为下一阶段的第一个转换一定是重新组织数据的，所以必须等当前阶段所有结果数据都计算出来了才能继续。

假设本例中的hdfs://names下有四个文件块，那么HadoopRDD中partitions就会有四个分区对应这四个块数据，同时preferedLocations会指明这四个块的最佳位置。现在，就可以创建出四个任务，并调度到合适的集群结点上。

3.3混排

(待补充：关于混排(Shuffle)是如何执行的)

3.4宽窄依赖

在设计RDD的接口时，一个有意思的问题是如何表现RDD之间的依赖。在RDD中将依赖划分成了两种类型：窄依赖(narrow dependencies)和宽依赖(wide dependencies)。窄依赖是指内部实现

4.1调度器

Spark的调度器类似于Dryad的，但是增加了对持久化RDD分区是否在内存里的考虑。重温一下前面例子里介绍过的：调度器会根据RDD的族谱创建出分阶段的DAG；每个阶段都包含尽可能多的具有窄依赖的变换；具有宽依赖的混排操作是阶段的边界；调度器根据数据本地性分派任务到集群结点上。

4.2解释器集成

(待补充)

4.3内存管理

Spark支持三种内存管理方式：Java对象的内存存储，序列化数据的内存存储，磁盘存储。第一种能提供最快的性能，因为JVM能够直接访问每个RDD对象。第二种使用户在内存空间有限时，能选择一种比Java对象图更加高效的存储方式。第三种则对大到无法放进内存，但每次重新计算又很耗时的RDD非常有用。

同时，当有新的RDD分区被计算出来而内存空间又不足时，Spark使用LRU策略将老分区移除到磁盘上。

4.4检查点支持

尽管RDD的Lineage可以用来还原数据，但这通常会非常耗时。所以将某些RDD持久化到磁盘上会非常有用，例如前面提到过的，宽依赖的中间数据。对于Spark来说，对检查点的支持非常简单，因为RDD都是不可变的。所以完全可以在后台持久化RDD，而无需暂停整个系统。

5高级特性

(待补充：Broadcast…)

6参考资料

本文内容主要来源于：1）RDD论文《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》；2）Spark峰会ppt资料：《A-Deeper-Understanding-of-Spark-Internals》和《Introduction to Spark Internals》。感兴趣的可以自行查找。