基于Storm构建分布式实时处理应用初探

Storm对比Hadoop，前者更擅长的是实时流式数据处理，后者更擅长的是基于HDFS，通过MapReduce方式的离线数据分析计算。对于Hadoop，本身不擅长实时的数据分析处理。两者的共同点都是分布式架构，而且都类似有主/从关系的概念。

本文不会具体阐述Storm集群和Zookeeper集群如何部署的问题，这里想通过一个实际的案例切入，分析一下如何利用Storm完成实时分析处理数据。

Storm本身是Apache托管的开源的分布式实时计算系统，它的前身是Twitter Storm。在Storm问世以前，处理海量的实时数据信息，大部分是类似于使用消息队列，加上工作进程/线程的方式。这使得构建这类的应用程序，变得异常的复杂。很多的业务逻辑中，你不得不考虑消息的发送和接收，线程之间的并发控制等等问题。而其中的业务逻辑可能只是占据整个应用的一小部分，而且很难做到业务逻辑的解耦。但是Storm的出现改变了这种局面，它首先抽象出数据流Stream的抽象概念，一个Stream指的是tuples组成的无边界的序列。后面又继续提出Spouts、Bolts的概念。Spouts在Storm里面是数据源，专门负责生成流。而Bolts则是以流作为输入，并重新生成流作为输出，并且Bolts还会继续指定它输入的流应该如何划分。最后Storm是通过拓扑(Topology)这种抽象概念，组织起若干个Spouts、Bolts构成的分布式数据处理网络。Storm设计的时候，就有意的把Spouts、Bolts组成的拓扑(Topology)网络通过Thrift服务方式进行封装，这个做法，使得Storm的Spouts、Bolts组件可以通过目前主流的任意语言实现，使得整个框架的兼容性和扩展性更加优秀。

在Storm里面拓扑(Topology)的概念，非常类似Hadoop里面MapReduce的Job的概念。不同的是Storm的拓扑(Topology)只要你启动了，它就会一直运行下去，除非你kill掉;而MapReduce的Job最终它是会结束的。基于这样的模式，使得Storm非常适合处理实时性的数据分析、持续计算、DRPC(分布式RPC)等。

下面就结合实际的案例，设计分析一下，如何利用Storm改善应用的处理性能。

某通信公司的垃圾短信监控平台，实时地上传每个省的疑似垃圾短信用户的垃圾短信内容文件，每个省则根据文件中垃圾短信的内容，解析过滤出，包含指定敏感关键字的垃圾短信进行入库。被入库的垃圾短信用户被列为敏感用户，是重点监控对象，毕竟乱发这些垃圾短信是非常不对的。垃圾短信监控平台生成的文件速度非常惊人，原来的传统做法是，根据每个省的每一个地市，对应一个独立应用，串行化地解析、过滤敏感关键字，来进行入库处理。但是，从现状来看，程序处理的性能并不高效，常常造成文件积压，没有及时处理入库。

现在，我们就通过Storm来重新梳理、组织一下上述的应用场景。

首先，我先说明一下，该案例中Storm集群和Zookeeper集群的部署情况，如下图所示：

<