1 文档说明

该文档描述的是以storm为主体的实时处理架构，该架构包括了数据收集部分，实时处理部分，及数据落地部分。

关于不同部分的技术选型与业务需求及个人对相关技术的熟悉度有关，会一一进行分析。

该架构是本人所掌握的一种架构，可能会与其他架构有相似的部分，个人会一一解释对其的理解。

这个文章写的很详细，相信对大家在实时处理整体理解上会有帮助的。

2 实时处理架构

2.1 整体架构图

架构说明：

整个数据处理流程包括四部分，一部分是数据接入层，该部分从前端业务系统获取数据；中间部分是最重要的storm实时处理部分，数据从接入层接入，经过实时处理后传入数据落地层；第三部分为数据落地层，该部分指定了数据的落地方式；第四部分元数据管理器。

2.2 数据接入层

该部分有多种数据收集方式，包括使用消息队列（MetaQ），直接通过网络Socket传输数据，前端业务系统专有数据采集API，对Log问价定时监控。

2.2.1 MetaQ

为什么选择消息队列?

这或许是大家比较疑惑的地方，会疑惑为什么不把数据直接导入storm中。使用消息队列作为数据中间处理组件的原因是，在大批量数据处理时，前端业务数据产生速度可能会很快，而实时处理或者其他处理速度跟不上，会影响整个系统处理性能，引入消息队列之后，我们可以把数据临时存储在消息队列中，后端处理速度就不会影响前端业务数据的产生，比较专业的术语叫做解除耦合，增加系统扩展性，系统各组件异步运行。

为什么使用MetaQ？

在消息队列选择上，kafka是一个比较通用的，开源时间较长的消息发布订阅系统，而MetaQ是基于kafka开发的，使用我们比较熟悉的Java开发，并且在此基础上作了一定的改进，如数据可靠及事务处理等。另一方面，这是国人开源的东西，各方面的文档比较完整，并且有相关的实例接口。所以使用MetaQ作为消息中间件，开发成本比较低，又有较好的性能。

2.2.2 Socket

部分人使用网络Socket编程实现Storm的数据接入。这是一种比较直接的数据采集方式，并且确实有些Storm相关的项目使用这种数据接入方式。

这种数据接入方式比较简单，维护成本较低，但数据量相对于使用消息中间件来说较小。

难点：

使用Socket采集数据比较麻烦的是，由于Storm的Spout的地址是不定的，无法确定其地址，则前端业务系统就无法将数据准确的发送的某个具体IP地址上的端口中。解决方法如下：

(1) 我们可以使用zookeeper作为传输站，Spout执行后，将本地有效的IP地址及可用正在监控的端口等信息写入zookeeper中，前端业务系统从zookeeper目录中获取该信息。

(2) 使用元数据指导前端业务系统数据发送，Spout将本地IP及端口信息存入元数据管理器中，前端业务系统从元数据管理器中获取该参数信息。

2.2.3 前端业务系统数据采集API

这种数据采集方式就不多说了，前端业务系统为Spout专门设计的数据采集API，Spout只需调用该API就能获取数据。

2.2.4 Log文件监控

有时候我们的数据源是已经保存下来的log文件，那Spout就必须监控Log文件的变化，及时将变化部分的数据提取写入Storm中，这很难做到完全实时性。

2.3 Storm实时处理系统

2.3.1 说明

前面部分数据接入层其实已经包含部分storm相关的内容，例如一些数据采集接口就是属于Storm的Spout部分，我把该部分单独拿出来的意思是把实时处理核心部分作为一个大章节，即实时处理部分（除数据接入及数据落地的接口）。

2.3.2 使用Storm原因

为何选择Storm作为实时处理的核心呢？Storm作为开源比较早的一款实时处理系统，其功能比较完善，其failover机制相当给力，无论是woker还是supervisor，甚至是task，只要挂掉都能自动重启；其性能经过测试还是相当不错的且目前网络相关资料较多，这就意味着开发代价会小很多；其扩展性非常好，能够横向扩展。Storm目前的短处在与nimbus单点，如果nimbus挂掉，整个系统会挂掉，这是Storm需要改进的地方，不过nimbus的系统压力不大，一般情况下也不会出现宕机。

2.3.3 实时处理业务接口

该部分需要提供一个实时业务处理的接口，即将用户的业务层需求转换为实时处理的具体模式。例如模仿Hive提供一个类Sql的业务接口，我们将一类数据在元数据管理器中描述是一个表，不同字段是表中不同字段

select ---------------------------固定数据查询（异常或者脏数据处理），

max/min/avg-------------------最大最小值

count/sum----------------------求和或次数统计（比如pv等）

count(distinct)------------------去重计数（典型的如UV）

order by------------------------排序（取近访问的用户）

group by + 聚类函数 + order by-----聚类后排序（如访问次数最多的topN商品）

这只是简单类比，我们可以将实时处理的业务需求转化为Sql相关语句，上层执行类Sql语句，底层将其翻译成具体Topology组成及节点参数等。

2.3.4 具体业务需求

(1) 条件过滤

这是Storm最基本的处理方式，对符合条件的数据进行实时过滤，将符合条件的数据保存下来，这种实时查询的业务需求在实际应用中是很常见的。

(2) 中间计算

我们需要改变数据中某一个字段（例如是数值），我们需要利用一个中间值经过计算（值比较、求和、求平均等等）后改变该值，然后将数据重新输出。

(3) 求TopN

相信大家对TopN类的业务需求也是比较熟悉的，在规定时间窗口内，统计数据出现的TopN，该类处理在购物及电商业务需求中，比较常见。

(4) 推荐系统

正如我架构图中画的那样，有时候在实时处理时会从mysql及hadoop中获取数据库中的信息，例如在电影推荐系统中，传入数据为用户当前点播电影信息，从数据库中获取的是该用户之前的一些点播电影信息统计，例如点播最多的电影类型、最近点播的电影类型，及其社交关系中点播信息，结合本次点击及从数据库中获取的信息，生成一条推荐数据，推荐给该用户。并且该次点击记录将会更新其数据库中的参考信息，这样就是实现了简单的智能推荐。

(5) 分布式RPC

Storm有对RPC进行专门的设计，分布式RPC用于对Storm上大量的函数调用进行并行计算，最后将结果返回给客户端。（这部分我也不是很懂）

(6) 批处理

所谓批处理就是数据攒积到一定触发条件，就批量输出，所谓的触发条件类似时间窗口到了，统计数量够了及检测到某种数据传入等等。

(7) 热度统计

热度统计实现依赖于TimeCacheMap数据结构，该结构能够在内存中保存近期活跃的对象。我们可以使用它来实现例如论坛中的热帖排行计算等。

2.4 数据落地层

2.4.1 MetaQ

如图架构所示，Storm与MetaQ是有一条虚线相连的，部分数据在经过实时处理之后需要写入MetaQ之中，因为后端业务系统需要从MetaQ中获取数据。这严格来说不算是数据落地，因为数据没有实实在在写入磁盘中持久化。

2.4.2 Mysql

此处列出Mysql代表传统数据库与Storm的接口差不多都相似。一般情况下，数据量不是非常大的情况下可以使用Mysql作为数据落地的存储对象。Mysql对数据后续处理也是比较方便的，且网络上对Mysql的操作也是比较多的，在开发上代价比较小，适合中小量数据存储。

2.4.3 HDFS

HDFS及基于Hadoop的分布式文件系统。许多日志分析系统都是基于HDFS搭建出来的，所以开发Storm与HDFS的数据落地接口将很有必要。例如将大批量数据实时处理之后存入Hive中，提供给后端业务系统进行处理，例如日志分析，数据挖掘等等。

2.4.4 Lustre

写这个数据落地方式，一方面是因为最近在研究Lustre，对其比较熟悉；另一方面也却是在某些应用上比较适用，例如Lustre作为数据落地的应用场景是，数据量很大，且处理后目的是作为归档处理。这种情形，Lustre能够为数据提供一个比较大（相当大）的数据目录，用于数据归档保存。

Lustre的架构可以采用Lustre+drbd+heartbeat的架构，这样既能为整个系统提供一个超大容量的归档统一命名目录空间，又能保证数据的安全（双机热备）。

2.5 元数据管理器

2.5.1 设计目的

元数据管理器的设计目的是，整个系统需要一个统一协调的组件，指导前端业务系统的数据写入，通知实时处理部分数据类型及其他数据描述，及指导数据如何落地。元数据管理器贯通整个系统，是比较重要的组成部分。

2.5.2 元数据设计

元数据设计可以使用mysql存储元数据信息，结合缓存机制开源软件设计而成。

3 相关说明

3.1 关于Storm和Hadoop对比

Storm关注的是数据多次处理一次写入，而hadoop关注的是数据一次写入，多次处理使用（查询）。Storm系统运行起来后是持续不断的，而hadoop往往只是在业务需要时调用数据。

两者关注及应用的方向不一样。

3.2 Storm的应用前景

就目前来说，越来越多的公司在用storm，像一些推荐系统啊，金融系统啊，在小一些的应用场景也有，例如预警系统，网站统计等等，其在数据处理方面有着天然的优势。

总体来看，在数据量越来越大，需要处理挖掘的数据需求越来越多的情况下，Storm还是有着很好的前景的。