Storm数据流模型有哪些

76次阅读
没有评论

共计 2357 个字符,预计需要花费 6 分钟才能阅读完成。

这篇文章主要讲解了“Storm 数据流模型有哪些”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着丸趣 TV 小编的思路慢慢深入,一起来研究和学习“Storm 数据流模型有哪些”吧!

Storm 是一个开源的实时计算系统,它提供了一系列的基本元素用于进行计算:

1 Topology 

2 Stream

3 spout

4 bolt

在我们提交我们的 topology 的时候,一旦你提交了你的 topology 到你的集群之中后,除非你显示的去停止任务

集群中间的 topology 会一直的在运行

计算任务 Topology 是由不同的 Spouts 和 bolts,通过数据流 Stream 连接起来的图,下面是一个 Topology 的结构示意图

其中包括了

1 :  Spout:Strom 中的消息源头,用于为 Topology 来生产消息(数据), 一般是从外部的数据源开始读取数据,在我们的真实环境之中,我们采用的是 kafka-Storm 流式对接的接口,所以我们 使用的 Spout 为 :kafkaSpout

2 Bolt, Storm 中的消息处理者,用于为 Topology 进行消息的处理,Bolt,可以执行如下的几种操作:

  2.1:过滤

      2.2:聚合

  2.3:查询数据库

  等几种操作,并且可以一级一级的进行处理,最终 Topology 会被提交到 Storm 集群中运行,也可以通过命令停止 topology 的运行,并且将占用的资源归还给 Storm 集群。

Storm 数据流模型

数据流的模型是 Storm 中对数据进行的抽象,它是时间上无界的 tuple 的元祖,在 topology 之中,Spout 是 bolt 的源头,

bolt 是对于 Spout 的消费者,负责 Topology 从特定数据源发射 Stream,bolt 可以接受任意多个 Stream 输入,然后进行数据的加工处理工作,如果需要,bolt 还可以发射出新的 Stream 给下一级 Bolt 进行处理

下面是一个 Topology 内部 Spout 和 Bolt 之间的数据流关系:

topology 中每一个计算组件(Spout 和 bolt)都有一个并行度来控制,在创建 Topology 时可以进行指定,Storm 在集群内分配对应并行度个数的线程来同时执行这一个组件

那么,有一个这样的问题:既然对于一个 Spout,或 Bolt,都会有多个 task 线程来运行,那么如何在两个组件之间发送 tuple 元祖了?

Storm 提供了好几种数据流的分发策略用来解决这一个问题,在 Topology 定义的时,需要为每一个 bolt 指定接受什么样的 Stream 作为它输入

目前 Storm 中提供了一下的 7 种 Stream Grouping

Shuffle Grouping、

Fields Grouping、

All Grouping、

Global Grouping、

Non Grouping、

Direct Grouping、

Local or shuffle grouping

一种 Storm 不能支持的场景

如果您阅读到这里,那么您可以细细的回想起来,当我们每一个业务逻辑都被一个 Topolo 持有的时候,

只能在 Topology 内按照“发布 - 订阅”方式在不同的计算组件 (spout/bolt) 之间进行数据的处理,而 Stream 在

Topology 之间是无法流动的。

很多时候,开始需要把你所有的业务逻辑写到你的一个 Topology 之中,请不要忘记:Stream 在 topology 之间是无法流动的

也就是意味着一个业务逻辑的过程,不能够和另外的一个业务过程进行通信

我们假设现在有这样的一个 Topology1, 在整个 Topology 的过程之中,通过初步的 filter,join bolt,Business1

Bolt,其中,Filter Bolt 用于对数据的过滤,join Bolt 用于数据流的聚合,如下图所示:

目前这个 Topology 已经被提交到集群了,那么,如果我们需要一个新的业务逻辑,而

这个 Topology 的特点是和 Topology1 公用的数据源,而且前期的预处理过程是一样的

那么这时候 Storm 怎么满足这一需求?

1 第一:kill 掉原先的 topology,然后实现 bussiness Bolt 的计算逻辑,并且重新打包形成一个新的

topology 计算任务的 jar 包后,提交到 Storm 集群之中重新运行,那么目前,我们的结构图如下所示:

这样的过程之中,来自于不同数据源的处理过程,经过处理以后,经过 join 以后,被发送到两个业务逻辑的处理 Bolt 之中。

第一种方式的缺陷:

 Topology 需要重新来部署,并且状态会丢失。而且需要修改你自身的 topology 结构,失去了稳定性的保证

2:第二种方式:

同一份的数据源被被两份处理流程所消费。无疑增加了 External Data Source 的负载压力,而且会导致我们的发射数据在集群之中被传输两份,一旦数据重复读取的因子超过 2,那么对 Storm 的计算 Slot 的浪费很严重

3 第三种方式

   ok,看了以上两种方式以后,也许你会提出下面的解决方案,通过 kafka 这样的消息中间件,来实现不同 Topology 的

Spout 共享数据源头,而且这样可以做到  

 3.1:【消息可靠传输】 

 3.2:【消息 rewind 回传等】

  有关 kafka-Storm 的接入组件,请参考【至静】所写的其他 kafka 有关的博文

对于消息中间件的引入,一方面减少了对减少对 External Data Source 的重复访问压力,而且通过消息中间件,我们屏蔽了 External Data Sourcede 的重复访问压力

感谢各位的阅读,以上就是“Storm 数据流模型有哪些”的内容了,经过本文的学习后,相信大家对 Storm 数据流模型有哪些这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是丸趣 TV,丸趣 TV 小编将为大家推送更多相关知识点的文章,欢迎关注!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计2357字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)