Video在线视频

下面我们来介绍一下

Storm的Architecture

我们看看到底它

在这个服务器网络和存储的这样一个层面

它会通过什么样的办法

把这些计算机的模块组织到一起

实现这样一个流式数据的处理

当我们从大的这样一个框架来看

实际上Storm

它也是被组织成了一个中心化的结构

在它的结构中

有一个叫做Nimbus的节点

或者是多个这样的节点

来负责整个系统和整个集群的这样一个维护

在Nimbus底下 

会有一系列的ZooKeeper的节点

它们负责来协调整个系统中的名字空间

以及系统中的一些关键资源的保护

基于ZooKeeper的资源分配和资源的保护

在Storm里面会通过一系列的Supervisor

来进行实际的每一个Topology的任务的管理

和任务的调度

以及中间数据流的分配

那么我们学习这些概念

最简单的方式就是

对它进行一个对照

我们把刚刚这几个概念

和Hadoop生态底下其他的系统进行一个对比

那么在这里面

我们就和MapReduce中

它的一些概念进行一个对照

我们从上往下

在MapReduce中

我们有JobTracker去管理一个MapReduce的Job

那么在Storm中

我们通过Nimbus进行一个任务的管理

他们管理了系统中不同用户 

不同的服务提交的任务

它们负责任务完成和资源的一个监控

然后它们还负责对失败的Job进行一个重启

或者说重新的调度

那么在JobTracker Nimbus底下

MapReduce里面就有了TaskTracker

分别去管理Map和Reduce的任务

那么在Storm里面

就有了这些Supervisor

它们去管理Topology里面

这些Spout和Bolt具体的模块

那么在这里面

他们的任务呢

就是去负责每个单元能够运行完成

比如说TaskTracker

会负责它自己负责的Map或者Reduce的任务

能够有效地完成

如果不完成

汇报给JobTracker

那么Supervisor会监控自己的Bolt

有没有持续的处理数据的流入

然后又对于没有把任务完成好的这些任务

能够有效地重新分配

它运行的资源

那么再往下

我们来看它们里面的Job和Topology的一个对应

在MapReduce里面

我们用Job来定义一个Map和Reduce的过程

然后在Storm里面我们通过Topology

来把Spout和Bolt连接在一起

形成了一个流式数据处理的这样一个结构

那么他们俩在任务的层面

实际上是能够对应起来的

那么在有了这样一个架构之后

实际上这个系统

是可以通过中心的这样一个监控

得到运行的

那我们来看

在运行的这个层面

它们是由什么样的模块组成

那我们刚刚说到

在Storm里面 

Topology是它一个具体的任务运行的模式

那么每个Topology会被Supervisor调度起来

Supervisor负责管理整个Topology任务的状态

在Topology底下

实际上我们还需要执行

具体的Spout和Bolt的任务

或者是数据处理的这样一些代码

那么它们是怎么样被封装起来的呢

实际上在一个Topology里面

它会产生Worker Process

Worker Process实际上是服务于Topology

一个或者多个

这些Worker Process呢

实际上是真正Topology运行着的进程

在这个Process里面

实际上底下

它会进一步去运行一系列叫做executor的东西

那么executor

实际上是一个一个地它建立起来的线程

在每个线程里面

它会处理一系列的任务

那么具体的任务

就是用户会往Storm的框架里面

去填写的处理数据的模块

所以它从大到小

我们经历了从Worker然后到executor

然后再到Task

这样的一个结构

那么Worker是一个进程

再往下我们会有executor的线程

再往下会有不同的数据处理的模块 Task

那么有了这样一个东西之后

实际上我们就能够分析

Storm的Topology里面

每一个数据处理模块

它的一个并行的情况

所谓并行的情况

就是 它能在多少个线程上

去并发执行这样的一个情况

那么当然这些线程可能会运行在不同的集群中

不同的服务器上

那我们来看

对于一个具体的Topology

它可能会有两个Process

也许是分别运行在不同的服务器上

进行数据的处理

每一个Process里面

会有多个executor

运行起了多个线程

它们会被CPU并行的进行调度

然后在每个executor里面

我们会有用户编写的不同的Task

那我们可以看到

我们给到的这个例子里面

从蓝色到绿色到黄色

形成了一个Topology

每一个模块

实际上可以通过统计它的executor的数量

来得到它的并行的情况

有了这样一个Topology

在架构上并行的执行的模式之后

实际上我们就要有一个新的问题去解决

有点类似于我们在MapReduce里面

所处理过的这个Shuffle的过程

我们来看在Topology里面

我们有数据流的这样一个方向

可以看到从Spout到不同的Bolt

它们之间被Topology这样一个有向的边连接起来

那么我们刚刚从并行的这样一个分析里面

我们知道

实际上数据

会从不同的executor到达不同的executor里面

那么在这里面就引入了一个新的概念

就是这个数据

它到底从一个executor怎么到达另外一个executor

它有什么样的排序的依据

那么在Storm里面

把这个概念实际上叫做了grouping

Grouping是指从Spout或者Bolt

这些处理单元不同的executor

它的数据会怎么样到达另外一个处理单元

那么在我们的这个之前的课程当中

我们在MapReduce里面

我们实际上也说到了

在MapReduce里面

有从Map到Reduce的这个过程

那么这个过程

我们之前也说它通常在实际系统中会比较耗时

因为它涉及到将这个指定的k的对应的这些数据

从某一个Map节点它的本地存储

搬到另外一个Reducer的节点

那么这个过程实际上是比较耗时的

但是它带来的好处就是

我们可以Reducer上对指定的K

进行一个处理

那么在Storm里面

实际上引入了类似的这样一个思路

我们也希望能够达到这样一个

比如说考虑数据的一些因素

考虑节点处理的这种性能

或者是一些其他的因素

来对数据进行一个这种Grouping

那我们来看

在Storm里面

它在设计的时候

使用的一些这种Grouping的原则和思路

Shuffle的这种Grouping

也就是random grouping

所以它不考虑Spout和Bolt之间这个数据流的一个关系

直接把它放过去

那么还有一些什么样的呢

基于field 基于这个数据域

比如说我们可以将某一些特定的数据

让它在某一些特定的Bolt中去处理

那比如说这些Bolt对应的物理机器服务器

我们知道它具有某些特别的性能

那么当它处理这种特定的数据域的时候

它可能具有特别的好处

或者是特别的这样的一个性能优势

那么还有一些是什么样的呢

我们可以做全量的这个数据分配

比如说All Grouping

我们可以让这个数据

被复制到所有的这个后续的Bolt节点上

那么我们还可以做其他的这种Grouping的方式

比如说我们要不要考虑

数据的这种Localities的特性

我们可以做一些Local的这种Grouping

那这是在Storm里面

由于有Topology的存在

以及Topology中每个处理单元并行性的存在

我们需要做的这样一些数据的操作

========

下面我们来看

怎么样具体去开发

一个真正的Storm的程序

然后让这个程序能够处理简单的这种数据

那么我们希望通过一个例子

来给大家看一看

Storm里面这样一个原生的代码

大概是长成什么样子的

然后各位同学怎么样把这些代码

和自己处理流式数据的任务进行结合

然后来进行真正的这样一个集群上

数据的一个处理

那么也是同样的

我们来介绍

在Storm中

假设你要开发一个Service 一个App

你的这样一个流程是什么样的

首先我们要想清楚

我们需要什么样的这种数据源  对吧

这是必不可少的

我们有了这个数据源之后

我们会需要在里面创建一系列的Bolt

然后来处理数据

然后我们要把这些Bolt

通过一个拓扑结构连接起来

这两步可能是大家在构思的时候

就会一次性的生成

然后我们会让Storm会运行这个Topology

我们说过 

Topology的概念在Storm中

就是一个MapReduce和Job这样一个概念

然后我们去Test这个Topology

看看它在小规模的数据

或者是短期的这样一个数据上

它能不能在给定的延迟 

给到我们一个想要的结果

它能不能有效的管理好内存

能不能有效的得到正确的结果

这是我们去探索的一个目标

那我们来看一个例子

这个例子呢

实际上已经给我们提供了一个Spout

一个数据源

这个数据源呢

是不断地去产生随机数

那我们的目标就是要产生一个新的数据流

这个数据流

是将我们产生的这样一个随机数的数据源

把它的数字进行一个翻倍

比如说这边有一个例子

如果给到的一个Tuple

它里面包含一个元素是74

那么它产生一个新的数据流

对应的Tuple

它的一个数据是148

我们来看

这个简单的例子

对应到Storm的代码和实现上

它是一个什么样的样子

我们来看

这个Spout 我们应该怎么样去实现

在Spout里面给了用户一个接口

这个接口叫做nextTuple

实际上 Storm系统会通过调用这个接口

来让你产生这样一个数据流

当然在某一些情况下

这个数据流已经是

你处理的这个数据任务

提供给你的

我们开看

假设我们要实现这个数据流的时候

我们需要怎么去做

那么在Storm里面

实现nextTuple就可以达到这样一个目标

我们会通过提供的

一个叫做Controlor的东西

让它去抛出一个Tuple

那么这个Tuple里面

实际上就包含了

我们刚刚所需要的这样一个数据

这是我们实现Spout的时候

去做的这样一个事情

那么当你把这个数据emit到Storm之后

Storm就会调用后续的Storm

然后来接收数据

并且让后续的Spout

去处理这个数据

然后整个Topology就会被运行起来

那么我们来看

我们实现Bolt的时候

又要去做什么呢

在实现Bolt的这个过程中

实际上我们是去执行刚刚的

就是用户实现的这样一个代码

那么数据流会从前面的Spout

或者其他的Bolt过来

然后我们在里面去做我们需要处理的这样一个任务

和Spout类似

Storm也提供了Bolt实现的这样一个接口

在里面叫做execute

execute会在有新的Tuple到达的时候

被系统调起

然后执行用户在excute里面写的代码

那么在里面也有一些基本的function

是用户可以去用的

比如说它可以用Controller

把处理之后生成了新的Tuple

往下一级进一步去传

那么回想一下

实际上Bolt和Bolt之间

也连成了Topology里面的这样一个顺序

同时呢 它会通过ack

这样一个功能

告诉Storm这个数据已经处理完了

那ack的好处

就是让整个编程人员在使用的时候

可以滞后去确认 

这个过程已经完成

它执行完到某一步

它可以告诉系统

现在我已经可以把这个Tuple传给下一个Bolt

那这是它的一个用处

那么有了Spout和Bolt的编写之后

实际上用户在这个过程的实现当中

会形成可能一系列的Bolt

那在我们刚刚具体的这个例子当中呢

它所需要做的仅仅是把数值乘以2

产生一个新的Tuple

然后emit到下一个Bolt

然后ack刚刚的操作

那么有了这些东西之后

我们看看怎么样通过Topology把它们给连接起来

在Storm里面

使用了一个叫做Topology Builder的工具

这个类

用Topology Builder来进行Bolt和Bolt的连接

那我们来看

它是怎么去做的

首先 我们可以在里面去set它的Bolt Topology

SetSpout就是说就是说这个Topology

以这个Spout作为它的数据源的输入

来驱动整个Topology的运行

同样 Topology可以往里面添加去添加它的Bolt

把这个Bolt添加到Topology里面

然后再通过它的Topology进行一个连接

可以把Spout和Bolt连接起来

连接起来之后

实际上整个Topology就已经完成了

那么有了这样一个Topology之后

实际上我们就可以去运行这样一个Storm的任务

那这边有一个视频

给大家可以看一下

在真实的一个Storm的分布式的

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

我们说了 流式数据

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

然后有它自己的一些特征

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

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

进行一次的查看

那么我们接着介绍了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

进行一个对比性的实验

大家来思考一下 

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

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