spark RDD

RDD是Spark中对数据和计算的抽象，是Spark中最核心的概念，它表示已被分片（partition），不可变的并能够被并行操作的数据集合。

对RDD的操作分为两种transformation和action。Transformation操作是通过转换从一个或多个RDD生成新的RDD。Action操作是从RDD生成最后的计算结果。

在Spark中，提供丰富的transformation和action操作，比起MapReduce计算模型中仅有的两种操作，会大大简化程序开发的难度。

RDD的生成方式只有两种，一是从数据源读入，另一种就是从其它RDD通过transformation操作转换。一个典型的Spark程序就是通过Spark上下文环境（SparkContext）生成一个或多个RDD，在这些RDD上通过一系列的transformation操作生成最终的RDD，最后通过调用最终RDD的action方法输出结果。

每个RDD都可以用下面5个特性来表示，其中后两个为可选的：

分片列表（数据块列表）

计算每个分片的函数

对父RDD的依赖列表

对key-value类型的RDD的分片器（Partitioner）（可选）

每个数据分片的预定义地址列表（如HDFS上的数据块的地址）（可选）

虽然Spark是基于内存的计算，但RDD不光可以存储在内存中，根据useDisk、useMemory、useOffHeap, deserialized、replication五个参数的组合Spark提供了12种存储级别，

在后面介绍RDD的容错机制时，我们会进一步理解。值得注意的是当StorageLevel设置成OFF_HEAP时，RDD实际被保存到Tachyon中。Tachyon是一个基于内存的分布式文件系统，目前正在快速发展

DAG、Stage与任务的生成

Spark的计算发生在RDD的action操作，而对action之前的所有transformation，Spark只是记录下RDD生成的轨迹，而不会触发真正的计算。

Spark内核会在需要计算发生的时刻绘制一张关于计算路径的有向无环图，也就是DAG。举个例子，下图中，

                                                         A-->B

                                                        /   \

                                           input-->   E--> F -->output

                                                        \    /

                                                         C-->D

从输入中逻辑上生成A和C两个RDD，经过一系列transformation操作，逻辑上生成了F，注意，我们说的是逻辑上，因为这时候计算没有发生， Spark内核做的事情只是记录了RDD的生成和依赖关系。当F要进行输出时，也就是F进行了action操作，Spark会根据RDD的依赖生成DAG，并从起点开始真正的计算。

有了计算的DAG图，Spark内核下一步的任务就是根据DAG图将计算划分成任务集 ，也就是Stage，这样可以将任务提交到计算节点进行真正的计算。Spark计算的中间结果默认是保存在内存中的，Spark在划分Stage（阶段）的时候会充分考虑在分布式计算中可流水线计算（pipeline）的部分来提高计算的效率，而在这个过程中，主要的根据就是RDD的依赖类型。根据不同的transformation操作，RDD的依赖可以分为窄依赖（Narrow Dependency）和宽依赖（Wide Dependency，在代码中为ShuffleDependency）两种类型。窄依赖指的是生成的RDD中每个partition只依赖于父RDD(s) 固定的partition。宽依赖指的是生成的RDD的每一个partition都依赖于父 RDD(s) 所有partition。

窄依赖典型的操作有map, filter, union等，宽依赖典型的操作有groupByKey, sortByKey等。可以看到，宽依赖往往意味着shuffle操作，这也是Spark划分stage的主要边界。

对于窄依赖，Spark会将其尽量划分在同一个stage中，因为它们可以进行流水线计算。

Spark在运行时会把Stage包装成任务提交，有父Stage的Spark会先提交父Stage。

SparkContext拥有DAGScheduler的实例，在runJob方法中会进一步调用DAGScheduler的runJob方法。

在此时，DAGScheduler会生成DAG和Stage，将Stage提交给TaskScheduler。TaskSchduler将Stage包装成TaskSet，发送到Worker节点进行真正的计算，同时还要监测任务状态，重试失败和长时间无返回的任务。

整个过程如下图所示。

                         创建RDD,经过一系列transformations，最后actions

                                                 V

                      action触发SparkContext的runJob方法，交给DAGScheduler

                                                 V

                                  DAGScheduler将DAG生成Stage

                                                 V

                               将Stage提交给TaskScheduler

                                                 V

                 TaskSchduler将Stage包装成TaskSet，发送到Worker节点进行真正的计算，

                       同时还要监测任务状态，重试失败和长时间无返回的任务

上文提到，Spark的计算是从action开始触发的，如果在action操作之前逻辑上很多transformation操作，一旦中间发生计算失败，Spark会重新提交任务，这在很多场景中代价过大。

还有一些场景，如有些迭代算法，计算的中间结果会被重复使用，重复计算同样增加计算时间和造成资源浪费。因此，在提高计算效率和更好支持容错，Spark提供了基于RDDcache机制和checkpoint机制。

我们可以通过RDD的toDebugString来查看其递归的依赖信息，也就是它的Lineage.

如果发现Lineage过长或者里面有被多次重复使用的RDD，我们就可以考虑使用cache机制或checkpoint机制了。

我们可以通过在程序中直接调用RDD的cache方法将其保存在内存中，这样这个RDD就可以被多个任务共享，避免重复计算。

另外，RDD还提供了更为灵活的persist方法，可以指定存储级别。从源码中可以看到RDD.cache就是简单的调用了RDD.persist(StorageLevel.MEMORY_ONLY)。

同样，我们可以调用RDD的checkpoint方法将其保存到磁盘。我们需要在SparkContext中设置checkpoint的目录，否则调用会抛出异常。

值得注意的是，在调用checkpoint之前建议先调用cache方法将RDD放入内存，否则将RDD保存到文件的时候需要重新计算。

Cache机制和checkpoint机制的差别在于cache将RDD保存到内存，并保留Lineage，如果缓存失效RDD还可以通过Lineage重建。而checkpoint将RDD落地到磁盘并切断Lineage，由文件系统保证其重建。

Spark的集群部署分为Standalone、Mesos和Yarn三种模式，

我们以Standalone模式为例，简单介绍Spark程序的部署。

集群中的Spark程序运行时分为3种角色，driver, master和worker（slave）。

在集群启动前，首先要配置master和worker节点。启动集群后，worker节点会向master节点注册自己，master节点会维护worker节点的心跳。

Spark程序都需要先创建Spark上下文环境，也就是SparkContext。创建SparkContext的进程就成为了driver角色，上一节提到的DAGScheduler和TaskScheduler都在driver中运行。

Spark程序在提交时要指定master的地址，这样可以在程序启动时向master申请worker的计算资源。