实时处理方案架构-笔记.docx

1、数据接入层

该部分有多种数据收集方式，包括使用消息队列（MetaQ），直接通过网络

Socket传输数据，前端业务系统专有数据采集API，对Log问价定时监控。

2、为什么选择消息队列？

为什么不把数据直接问导入storm中？而是使用消息队列（MetaQ）?

使用消息队列作为数据中间处理组件的原因是:

在大批量数据处理时，前端业务数据产生速度可能会很快，而实时处理或者其他处理速度跟不上，会影响整个系统处理性能，引入消息队列之后，我们可以把数据临时存储在消息队列中，后端处理速度就不会影响前端业务数据的产生，比较专业的术语叫做解除耦合，增加系统扩展性，系统各组件异步运行。

为什么使用MetaQ？

在消息队列选择上，kafka是一个比较通用的，开源时间较长的消息发布订阅系统，而MetaQ是基于kafka开发的，使用我们比较熟悉的Java开发，并且在此基础上作了一定的改进，如数据可靠及事务处理等。

另一方面，这是国人开源的东西，各方面的文档比较完整，并且有相关的实例接口。所以使用MetaQ作为消息中间件，开发成本比较低，又有较好的性能。

Log文件监控

有时候我们的数据源是已经保存下来的log文件，那Spout就必须监控

Log文件的变化，及时将变化部分的数据提取写入Storm中，这很难做到完全实时性。

3、为何使用storm作为实时处理的核心？

Storm作为开源比较早的一款实时处理系统，其功能比较完善。其failover机制相当给力，无论是woker还是supervisor，甚至是task，只要挂掉都能自动重启；其性能经过测试还是相当不错的且目前网络相关资料较多，这就意味着开发代价会小很多；其扩展性非常好，能够横向扩展。

Storm目前的短处：

在于nimbus单点，如果nimbus挂掉，整个系统会挂掉，这是Storm需要改进的地方，不过nimbus的系统压力不大，一般情况下也不会出现宕机。

4、storm具体应用场景

1）、条件过滤

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

2）、中间计算

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

3）、求TopN

相信大家对TopN类的业务需求也是比较熟悉的。

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

4）、推荐系统

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

样就是实现了简单的智能推荐。

5）、分布式RPC

Storm有对RPC进行专门的设计，分布式RPC用于对Storm上大量的函数调用进行并行计算，最后将结果返回给客户端。

6）、批处理

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

7）、热度统计

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

5、数据落地层

1）、MetaQ

Storm与MetaQ是有一条虚线相连的，部分数据在经过实时处理之后需要写入MetaQ之中，因为后端业务系统需要从MetaQ中获取数据。

这严格来说不算是数据落地，因为数据没有实实在在写入磁盘中持久化。

2）、MySql

此处列出Mysql代表传统数据库与Storm的接口差不多都相似。一般情况下，数据量不是非常大的情况下可以使用Mysql作为数据落地的存储对象。

Mysql对数据后续处理也是比较方便的，且网络上对Mysql的操作也是比较多的，在开发上代价比较小，适合中小量数据存储。

3）、HDFS

HDFS及基于Hadoop的分布式文件系统。

许多日志分析系统都是基于HDFS搭建出来的，所以开发Storm与HDFS的数据落地接口将很有必要。

例如将大批量数据实时处理之后存入Hive中，提供给后端业务系统进行处理，例如日志分析，数据挖掘等等。

4）、Lustre

在某些应用上比较适用。

例如：

Lustre作为数据落地的应用场景是，数据量很大，且处理后目的是作为归档处理。这种情形，Lustre能够为数据提供一个比较大（相当大）的数据目录，用于数据归档保存。Lustre的架构可以采用Lustre+drbd+heartbeat的架构，这样既能为整个系统提供一个超大容量的归档统一命名目录空间，又能保证数据的安全（双机热备）。

6、元数据管理器

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

1）、元数据设计

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

7、关于Storm和Hadoop对比

Storm关注的是数据多次处理一次写入，而hadoop关注的是数据一次写入，多次处理使用（查询）。

Storm系统运行起来后是持续不断的，而hadoop往往只是在业务需要时调用数据。两者关注及应用的方向不一样。

8、Storm的应用前景

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

总体来看，在数据量越来越大，需要处理挖掘的数据需求越来越多的情况下，Storm

还是有着很好的前景的。