Video在线视频

我们刚刚介绍了在Spark Streaming里面

它通过了一个什么样的办法

来进行流式数据的处理

实际上它的思路很简单

也是我们处理流式数据很容易想到的一个思路

我们就是说

怎么样把这个流

给切成一个一个不是流的这样一个数据

把它变成一个一个的小的batch

或者说大家爱叫做Mini batch的方式进行数据处理

那么通过这种方式

实际上它就可以

很容易的去借用以前在RDD里面

实现了各种各样的操作

来进行这样一个数据的流式处理

那么引入了一个叫做DStream的概念

通过一系列的RDD Mini RDD组合在一起

形成了一个逻辑上的一个流

那么我们来看

在Spark Streaming里面

它实现了什么样的功能

可以供这个数据处理和开发人员

进行真正的流式数据的处理

这张图实际上我们对比了

Spark Streaming里面的程序和Spark里面的程序

实际上我们发现

它们几乎没有什么样的差别

我们在Spark Streaming里面构建起一个叫做tweets

这样一个DStream

这个Stream实际上来自tweets

它会把twitter最近发的这样一个数据变成一个一个小的Mini batch

然后每个小的RDD形成了这样一个Stream

我们就可以在这个Stream上进行一系列的操作

实际上操作过程并没有我们刚刚说的那么复杂

我们那些Transform在实际的编码当中

可以把它直接应用到DStream上

我们发现

它可以在刚刚的Stream twitter上

进行flatMap

实际上它的意义

是将flatMap应用到DStream包含的所有的RDD里面

这些小的RDD

然后形成了新的Stream

叫做hashTags

那么这个flatMap

实际上是把里面的一些关键词

通过了一个叫做getTags

这样一个方法

把它里面的hashTag给拿了出来

我们不用去管这个函数具体怎么实现

大家现在需要知道它的功能就行了

然后这个hashTag就可以做进一步的操作

比如说 可以进一步的进行Transform

或者说现在我们把它保存在了磁盘

我们发现两段程序是非常非常相似的

也就是说大家在使用Spark Streaming

进行数据操作的时候

没有特别多的学习的成本

几乎可以把原来的Transform直接用过来

可能会有很小的语法上的调整而已

不像我们从MapReduce迁移到Storm的时候

整个思路要从Map和Reduce变成了

Spout和Bolt的关系上

我们下面给一些Spark官方教程里面

它给的一些例子来帮助大家理解Spark Streaming的情况

当然 大家可以进一步查找Spark Streaming最新的一些文档

来了解它最新的一些功能和feature

第一个例子

我们就是刚刚已经给到大家了

怎么样从Twitter的Stream里面拿到hashTag

第一步 我们创建了这样一个DStream

得到了现在发的所有的这样一个流

DStream可以直接通过

Spark Streaming里面已经提供的这些接口来取得

它的图示

就是这样一个样子

在不同的时间点

在你设定好时间窗口之后

不同的时间窗口

就会产生不同的小的RDD

有了这些小的RDD之后

它会用到Spark这种分布化的

对RDD的处理

之前我们介绍RDD的partition的时候

大家已经知道

这些数据会到系统中的服务器上进行分布式处理

那么进一步

我们去产生另外一个DStream

使用了原来的对应的这样一个Transform的方法

把它的hashTag给拿出来

拿出来之后呢

把它保存在新的DStream变量里面

这个过程实际上也是分布进行的

我们可以发现

在每个服务器上

它可能会对自己现在已经接收到了这个RDD

进行独立的处理

因为这之间并没有特别多的数据的依赖

那么可以达到一个比较好的分布化的一个效果

形成了新的RDD

那么形成新的RDD之后

我们可以对RDD进行进一步的处理

或者说 在我们目前的这个状态下

我们就想把它保存到磁盘

一样的 这个Spark Streaming会帮我们把数据

分布的存储到磁盘里去

然后完成了一个简单的第一个例子

那么第二个例子

假设我们还想进一步去操作

我们想把这些hashTag给统计出来

做一个计数

实际上我们在原来的Spark也说到过类似的计数

比如说我们可以进行Reduce by k

我们把相同的k进行Reduce

然后在Reduce里面对数据进行一个累加

可以完成这样的一个效果

那我们来看

在Streaming的背景下

怎么去做这件事情

刚刚我们说

已经有了这一系列的命令的RDD

我们来看

它的计数是怎么做的

我们使用了一个叫做CountByValue

实际上是把刚刚的DStream中那个RDD 

它的value

就是它的hashTags进行一个Counts

它本质上是一个Reduce的操作

那么同样的

这些数据

每个RDD被Partition之后

会在各个Partition对应的Server上得到执行

得到计数

计数完成之后

会形成一个新的DStream

这个DStream

实际上就对应了你要统计的value

和统计value的数值

这是我们做到的

对RDD进行类似于Reduce的操作

第三个例子 我们加入了时间窗口

但是我们并不关心

从我们开启程序到现在所有时间的Count

我们关心的仅仅是最近十分钟

大家发出的Twitter的情况

比如说最近十分钟

什么样的hashTags是最流行的

那么我们就会加入到这样一个时间窗口

我们来看这个怎么做的

我们通过window这个新的Function

在传统的RDD里面没有这个东西

在Streaming里面

我们有了这个window

实际上window就是限制了当前的计算

它在一个什么样的时间范围内去做

那么也就是说在最近多少的RDD上去做

window有一个size概念

我们看的时间窗口有多大

十分钟或者十秒钟

然后window往前移动的时候

它是怎么移动的

是不要相互覆盖呢

还是相互覆盖

那在这里面

我们给它移动的步长是一秒钟

也就是说它每次移动一秒

会有大量的和原来的窗口覆盖的空间

我们来看这个例子是什么样的

同样先构造出window的操作

图片上已经给出了我们在不同的Mini batch里面

我们拿到的RDD的数据

当我们加入的窗口

是给定大小的window之后

那么我们就会只看这个window里面

它所产生的数据的统计

同样在这个window里面

我们可以做Reduce

或者我们可以做其他Spark已经给我们提供的操作

在这里我们进行了一个window里面的count

count出hash的数量

当我们window再往前移动的时候

我们参考了在window这个函数里面

我们指定的interval 步长

那么它会往前移动1

那么我们看 

下一个数据就可以被统计出来

如果只是简单的做刚刚的那样的计算的话

我们会发现

当窗口和窗口之间还有大量的重叠的时候

实际上我们浪费了很多的时间去做重复的操作

比如说加法

我们会反复的加很多已经被加过的数据

在Spark里面实际上有一个feature

它解决了这个问题

叫做Smart window

我们来看所谓的Smart

到底是怎么做的呢

由于window这种操作

在大量这种流式数据处理里面

会经常被常用

所以Spark针对这个情况

做了一系列的优化

我们来看这个Smart window怎么做的

和刚刚的例子一样

当我们指定一个window

计算window里面hashTag的count的时候

我们会做一个数据的叠加

而当window往前移动的时候

这时候我们在Smart window控制底下

我们并不需要去计算所有的数据

做重新的Reduce

重新的相加

我们仅仅是需要根据你做的操作的属性

比如说是加法

我们可以把移出窗口的元素

从刚刚的计算结果中减掉

然后加上我们后面窗口会包含进来的新元素

它在Reduce的背景下

产生的一个值

然后做一个增量式结果的迭代

实际上这种操作

当然大家能够体会得到

它并不是一个通用的

可能某些操作

你并不能做到Smart window这种操作

但是针对我们在Spark Streaming里面

所要处理的大量的数据

它都具有这种增量性

我们实际上

可以大大的通过Smart window的方法

来降低计算的开销

那么在Spark Streaming里面

实际上它的这种数据的状态

以及这种失败的保证

实际上它是通过数据本身

RDD本身来做到的

这和我们在Storm里面讲的不太一样

Storm里面 

我们实际上把状态保存在节点上

它和我们运行这个Spout和Bolt的节点

是相关的

一旦这个节点失败

可能它的状态会丢失

那么这是在Storm这种由数据驱动

但是是由节点来保存状态信息

它的特性所决定的

在Spark Streaming里面

实际上这个问题得到了一定的克服

它的数据的状态实际上是保存在RDD里面

RDD和RDD

DStream和DStream之间

存在着一定的计算的关系

Transform的关系

而这种关系实际上刻画了它的状态

当一个DStream一旦生成之后

这个节点即使失效了

也不会影响状态的记录

因为我依然可以通过之前的计算过程

对数据进行恢复

有了这样一个特性之后

实际上在Spark Streaming里面

它就可以基于这样的特性

进行更加鲁棒

或者是更加高效的

一个系统的可扩展性的一个构建

那这是Spark Streaming的一个优势

我们希望同学们在真实的平台

不管是基于你自己的一个模拟的环境

或者是Cloud上的各种各样的Spark的平台上

大家能够去测试一下

把Spark原有的命令

原有的方法使用到Spark Streaming里面

然后来体会到Spark Streaming的一个优势

同时我们也鼓励大家对Spark Streaming和Storm

进行一个对比性的实验

大家来思考一下 

除了我们讲到的这些特性以外

它们俩还会有什么样的差别联系