Storm数据流模型的分析及讨论

1）  第一种方式：首先kill掉已经在集群中运行的Topology1计算任务，然后实现Business2 Bolt的计算逻辑，并重新打包形成一个新的Topology计算任务jar包后，提交到Storm集群中重新运行，这时候Storm内的整体Topology结构如下：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/FF122814251.png" />

这种方式的缺点在于：由于要重启Topology，所以如果Spout或Bolt有状态则会丢失掉；同时由于Topology结构发生了变化，因此重新运行Topology前需要对程序的稳定性、正确性进行验证；另外Topology结构的变化也会带来额外的运维开销。

2）  第二种方式：完全开发部署一套新的Topology，其中前面的公共部分的Spout和Bolt可以直接复用，只需要重新开发新的计算逻辑Business2 Bolt来替换原有的Business1 Bolt即可。然后重新提交新的Topology运行。这时候Storm内的整体Topology结构如下：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/DE122814650.png" />

这种方式的缺点在于：由于两个Topology都会从External Data Source读取同一份数据，无疑增加了External Data Source的负载压力；而且会导致同样的数据在Storm集群内被传输相同的两份，被同样的计算单元Bolt进行处理，浪费了Storm的计算资源和网络传输带宽。假设现在不止有两个这样的Topology计算任务，而是有N个，那么对Storm的计算Slot的浪费很严重。

注意：上述两种方式还有一个公共的缺点——系统可扩展性不好，这意味着不管哪种方式，只要以后有这种新增业务逻辑的需求，都需要进行复杂的人工操作或线性的资源浪费现象。

3） 第三种方式：OK，看了以上两种方式后，也许你会提出下面的解决方案：通过Kafka这样的消息中间件，实现不同Topology的Spout共享数据源，而且这样可以做到消息可靠传输、消息rewind回传等，好处是对于Storm来说，已经有了storm-kafka插件的支持。这时候Storm内的整体Topology结构如下：

498)this.width=498;'' onmousewheel = ''javascript:return big(this)'' alt="" src="/uploadfile/201301/12/DC122814102.png" />

这种实现方式可以通过引入一层消息中间件减少对External Data Source的重复访问的压力，而且可以通过消息中间件层，屏蔽掉External Data Source的细节，如果需要扩展新的业务逻辑，只需要重新部署运行新的Topology，应该说是现有Storm版本下很好的实现方式了。不过消息中间件的引入，无疑将给系统带来了一定的复杂性，这对于Storm上的应用开发来说提高了门槛。

值得注意的是，方案三中仍遗留有一点问题没有解决：对于Storm集群来说，这种方式还是没有能够从根本上避免数据在Storm不同Topology内的重复发送与处理。这是由于Storm的数据流模型上的限制所导致的，如果Storm实现了不同Topology之间Stream的共享，那么这一问题也就迎刃而解了。

一个流处理系统的数据流模型

个人工作中有幸参与过一个流处理框架的开发与应用。下面我们来简单看看其中所采用的数据流模型。

首先，先来看一下该流处理系统内的几个基本概念：

1）数据流（data stream）：时间分布和数量上无限的一系列数据记录的集合体；

2）数据记录（data record）：数据流的最小组成单元，每条数据记录包括 3 类数据：所属数据流名称（stream name）、用于路由的数据（keys）和具体数据处理逻辑所需的数据（value）；

3）数据处理任务定义（task definition）：定义一个