RDD阅读笔记

其他名词

HDFS

RDD

弹性分布式数据集

容错支持：

RDD只支持粗粒度变换，即，输入数据集是 immutable （或者说只读）的，每次运算会产生新的输出。不支持对一个数据集中细粒度的更新操作。这种约束，大大简化了容错支持，并且能满足很大一类的计算需求。

对数据集的一致性抽象正是计算流水线（pipeline）得以存在和优化的精髓所在。在定义了数据集的基本属性（不可变，分区，依赖关系，存放位置等）后，就可以在此基础上施加各种高阶算子，以构建 DAG 执行引擎，并做适当优化。从这个角度来说，RDD 实在是一种精妙设计。

例行总结一下 RDD 论文的主要设计点有：

1. 显式抽象。将运算中的数据集进行显式抽象，定义了其接口和属性。由于数据集抽象的统一，从而可以将不同的计算过程组合起来进行统一的 DAG 调度。
2. 基于内存。相较于 MapReduce 中间结果必须落盘，RDD 通过将结果保存在内存中，从而大大降低了单个算子计算延迟以及不同算子之间的加载延迟。
3. 宽窄依赖。在进行 DAG 调度时，定义了宽窄依赖的概念，并以此进行阶段划分，优化调度计算。
4. 谱系容错。主要依赖谱系图计算来进行错误恢复，而非进行冗余备份，因为内存实在是有限，只能以计算换存储了。
5. 交互查询。修改了 Scala 的解释器，使得可以交互式的查询基于多机内存的大型数据集。进而支持类 SQL 等高阶查询语言。

RDD不存储真正要计算的数据！

RDD转换都是惰性的，只有action时才会运行

MR对数据是没有抽象的，Spark对数据进行了抽象，也就是RDD

RDD弹性

1.自动进行内存和磁盘数据的交换

2.基于lineage的高校容错机制

3.可通过checkpoint和persist持久化数据

RDD五大特性

前三个RDD都具备，后两个可选

1 A list of partitions

对于RDD来说，每个分片都会被一个计算任务处理，分片数决定并行度；

用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值

2

入门必读 | Spark 论文导读 - 知乎 (zhihu.com)

为什么需要RDD？RDD解决了什么问题

没有RDD之前：

那个时候的计算框架，比如MapReduce，虽然对利用集群中的计算资源做了各类抽象，但还没有实现对集群内存的抽象封装。存在着许多局限性。

MapReduce局限：

抽象层次低，需要写很多底层的代码，不够高效

MapReduce 编程模型的表达能力有限，所有的事情必须要转化成 Map 和 Reduce 两个操作，而仅靠 MapReduce 难以满足所有需求

时延高，只适用批数据处理，对于交互式数据处理和实时数据处理的支持不够

任务的执行需要多次读写分布式文件系统，无法利用分布式内存资源，难以满足复用中间结果的计算需要，对于迭代式数据处理性能比较差，包括：

• 迭代式机器学习算法及图算法
• 交互式数据挖掘

可见MapReduce对那些需要重复利用中间结果集的应用不太友好。

在RDD发明之前，很多特殊的计算需求只能靠不断引入新的计算框架才能解决。而RDD发明之后，对于这类在多个数据集上重复一组运算的操作，变得简单和通用了。

RDD是什么

R：Resilient

有弹性的；能复原的

有弹性说明这个东西不容易被损坏，比如说轮胎、皮球。

大规模集群里，任何一台服务器都有可能随时出现故障。而spark处理的任务，可能时常要运行分钟级甚至小时级别，那么整个任务完全重跑的代价非常大，而某些task重跑的代价就比较小了，所以spark的数据结构一定要有"弹性"，能自动容错，保证任务只跑一遍。

没有弹性的系统：例如presto或者impala，因为在其上运行的查询，都是秒级的时延，所以如果子任务失败，直接把查询重跑一遍即可

D：Distributed

分布式

根据一些特定的规则切分后的数据子集，就可以在独立的task中进行处理，而这些task又是分散在集群多个服务器上并行的同时的执行

D：Datasets

数据集

注意！实际上RDD并非真正的“集合”，而是一个抽象的数据模型，不必担心底层数据的分布式特性。

RDD特征

只读

只读的属性注定了RDD的产生方式只有新建，要么从其他数据源读取而来，要么从已有的RDD修剪出来。

RDD优缺点

RDD的表现方式

窄依赖和宽依赖

RDD性能评估