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

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

1）每个处理结点启动流处理过程后，开启网络服务，监听从上一级处理结点发出的TCP连接请求，接收从上一级结点发来的数据；

2）处理结点不间断地接收从上一级处理结点发来的数据，对于每条数据记录，根据数据流名进行筛选，将其分发到该数据流所对应的处理进程中；

3）将从每个特定数据流发来的数据，广播到所有以该数据流作为输入数据流的数据处理任务实例中；

4）数据处理任务实例从其输入数据流中接收数据，按照过滤条件进行筛选，然后将符合过滤条件的数据记录发送给外部应用程序进行处理；

5）外部应用程序启动外部处理进程，对数据进行实际处理过程，并将每条数据记录的处理结果返回给相应的数据处理任务实例；

6）数据处理任务实例从外部应用程序收集处理后的结果数据，并依次将其转发到对应的输出数据流中；

7）输出数据流进程接收发向该数据流的数据，然后按照数据流的订阅关系，将数据发送到所有订阅了该数据流的下一级处理结点；

8）根据下一级处理结点的IP地址和端口号，通过TCP请求与下一级处理结点建立网络连接，然后将数据按序传输到下一级处理结点。

二者在数据流模型上的不同之处

至于两个系统的实现细节，我们先不去做具体比较，下面仅列出二者在数据流模型上的一些不同之处（这里并不是为了全面对比二者的不同之处，只是列出其中的关键部分）：

1）  在Storm中，数据流Stream是在Topology内进行定义，并在Topology内进行传输的；而在上面提到的流处理系统中，数据流Stream是在整个系统内全局唯一的，可以在整个集群内被订阅。

2）  在Storm中，数据流Stream的发布和订阅都是静态的，所谓静态是指数据流的发布与订阅关系在向Storm集群提交Topology计算任务时，被一次性生成的，这一关系在Topology的运行过程中是不能被改变的；而在上面提到的流处理系统中，数据流Stream的发布和订阅都是动态的，即数据处理任务task可以动态的发布Stream，也可以动态的订阅系统内已经生成的任意Stream，数据流的订阅关于通过分布式应用程序协调服务ZooKeeper集群的动态节点来维护管理。

好了，有了以上的对比，我们不难发现，对于本文所举的应用场景实例，Storm的数据流模式尚不能很方便的支持，而在这里提到的这个流处理系统的全局数据流模型下，这一应用场景的需求可以很方便的满足。

总结的话

个人觉得，Storm有必要实现不同Topology之间Stream的共享，这个至少可以在不损失Storm现有功能的前提下，使得Storm在处理实际生产环境下的一些应用场景时更加从容应对。

至于如何在现有Storm的基础上实现这一需求，可能的方式很多。一种简单的方式是通过Zookeeper来集中存储、动态感知Topology之间Stream的“发布-订阅”关系，同时在Storm的消息分发过程中对这种情况加以处理。

以上观点，如果不对之处，欢迎大家指出。

原文链接：http://www.cnblogs.com/panfeng412/archive/2012/07/29/storm-stream-model-analysis-and-discussion.html