[转]基于Storm的实时数据处理方案

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仍是有着很好的前景的。

 

转载自：http://blog.csdn.net/endlu/article/details/51169383