Video在线视频

今天我们讲流式数据的处理

我们说了 流式数据

它作为今天各种应用所需要的一种新的处理方式

然后有它自己的一些特征

比如说秒级的这样一个反馈

比如说对数据能够在一个时间窗口里面

进行一次的查看

那么我们接着介绍了Hadoop生态环境下的Storm

通过Tuple来在Spout和 Bolt之间

进行一个数据的驱动方式的这样一个运行

同时进行数据流的并行化

实际上它的模式

是通过每一次产生新的Tuple

然后由Storm去驱动这些Tuple 

在Bolt里面得到执行

并且产生数据的下一步的数据流

那么我们在编写一个Bolt的过程中

我们已经体会到

实际上在使用Bolt的时候

我们会被系统调起

通过executor调起

然后我们会产生新的下一个这个数据的Tuple

然后来通知下一个Bolt运行

实际上给人的感觉

它是一个被事件

被Action驱动的这样一个模式进行运行

那么我们接下来会介绍

另外一个这个流式数据处理的一个框架

叫做 Spark Streaming

然后来介绍它在处理流式数据的时候

使用的这个不同的一个思路

那么在Spark Streaming里面

实际上它借用了之前

在Spark里面的若干的概念

那么我们回顾一下

在Spark里面

数据被变成了一个一个的RDD

然后RDD和RDD之间存在着这种转换的关系

然后可以通过RDD在内存或者是在磁盘

得到一系列的存储和权限这样一个方式

那么在Spark Streaming 里面

实际上也借用了这样一个方式

然后它在处理流式数据的时候

实际上使用了一个转化处理的

这样一个办法

我们有一个数据流

如果我们有办法将数据流

变成一个一个的

能够进行小规模批量处理的数据形态的话

实际上我们就可以完全利用原来的

这种RDD的这样一个模式

那Spark Streaming就是基于这样的一个思路

让我们来看怎么做的

我们有了一个数据流

我们希望做Spark Streaming的时候

我们会做一些什么样的事情呢

我们不直接去处理这个实体流

或者是数据流中每一个很小的Tuple单元

相反我们是把它变成了

一个一个有一定程度的

从时间上进行切片的数据块

它用了一个词 叫做chop

我们把这个数据流

把它切成了很多的这个数据片

那每一个数据片呢

实际上它的长度是可变的

比如说我们可以把它切成

按照每秒或者按照每分

或者按照每几秒

把它切成一段一段的

那么这个每一段

就变成了一个传统的RDD

能够在Spark中得到处理

实际上根据不同应用的需求

我们完全可以控制切的数据块有多大

然后达到对延迟的一个控制

有了这样一个数据的

进行一个小的batch的处理之后

实际上原来在Spark里面提供到的

这种Transform或者Action就都可以得到执行了

这是在Spark Streaming里面所做的事情

那么在Spark Streaming最开始的这种实现当中

实际上他们已经可以做到秒级的一个数据延迟

同时呢 他们可以对这种很小的mini batch

进行传统的RDD的操作

我们来看在Spark Streaming里面

它是怎么去实现我们在Storm实现的这种容错性

在Storm里面

因为依赖了和Hadoop类似的这种

从中心到边缘

或者是从Nimbus到executor的管理

得到Supervisor这样一个管理

那么我们来看

它在Spark Streaming里面

我们怎么样做到类似的Topology

实际上这部分的思路是比较简单的

因为在Spark里面

RDD本身是可以容错的

我们之前介绍过

RDD因为我们在整个系统中

保存了RDD在执行的时候

它的一系列操作的过程

它经过了什么样的Transform

然后最终如果某一个RDD缺失的话

我们可以通过Transform的log来达到一个恢复

在Spark Streaming里面

类似的思想也得到了一个使用

利用RDD它的一个特性

实际上我们在Spark Streaming里面

也记录了它的一个执行的流程

那有了这样一个执行流程之后呢

实际上我们就可以通过某一个节点失败的时候

通过执行流程的一个重放

来达到对它恢复的一个目的

这边我们可以看到

数据经过一系列的Transform

从RDD的一个状态

变成另外一个新的RDD

然后新的RDD可以通过转换的过程

达到一个恢复

那么在Spark Streaming里面

尽管它是基于RDD

但是由于它的数据对象本身是一个Stream

它引入了一些新的概念

第一个概念叫做DStream

DStream是什么

DStream是一系列时间序列产生的RDD的序列

但这个序列可能是没有头也没有尾的

它是一系列的Mini的这种数据的batch

Mini的RDD

那么这个数据流怎么来

它可能会来自于我们刚刚说到的

这种社交媒体它产生的数据流

它可能是从其他的这种数据源生成的

比如说HDFS Kafka里面

可以读出这样一个流式的数据

Transform在Spark Streaming里面

依然是实用的

它表示了从某一个Stream

转换到另外一种Stream它的一个过程

它实际上继承了原来的RDD上Transform的一个概念

只不过现在我们可以从这个组成这个RDD

由这个RDD组成的Stream

转换到另外一个新的形态的RDD

就形成了另外一个Stream

实际上它的本质是在RDD上进行的

然后我们有各种各样的输出的方式

那么在传统的Spark里面

实际上我们的输出

通常是写到屏幕

或者是我们存到分布式文件系统里面

那么在Spark Streaming里面

我们依然可以把它的一些结果输出到硬盘上

但是我们还有一些其他办法

我们可以让它产生新的一个数据流

我们可以让后面的处理Stream的Spark Streaming的任务

可以进一步去做一些处理

然后我们可以让Spark Streaming也形成类似于

Storm Topology那样复杂的结构

在整个系统中

==

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

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

来进行流式数据的处理

实际上它的思路很简单

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

我们就是说

怎么样把这个流

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

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

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

那么通过这种方式

实际上它就可以

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

实现了各种各样的操作

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

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

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

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

那么我们来看

在Spark Streaming里面

实现了什么样的功能

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

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

这张图实际上我们对比了

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

实际上我们发现

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

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

这样一个DStream

这个Stream实际上来自twitter

它会把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

进行一个对比性的实验

大家来思考一下 

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

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