转自：https://blog.csdn.net/u011564172/article/details/53310530
概要
RDD是为了处理迭代算法和数据发掘应运而生的，keep数据在内存，显著提升性能。
RDD基于lineage实现容错，而不是shared state的update。
简介
背景
原有的并行框架MapReduce无法有效利用内存，并且不能重复利用迭代计算的中间结果，而是将中间结果存储在磁盘上，增加了数据备份（hdfs默认为3份）开销，磁盘IO，序列化的时间，迭代计算在数据挖掘和图算法中很常见，例如k-means，逻辑回归，PageRank。
挑战
RDD设计中的主要挑战是提供高效的“fault tolerance”编程接口，现有的对于内存存储的容错都是细粒度的对于可变状态的update，具体为跨机器的数据备份（replicate data cross machine）或者跨机器的日志更新（log updates cross machine），需要跨机器传输备份数据，效率低。不同的RDD提供基于粗粒度的transformations（例如map，filter等）构建的lineage（血统），如果一个RDD丢失数据，则可根据lineage找出丢失数据的来源，重新计算，达到容错，而不需要数据备份。
RDD（Resilient Distributed Datasets）
Spark数据存储的核心是弹性分布式数据集（RDD）。RDD可以被抽象地理解为一个大的数组（Array），但是这个数组是分布在集群上的。逻辑上RDD的每个分区叫一个partition。
在Spark的执行过程中，RDD经历一个个的Transformation算子之后，最后通过Action算子进程触发操作。逻辑上每经历一次变换，就会将RDD装换为一个新的RDD，RDD之间通过Lineage产生关系，这个关系在容错中有很重要的作用。变换的输入和输出都是RDD。RDD会被划分成很多的分区分布到集群的多个节点中。分区是个逻辑概念，变换前后的新旧分区在物理上可能是同一块内存存储。这是很重要的优化，以防止函数式数据不变性（immutable）导致的内存需求无限扩张。有些RDD是计算的中间结果，其分区并不一定有相应的内存或磁盘数据与之对应，如果要迭代使用数据，可以调用cache()函数缓存数据。
在物理上，RDD对象实质上是一个元数据结构，存储着Block、Node等的映射关系，以及其他的元数据信息。以及其他的元数据信息。一个RDD就是一组分区，在物理数据存储上，RDD的每个分区对应的就是一个Block，Block可以存储在内存，当内存不够时可以存储到磁盘上。
RDD抽象
只读的，分区的数据集（a collection of Java or Python object across a cluster.），通过其他RDD或者数据源（data in stable storage）创建。RDD通过lineage保留自身创建信息，RDD只有在执行action之后才会触发真正的计算。
spark编程接口
spark的实现中，使用对象存储数据，transformation是操作这些对象的方法，RDD可以通过外部数据源或者parallelize操作数组的方式初始化，执行transformation获得新RDD，最后是action操作（例如count，collect，save），spark中RDD的计算是lazy的，此外程序可以使用persist和cache（cache是调用persist（StorageLevel.MEMORY_ONLY））缓存数据达到重复利用。
RDD和shared state对比
因为RDD是只读的（不可变的）和使用了lineage，一致性和容错都得到了保障，对于stragglers（是指long-running tasks，slow nodes）的策略和MapReduce相似，使用了备份任务，同时执行的方式，此外，跟性能相关性大的一点是计算跟着数据走。
RDD模型优势
1.容错方式：RDD只能通过粗粒度的transformation操作，这确保RDD可以bulk write，不需要通过checkpoing就能实现数据容错，此外，只有丢失数据的partition需要重算，根据lineage。
2.任务备份：通过对运行慢的任务进行备份，提高任务的执行速度。
3.就近执行：计算跟着数据走，提高执行效率。
4.不只是内存：内存不足，数据可以存储在硬盘，并通过压缩的方式获得和内存处理相近的性能。
RDD不是万能的
RDD适合批处理，不适合细粒度的对于shared state的update，如web程序的DB，持续增长的web爬虫数据存储等。
Spark编程接口
RDD相关操作
spark采用scala语言实现，简介，效率不错
RDD组成
组成
RDD分类
窄依赖：父RDD只被一个子RDD引用
宽依赖：父RDD被不止一个子RDD引用
为什么要区分窄依赖和宽依赖
1.窄依赖可以流水线（pipeline）执行，执行效率高，宽依赖需要等所有父RDD执行完再执行下一步计算。
2.窄依赖的恢复更容易且快速，因为只有一个父RDD的partition需要重新计算。
部分RDD的实现
1.hadoopRDD：一个block对应一个partition，preferredLocations方法返回block，然后iterator reads the block。
2.mapRDD：map方法返回mapRDD，保持和父RDD相同的partition和preferredLocations，只是将map方法应用于父RDD的每一条记录。
3.unionRDD：union方法返回，每一个child RDD的partition通过窄依赖计算得来。
4.sampleRDD：和map类似，多了一个随机数生成器，用来获取样本RDD中记录。
5.joinRDD：可能导致两个宽依赖，两个窄依赖，或者各有一个，result RDD拥有的partition schema，可以是默认的hash partitioner，或者从父RDD继承的。
任务调度
stage划分
当调用action方法时，spark根据lineage构建DAG生成task。如上图所示，以RDD的partition为最小粒度，划分stage时，从一个RDD开始，尽可能多的包含流水线操作（窄依赖），将其划分为一个stage（如上图stage2），每个stage的边界是shuffle操作（宽依赖）。
对于宽依赖，会保存中间结果便于遇到错误后数据恢复，和MapReduce的map端类似。
任务调度
stage划分完毕后，根据stage生成一系列task，使用delay scheduling算法，根据计算跟着数据走的原则分发task到各节点执行，计算后的结果返回给driver节点的action操作。
内存管理
spark提供三种RDD持久化方案:
1.内存存储序列化的Java对象
2.内存存储其他格式的序列化数据
3.磁盘存储
第一种性能最好，第二种选择合适的序列化和压缩工具能有效利用内存，第三种适合特别大的数据量。为了更有效的使用内存，使用LRU算法，然后，内存不足时，清除的却是最近被使用的RDD的partition，保存old partition在内存，目的是为了防止partition频繁的in and out。因为我们通常操作整个RDD，那么早已在内存中的partition将来被用到的可能性大。目前spark集群的每个实例单独管理自己的memory，未来调研统一内存管理的可行性（unified memory manager）。
支持保存点（checkpoint）
虽然RDD可以通过lineage实现fault recovery，但是这个回复可能是很耗时的，因为提供保存点很有必要，通常保存点在有宽依赖时（shuffle耗时）很有用，相反，窄依赖时则不值得使用。spark提供了API，但何时使用由用户决定，也在调研自动保存点的可行性，RDD的只读属性也使其实现保存点功能比传统的shared state更容易。
总结
RDD是高效的，通用的，容错的，更是spark的基石。
来源：oschina
链接：https://my.oschina.net/u/4400196/blog/3283357