Video在线视频

我们刚刚讲到在spark里面

实际上它提出了一个概念叫做RDD

这种可伸缩的分布式数据集

那么利用这种数据集它可以在上面

搭建transform这种操作

可以实现action

最终让RDD出现在屏幕

或者是出现在分布式文件系统中

那么RDD被transform和action

连接起来实际上

可以完成一系列的动作

这些动作覆盖了我们在

map-reduce中介绍的map

和reduce两个过程

那么RDD实际上是作为

spark的一个核心

被spark的底层

进行资源管理资源分配

以及对它进行任务的调度

以及工作节点的

这样一个任务的执行

那么我们接下来

就会仔细来看一下RDD

它的一些存储特征以及

它的一些关联特征以及RDD

在整个spark当中

它是怎么样得到有效的

处理上的优化的

首先我们来看RDD的一个存储

在RDD的这个存储里面

有两个方面

一个就是RDD

它到底是怎么样表示的

那么我们之前说RDD

怎么样可以生成呢

它可以通过分布式文件系统

直接从分布式文件系统里面得到读入

形成一个从磁盘到RDD的

这样一个过程

同时RDD在表示的过程当中

它还有自己的这样一个

partition的概念

比如说RDD实际上它也是在

分布的一个环境下得到处理的

所以partition

是它核心的一个概念

那么RDD还有依赖性对吧

RDD可以通过我们刚刚说到

这种变幻

这种transform从某一个RDD

或者某几个RDD变幻而来

所以RDD他核心的一个概念是

它的这种依赖性

这和map-reduce里面对数据的

定义是不太一样的

map-reduce

里面每一个文件是相对独立的

我们可以说某一个文件可能是

由之前某一个文件生成的

但这个文件的依赖关系

是一个非常弱的关系

因为经过一段时间之后

这个文件可能会被其他的进程

或者是用户做一些修改

那么这种依赖关系就被打破了

所以它并不是一个强的依赖关系

而在RDD里面

由于它本身不能变化

我们之前已经说到

所以这种依赖关系是在整个系统

的周期里面是存在的

所以它有这种依赖的关系

那么RDD的存储也有几种模态

第一它可以在磁盘上

我们刚刚说

在action里面有一个功能

叫做save到文件

所以我们可以将RDD

直接存到文件当中

形成一个文件化的这个RDD

那么它可以在内存当中

我们说spark

引入了一个概念

就是要在内存中搭建

这样一个数据处理的一个框架

所以在内存中

进行RDD的一个cache

是它的一个存储的模式

然后它可以进行replication

它可以在分布的系统中

有多份的存在

这是RDD的一个核心的概念

我们来看RDD的这个持久性

是怎么样做得到的

在spark里面

实际上每个RDD它在进行

action的时候

它都会进行一个生成

除非你指定的这个RDD

已经被cache

或者说已经是系统中存在的一个RDD

否则当action执行的时候

每个RDD会被生成

RDD在生成的时候

它会通过我们刚刚说到的

这样一个依赖关系

去查找它到底需要什么样前序的RDD

它才能被生成出来

形成这样一个运行的一个过程

所以当RDD一旦计算出来之后

它实际上就会以

这样一个不变的形式

在磁盘或者是在内存中持久下来

同时RDD的这种模式

实际上也是可以发生变化的

当我们从磁盘得到一个RDD

或者计算出一个RDD之后

我们是可以通过显示的

这样一个操作

告诉它是不是应该进入到内存

或者是磁盘的这样一个

catch的一个状态

那么这样的一个好处

就是我们可以有效的

根据我们当前处理的

这样一个任务

是迭代化的操作

还是交互性的操作

来决定我们在系统中

不同的数据集RDD

它的一个存在的一个模态

我们甚至还需要

考虑这些RDD的大小

我们要在大小

我们存储的这个开销

以及我们后面计算的

这样一个性能上

取得一个平衡

提供了给程序员

或者是数据工程师

一个比较灵活的

一个控制的这样一个层面

那么刚刚说RDD

它的一个核心的概念

是它的这种依赖关系

那我们就通过这张图

给大家一个例子

让大家来看看这个依赖关系

到底是怎么存在的

在图的左面

我们可以看到数据

被从分布式文件系统

SDFS里面读取出来

进入到spark的环境

那么图的右边

它们经过一系列操作之后

通过一个action叫做

saveAsSequenceFile

存到这个HDFS里面去了

在中间就是RDD的

一系列的变化

我们可以看当文件

被读取出来之后

实际上它可以形成一个原生的

这样一个RDD

经过一系列的transform

包含了这里面的map

map实际上在map-reduce里面

是对每一行进行单独的

这样一个处理

在RDD里面也有类似的

这样一个变换

它就是对数据集中的每一行

进行某一种处理

然后进行了一个reduceByKey

那么这里大家要注意

在reduce里面

好像reduce执行的

一些写入到磁盘的操作

但是在这个spark

里面有reduceByKey

依然是一个transformation

是一个形变的过程

当它不需要执行

action的时候

它依然不会在系统中

发生真正的操作

那么它的概念和

map-reduce中的reduce是类似的

也是将具有相同的Key的这个数据

进行一定的这个整合的操作

那么经过这样一系列的操作之后

在这个系统中

我们现在有

A B C D E F

4个RDD

那么这些RDD实际上

在这个依赖关系上

它们是有很明确的

哪个RDD是由哪些RDD生成的

或者是直接从分布式

文件系统里面读取出来的

所以有了这样一个依赖关系之后

在spark系统中

就引入了

lineage这样一个概念

那么我们可以看得到

这是和map-reduce中有区别的

那么当然map-reduce

在经过一系列迭代的

这样一个操作之后

其实它的jobs

也形成了类似的这样一个关系

那么spark把

这样的一个关系给显示化

把它给直接拿出来做了设计

那么有了这样的一个血缘的关系

这样一个lineage的关系之后

它有什么好处呢

它可以做容错

那么我们知道

在整个spark系统中

它依然没有改变我们的假设

也就是说

任何系统任何模块都可能会失败

那么失败之后怎么样恢复呢

在map-reduce里面

对数据的恢复

实际上是相对比较简单的

因为它的数据都已经

存储在分布式文件系统里面

当某一个replication去掉之后

实际上它依然可以

通过另外的两个

或者是多个replication

来得到恢复

那么在这个spark里面

由于这种依赖关系的存在

那么实际上它可以通过

这个依赖关系进行数据的恢复

在这里的这个例子里面

我们发现一个RDD

从它从text文件里面

读出来之后

它经过了一系列的变化

它经过了一个filter

filter是将RDD中包含

某一些关键词的

这个数据给提取出来

然后经过了map

对这一行进行了一个平行的

一个操作

然后还做了一个cache

让它cache到内存当中

假设其中的filter

或者map中生成的这个RDD

出现了异常或者丢失之后

实际上我们是可以根据整个系统

记录的这样一个依赖关系

对局部进行一个恢复

那么这是spark它对错误处理

一个天然的一个优势

那么这种优势实际上大家在后面

实际的这种使用当中可以去体会

但我们需要对其中某一些RDD

进行特别的处理的时候

实际上你会发现

你的RDD的复用

你的RDD的这种

重新的这种关系的构建

是可以很大程度上降低

你的这个劳动量

那么刚刚是RDD的一些存储

表示以及它的这种依赖关系的

一些特征

那么下面我们来看

RDD它的一些内部的接口

到底是什么东西

然后使得它能够很好的

支持我们刚刚的一些特征

首先RDD

具有partition的概念

那么RDD本身它是

可以在系统中的多个server上

去进行存储的

所以它天然具有partition的概念

那么partition之后

它使得RDD在这个分布的

环境下具有这种容错

具有这个可以

得到并行处理的这样一个能力

同时对于RDD它也有这个

localization的一个需求

那么我们有代码有数据

那么在这个RDD进行真正的

action或者是

transformation的操作的时候

实际上对于RDD它的位置是有感知的

不是我们会有一些partition

这种策略的一个选择

比如说当我们的数据在处理的

过程中具有一定的

并行的这种要求的时候

实际上我们是需要去

设计它的这个partition的策略

使得它能够和

我们的数据处理的算法

进行一个匹配

它有存储的策略

比如说它的这个lazy

和cache这种策略

当我们没有执行到存储到硬盘的

这样操作的时候

实际上RDD它一直在系统中

是以一个逻辑的关系存在

只有当我们要求它做了某一些

存储的动作的时候

整个过程才会依赖着关系

以这种后推的

这样一个方式来进行

同时在整个系统当中

会以形成这样一个lineage

这样一个图的这样一个关系

使得当发生错误

当发生一些数据丢失的情况下

我们依然可以通过一个无环图的

这样一个回溯

去找着

最终生成

缺失RDD或者是失败RDD

它的这样一个过程

那么我们来分析一下

在spark里面

使用了这样的一个数据模型和

编程模型

它的一些好处是什么

首先每个RDD是不允许变的

所以数据具有高度的这种一致性

一个RDD被用户生成出来之后

用户只需要通过这个名字

就一定能访问当前生成的

这个数据

不管系统经历了

其它的什么样的变化

那这个数据

用户可以认为是不会发生变化的

那它具有这个一致性

那么对于这种失败的处理

我们刚刚已经反复强调

依赖于它的这种依赖关系

实际上具有相对比较高效的

可恢复性

同时

它可以很好地去

处理这种数据的一个

和计算的一个位置的一个分配

因为RDD本身支持了partition

那么我们的代码

就能够在各个节点上得到执行

所以在spark里面

可以很好的对这种数据的局部性

进行一个处理

达到提高计算性能的一个目标

同时在RDD里面

实际上由于它具有迭代

具有交互的这种特性

那么RDD具有transform

和action的这种分离

实际上它可以支持

更加复杂的这样

一个数据处理的任务

在我们后面也会给到一些例子

让大家去体会

那么在RDD里面

实际上我们可以很好的对

map-reduce进行支持以外

还能够支持更加复杂

看起来更加实际的一些任务

它的这个fault tolerance

它的这个失败的恢复

我们刚刚已经说过

它可以依赖于它的依赖关系

进行一个错误的恢复

同时在spark里面

它也做了很多的这种数据更新的

一个记录

以transformation

作为它的这样一个更新的操作

实际transformation

会被spark的中心节点记录

那么这些信息会被持久化到整个

系统当中

所以整个系统实际上负责记录了

用户进行了哪些操作

那么这些操作在数据上

是可以得到回放的

那回放的过程就是

对错误恢复的一个过程

然后laziness

我们之前也简单的提了一下

spark实际上它的transform

并不会导致节点做

任何实际的动作

那么这个动作只是被中心节点

进行了记录

那么它的这种laziness的好处就是

帮用户在探索这个数据的过程中

没有必要去消耗很多的计算资源

对用户的每一步操作

进行一个响应

而实际上只有当用户

需要在屏幕上输出

或者是需要在磁盘中输出的时候

这些数据才会得到一个呈现

那么这种laziness

实际上延缓了资源

被真正消耗的这样一个过程

也给了用户这种交互的行为

一个比较好的操作大家在使用

sparkshell的时候

就会感觉到当你不断的

运行一系列操作的时候

实际上你的整个思路不会被打断

也可以不断的去进行迭代

那么最后

当你要看一些最终结果的时候

它才会有一个最终的一个反馈

那么这是满足

今天大家交互的使用spark的

这样一个需求的一个方案