摘要：大数据计算主要包括批量计算和实时计算，针对批量计算处理的都是历史数据而不能实现低延迟高响应的缺点，基于Storm并借助开源框架Flume、Kafka，设计了一个实时数据收集与处理的系统，将数据转为流的形式，对收集来的数据直接在内存以流的形式进行计算，输出有价值的信息。最后对系统进行性能测试以及计算能力的测试。实验结果表明，该系统可扩展性良好，且并行计算能力稳定，适合大量实时数据处理。

0引言

近些年，大数据已迅速成为科技界、学术界关注的热门话题。有国家指出，大数据就是“未来的新石油”，拥有数据的规模和运用数据的能力将会成为一个国家综合国力的重要组成部分［1］。互联网、社交媒体等众多行业领域每天都产生GB甚至TB的数据。随着数据量的指数级增长，也催生了一批大数据处理技术。目前，最流行的莫过于Hadoop分布式存储计算平台［2］。Hadoop适合对数据进行批量处理，可以应用到日志分析、建立索引等方面［3］。这些都是对历史数据进行集中处理，但是在对待实时数据方面，Hadoop却显得有些力不从心。由此，Twitter公司研发出开源的实时数据计算技术Storm，它的出现使得大数据的实时处理成为可能。

1Storm简介

Storm是一个分布式的实时计算系统，它可以方便地在一个计算机集群中编写复杂的实时计算。Storm之于实时处理，就好比Mapreduce批处理［4］。其主要应用场景有流数据处理、实时搜索等［5］。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。

Storm实现了一种流式处理模型，流是一种有顺序并且连续到达的数据。在Storm计算模型中，主要有两类计算过程，分别是Spout计算过程和Bolt计算过程。Spout、Bolt分别由用户自己实现SpoutInterface和BoltInterface两类接口。Spout用于一个Topology拓扑生产消息，一般是从外部数据源接入，将数据流以tuple的形式传递给Bolt，Bolt去处理传过来的tuple。

2实时数据收集系统的设计

由于传统的数据收集与处理通常是将文件离线存储在硬盘上，再进行处理，实时性不高。为了解决这个问题，基于Storm开发一个实时数据收集与处理的系统，该系统直接将数据转为流的形式进行处理，而不再存储到文件，从而实现高响应低延迟。

为了保证整个系统的健壮性及可维护性，采取Flume和Kafka框架对实时数据进行收集与缓存，Storm则对实时数据流进行处理。图1为整个系统的架构图。

2.1Flume

Flume是一个分布式的、能有效地收集、移动大量日志数据的框架。它有一个简单的和灵活的基于流的数据流架构。这是强大的容错的可靠性机制和多故障转移和恢复机制。Flume的核心组件中包含source、channel，sink。source允许快速接入各种数据源，数据经过channel管道的暂存，最终sink使得数据流向多种目的地。

2.2Kafka

Kafka是一个分布式发布订阅消息系统。核心组件包括producer、broker和consumer。一个单一的Kafka的broker可以处理数百兆字节读取和写入每秒从成千上万的客户。Kafka内部的消息队列可以实现高吞吐量、高负载，当数据源头数据量过大时，可以在Kafka内部得到有效的暂存，否则，Storm集群处理数据的速度可能赶不上数据源数据流动的速度，容易造成集群的性能减慢甚至宕机。

2.3Storm工作机制

Storm由主节点和从节点构成。主节点运行Nimbus进程，负责代码的分发等分配任务。从节点Supervisor负责接收主节点分给它的任务，一般情况下，一个从节点上运行一个或多个进程Worker，每个进程中又产生一个或多个线程Excutor，线程用来执行Task任务，即Spout和Bolt业务逻辑。

当一个Topology被定义好后，通过Storm的jar命令，将它打包上传至主节点，主节点去zk检查集群的状态是否处于active，并且检查集群中是否存在相同名字的Topology实例在运行，然后根据代码中的参数来确定进程、线程、Spout和Bolt的数量，并设定Task任务的数量以及Task编号，将分配好的Task信息写入zk中。整个过程主节点与从节点之间是不进行通信的，所有的通信通过zk来协调［6］。

3系统实现

3.1数据源

新浪微博作为时下流行的社交平台，每时每刻都会产生不同的热门话题以反映民众的关注点。为了统计实时的热门话题内容，采用在内存中不定时随机产生不同的词条的方法来模拟微博上的话题，并且通过Storm框架对数据进行分析统计出实时的热门话题。

通过内存中产生数据模拟实时数据，以log4j形式进行接收，Flume用avro网络流的形式读取log4j接收到的数据。采用XML配置集成log4j与Flume，完成数据源source对实时数据的读取。图2是Storm工作流程图。

3.2Flume集成Kafka

虽然Flume已经自带实现了avro sink、hdfs sink等多种sink，但是没有对接Kafka的sink，因此，首先自定义流向到Kafka的sink。通过继承一个AbstrackSink并且实现Configurable接口。其中有两个核心方法，分别是configure和process，实现自定义Flume到Kafka的sink。

3.3Storm处理数据流

Spout是一个Topology的数据源，在服务器上应该时刻在产生数据，Spout读取实时的数据。本文将数据以log4j的形式在内存中不断产生，根据设计的系统，Spout将从Kafka中不断读取数据。这里不需要手动实现一个Spout，stormkafka的插件中已经提供好一个类KafkaSpout，使用它Storm会从Kafka中不断读数据。

数据流流入bolt进行逻辑处理，Spout产生的话题作为关键字，对源码进行分析可知，Bolt会根据“bytes”字段将接收过来的数据进行区分。根据设计的系统流程，每当产生一个话题，就向关系型数据库插入一条数据，用来持久化。

3.4系统性能测试

当数据源不停产生数据时，可能会削弱Storm的计算能力，当海量数据产生时，甚至可能导致Storm的宕机。为了测试整个系统中Kafka的消息队列是否能暂存大量的数据，采用多线程［7］技术，同时运行若干线程产生数据，每个线程产生相同的数据量，通过对Storm计算效率的对比来验证。表1为Storm计算性能与线程数的关系。图3为Storm处理数据量与时间的关系。

通过上述图表可以清晰地看出，Storm的计算时间是随着数据量的增大线性递增的，而不是指数型递增，说明Storm的计算能力没有随着数据量的增大而削弱，在Kafka的作用下，数据得到了有效的缓存，使得Storm正常运作，从而保证整个系统的稳定性。

3.5Storm并行度测试

为了测试Storm横向扩展给整个系统带来的性能影响，分别在单个节点和集群的情况下进行测试。对paramhint参数设置，改变进程、线程数量，分析Storm计算能力。

通过图4、图5可以得出，在单节点下，随着线程数量的增多Storm计算能力反而减弱；而在集群下，随着线程的增加计算能力增加。所以建议在非集群下，不要增加进

程的数量，此时随并行度的增大计算能力会下降。无论是单节点还是集群，Storm的计算能力都会随线程数量的增加而增强。

4结论

本文通过对Storm的体系结构进行分析，结合Flume、Kafka框架，实现了一个实时数据收集与计算的系统。该系统具有良好的可扩展性。下一步的主要工作是接入实际生产中的数据源，如实时股票浮动数据、实时天气数据等，并且对Storm的实时计算结果进行动态的可视化。

关于：中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务，十年研发经验，上百成功案例，中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值，致力于为用户提供很好的软件解决方案。联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com