实时处理方案架构(作者-落枫)

实时处理方案架构

作者：黄崇远

时间：2013/9/17

目录

实时处理方案架构 (1)

1 文档说明 (1)

2 实时处理架构 (1)

2.1 整体架构图 (1)

2.2 数据接入层 (2)

2.2.1 MetaQ (2)

2.2.2 Socket (2)

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

2.2.4 Log文件监控 (2)

2.3 Storm实时处理系统 (3)

2.3.1 说明 (3)

2.3.2 使用Storm原因 (3)

2.3.3 实时处理业务接口 (3)

2.3.4 具体业务需求 (3)

2.4 数据落地层 (4)

2.4.1 MetaQ (4)

2.4.2 Mysql (4)

2.4.3 HDFS (4)

2.4.4 Lustre (4)

2.5 元数据管理器 (4)

2.5.1 设计目的 (4)

2.5.2 元数据设计 (5)

3 相关说明 (5)

3.1 关于Storm和Hadoop对比 (5)

3.2 Storm的应用前景 (5)

1 文档说明

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

关于不同部分的技术选型与业务需求及个人对相关技术的熟悉度有关，会一一进行分析。该架构是本人所掌握的一种架构，可能会与其他架构有相似的部分，个人会一一解释对其的理解。

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

相关技术文章会持续更新，如果对我的博客刚兴趣，请关注我的博客：

/huangchongyuan

如果有兴趣一起讨论技术，请加入我的qq群：

191321336(群共享中有相关源代码及资料)

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中获取数据库中的信息，例如在电影推荐系统中，传入数据为用户当前点播电影信息，从数据库中获取的是该用户之前的一些点播电影信息统计，例如点播最多的电影类型、最近点播的电影类型，及其社