Spark RDD理解

RDD设计是整个Spark中最为核心的设计理念，理解了RDD的设计之后自然而然就可以理解Spark为什么要这么设计，首先呢我们要先从Spark和Hadoop的渊源说起。

Spark&Hadoop

Hadoop在之前几年是非常火的，统领了大数据分析将近十年的浪潮，但是从2015年之后，整个Hadoop市场在逐渐萎缩，取而代之的是Spark市场逐渐扩张，同样是做批处理为何Spark要比Hadoop技高一筹呢？
Hadoop是一个非常成熟的生态系统，基于非常抽象的MapReduce来进行数据分析，用户呢不需要关心其他的实现，只需要写好Map函数和Reduce函数，Hadoop就可以帮我们进行数据分析，听起来非常令人振奋人心。既然是高度抽象，我们想，所有的数据分析模型我们都可以表达为这两个函数么？很显然这是不一定的，可见MapReduce模型在功能的丰富性的表达上是存在一定的缺陷的。同时呢，Hadoop的MapReduce模型将整个的数据分析流程抽象为Map过程和一个Reduce过程，在集群工作的时候势必会进行等待，因为只有集群内部所有节点的Map过程全部完成之后才可以启动Reduce过程。此外呢？Hadoop是一个基于硬盘的这样一个系统，在数据分析过程中需要频繁和磁盘进行交换，存在着巨大的IO瓶颈。
那么RDD正是注意到了Hadoop的这些缺点之后伴随着Spark一起诞生的。Hadoop的MapReduce过程表达能力差，我Spark表达能力强啊，提供了丰富的处理流程的接口，我们可以按照函数式编程的方式来进行编程。Hadoop在Map过程和Reduce过程之间进行等待，我Spark可以基于DAG（有向无环图）进行优化，大大的减少了等待的开销。Hadoop需要和磁盘进行频繁的数据交换，而Spark是基于内存的数据分析系统，不需要频繁进行数据交换。

RDD的由来

既然看到了Spark非常好，实现方案比Hadoop要技高一筹，那么Spark怎么实现呢？你要实现函数式编程，你要基于有向无环图进行优化，你要基于内存进行数据交换，怎么去做呢？
函数式编程大家都知道，就是类似于写函数的编程，像函数式的把变量的处理流程用函数表达出来。DAG有向无环图同时也是一种对数据分析流程的抽象，然后进行后续的优化。包括内存的存储加上上面提到的两个方面我们都无法回避的一个问题就是数据的抽象，只有有了数据的抽象来表达我们的数据（给这个数据起个名字）我们才能够把数据处理的流程表达出来，而RDD呢正是这样一种数据的抽象。
RDD全称resilient distributed datasets，它就是一种数据抽象，代表分布式集群各个节点的某些数据的集合。举一个很简单的例子：

val file = sc.textFile("hdfs:/test/ceshi.csv")

 我的hdfs下面有一个文件，我想把这个文件的数据读进来对这些数据进行操作，于是我们就可以创建一个RDD来抽象表示这个文件中的数据，我们根本不需要管这些数据是怎么组织的，只需要创建之后拿来用就可以了，这就是RDD，这就是数据的抽象表示。

RDD的DAG流程图

RDD全称的中文翻译为“弹性分布式数据集”。
上面也说到了，有了RDD之后我们可以抽象表示数据，这数据不管是分布式的还是单机的都可以统统拿来表示，可以一定程度上解释分布式的概念，那么弹性又该如何理解呢？ 我们先从Spark的DAG数据流程图说起：

比如我现在有很多个int的数据，我要有两个函数f(x)和g(x)，我要找到数据经过这两个变换之后的最大的三个值。那么按照这个操作，RDD1就是我的原始数据，操作1就是f(x)变换，操作2就是g(x)变换，操作三就是数据的合并操作，操作4就是找出最大的三个值的操作。那么DAG图呢实际上就是数据的操作的轨迹，它记录了数据的操作流程，就像现实生活中的工序图一样。那么为什么可以称之为弹性呢？

1. 容错率很高。我们有了数据的DAG流程图之后可以进行稳定的数据恢复。比如说我的RDD4被破坏了，那么我就可以根据DAG图使用RDD2和RDD3进行恢复，保障我的系统的正常运行。
2. Spark系统默认情况下在Task失败之后会进行重试。
3. 数据调度弹性。DAG的任务调度跟资源管理是分开的。
4. 内存和磁盘数据切换自动进行。