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

Information classification: Internal 信息分类: 内部  HYPERLINK /panfeng412/archive/2012/07/29/storm-stream-model-analysis-and-discussion.html Storm数据流模型的分析及讨论 本文首先介绍了Storm的基本概念和数据流模型，然后结合一个典型应用场景来说明Storm支持Topology之间数据流订阅的必要性，最后对比了Storm与另一个流处理系统在数据流模型上的区别之处。 Storm基本概念 Storm是一个开源的实时计算系统，它提供了一系列的基本元素用于进行计算：Topology、Stream、Spout、Bolt等等。 在Storm中，一个实时应用的计算任务被打包作为Topology发布，这同Hadoop的MapReduce任务相似。但是有一点不同的是：在Hadoop中，MapReduce任务最终会执行完成后结束；而在Storm中，Topology任务一旦提交后永远不会结束，除非你显示去停止任务。 计算任务Topology是由不同的Spouts和Bolts，通过数据流（Stream）连接起来的图。下面是一个Topology的结构示意图： 其中包含有： Spout：Storm中的消息源，用于为Topology生产消息（数据），一般是从外部数据源（如Message Queue、RDBMS、NoSQL、Realtime Log）不间断地读取数据并发送给Topology消息（tuple元组）。 Bolt：Storm中的消息处理者，用于为Topology进行消息的处理，Bolt可以执行过滤， 聚合， 查询数据库等操作，而且可以一级一级的进行处理。 最终，Topology会被提交到storm集群中运行；也可以通过命令停止Topology的运行，将Topology占用的计算资源归还给Storm集群。 Storm数据流模型 数据流（Stream）是Storm中对数据进行的抽象，它是时间上无界的tuple元组序列。在Topology中，Spout是Stream的源头，负责为Topology从特定数据源发射Stream；Bolt可以接收任意多个Stream作为输入，然后进行数据的加工处理过程，如果需要，Bolt还可以发射出新的Stream给下级Bolt进行处理。 下面是一个Topology内部Spout和Bolt之间的数据流关系： Topology中每一个计算组件（Spout和Bolt）都有一个并行执行度，在创建Topology时可以进行指定，Storm会在集群内分配对应并行度个数的线程来同时执行这一组件。 那么，有一个问题：既然对于一个Spout或Bolt，都会有多个task线程来运行，那么如何在两个组件（Spout和Bolt）之间发送tuple元组呢？ Storm提供了若干种数据流分发（Stream Grouping）策略用来解决这一问题。在Topology定义时，需要为每个Bolt指定接收什么样的Stream作为其输入（注：Spout并不需要接收Stream，只会发射Stream）。 目前Storm中提供了以下7种Stream Grouping策略：Shuffle Grouping、Fields Grouping、All Grouping、Global Grouping、Non Grouping、Direct Grouping、Local or shuffle grouping，具体策略可以参考 HYPERLINK /nathanmarz/storm/wiki/Concepts 这里。 一种Storm不能支持的场景 以上介绍了一些Storm中的基本概念，可以看出，Storm中Stream的概念是Topology内唯一的，只能在Topology内按照“发布-订阅”方式在不同的计算组件（Spout和Bolt）之间进行数据的流动，而Stream在Topology之间是无法流动的。 这一点限制了Storm在一些场景下的应用，下面通过一个简单的实例来说明。 假设现在有一个Topology1的结构如下：通过Spout产生数据流后，依次需要经过Filter Bolt，Join Bolt，Business1 Bolt。其中，Filter Bolt用于对数据进行过滤，Join Bolt用于数据流的聚合，Business1 Bolt用于进行一个实际业务的计算逻辑。 目前这个Topology1已经被提交到Storm集群运行，而现在我们又有了新的需求，需要计算一个新的业务逻辑，而这个Topology的特点是和Topology1公用同样的数据源，而且前期的预处理过程完全一样（依次经历Filter Bolt和Join Bol