随着互联网用户数量的持续增长^[1]以及以Web 2.0为代表的互联网技术的迅速发展，有着方便、快捷、价格相对便宜的优点的网上购物，受到越来越多人的青睐. 此外，消费者还习惯于利用电子商务网站提供的评论模块分享自己对产品的评价以及购物体验. 由于产品的在线评论数据蕴涵着丰富反馈信息以及近年来在线评论数据的大量增长，使得消费者和商家对它的重视程度越来越高. 一方面，商家可以通过用户评论信息及时掌握用户的消费趋势, 进而优化电商的服务水平，提高用户的满意度和忠诚度，特别是电子商务发展到现在的阶段，商家对于客户的服务水平已经成为比拼的焦点，对客户资源的重视程度也上升到了全新的高度；另一方面，产品的评论信息作为一种新型的口碑传播方式，已经成为用户了解产品质量和服务的重要信息来源. 所以，如何尽早地获取在线产品的评论信息，进而实时地把握产品舆情，无论对商家还是消费者都显得十分重要.

近些年来，通过优化采集周期来尽早获取网页的增量信息的方法有很多种，方法大致分为以下几类：A. K. Sharma等^[2-3]提出了SART算法，该算法不需要网页完整的历史更新记录，而是根据每次采集后不断积累起来的网页历史修改频率的数据来对网页下一次采集时间进行优化，不足之处是过于关注网页的更新频率，数据抓取的滞后时间比较大. 文献[4-7]提出了基于Poisson分布等数学模型来优化采集周期，该模型仅仅对粗粒度的时间预测效果较好，而对于细粒度的时间预测效果比较差. 文献[8]提出用一个数学概率模型来模拟网页修改的行为，但是用这种方式与网页行为拟合的准确率和稳定性都不是很高，导致增量数据获取的不及时.

针对上述问题，本文提出了一种基于Storm^[9-11]的在线产品评论信息采集方法. 该方法让传统的网络爬虫^[12]与时下最受欢迎的开源分布式流处理框架——Storm相结合，充分利用Storm分布式、高度容错性、无数据丢失、可扩展性强以及实时处理等优势实现数据的分布式抓取，并在文献[2-3]以及TCP协议滑动窗口的拥塞控制算法的启发下设计了SHHD算法（Simhash^[13]算法和汉明距离）对采集周期进行优化，最终有效地减轻了对网络环境的压力，实现了适应性的增量的在线产品评论信息采集过程.

1 系统框架设计

系统的整体框架如图1所示，主要分为产品id抓取机模块、预处理模块、调度模块、分布式抓取模块、采集周期调整模块、数据存储模块等6个部分. 该系统框架主要由两部分构成：a~d部分主要是定时的收集新增的产品信息，1~5部分主要是对产品的评论信息进行垂直搜索，实时跟踪其更新的评论信息，以增量的方式维护产品的评论信息库. 下面对主要功能模块进行详细介绍.

1.1 产品id抓取模块

该模块是整个采集系统的入口，因为只有先采集到在线产品的信息（主要是产品id），才可以对在线产品的评论信息进行垂直搜索，并实时跟踪其更新的评论信息. 该模块由时间触发服务器控制，周期性地去抓取新的产品信息.

1.2 预处理模块

将抓取到的新的产品id，经过url链接优化器处理生成产品url. 初始化产品的一些采集参数（产品采集周期、产品的当前评论量、产品最近一次评论时间），为配合产品评论数据增量抓取过程奠定基础.

1.3 调度模块

该模块主要是对产品url进行管理调度. 对于新添加的产品url，会将其通过预处理模块处理后直接放入待采集队列；对于已经存在的产品url，在每次增量抓取完成后，首先会通过采集周期调整模块对其采集周期进行调整，然后再将产品url延迟（延迟时间为采集周期）放入待采集队列.

1.4 分布式增量抓取模块

该模块主要是对在线产品的评论信息进行增量抓取，以增量的方式维护产品的评论信息库. 由于该增量爬虫是基于Storm平台，因此，可以实现对产品评论信息的分布式抓取，具体抓取框架如图2所示.

1.5 采集周期调整模块

该模块主要是对产品的评论信息下次采集时间进行调整. 每一次增量采集完产品的评论信息后，并不是直接将产品url重新放入待采集队列，而是通过Simhash算法和汉明距离计算出网页相似度，进而根据网页相似度来调整产品评论信息的采集周期.

1.6 数据存储模块

该模块主要是对采集到的产品的评论信息，以增量的方式进行持久化存储以供后续业务使用. 由于后续业务使用MapReduce对产品评论数据进行处理，这里为了方便处理采用新型的非关系数据库HBase来存储产品的评论信息.

2 关键技术研究与实现

系统中涉及到的关键问题是如何将传统的网络爬虫与Storm框架相结实现产品评论信息的分布式抓取以及如何动态调整产品评论信息的采集周期实现适应性的增量的在线产品评论信息采集过程. 本节会针对这两个问题进行详细介绍.

2.1 基于Storm的分布式数据抓取

在Storm平台中，每个计算任务的逻辑都被封装到Topology^[10]（有Spout和Bolt组件通过数据流连接起来的有向图）对象中. 本文将爬虫的下载、解析以及存储模块分别作为一个处理逻辑单元放在一个Bolt组件中. 为了保证数据不被重复抓取，组件之间采用Fields Grouping^[10]策略，使得相同产品的评论信息采集任务被发送到相同的Task来执行.

2.1.1 爬虫Topology设计

具体设计的爬虫Topology如图3所示. 其中Queue为采集系统的待采集队列；URL_spout组件负责从待采集队列中读取产品ULR到Storm集群；Check_bolt组件负责检查待采集产品是否有新的评论信息产生；Fetch_parse_bolt组件根据上游的Check_bolt组件的检查结果，对产品评论信息进行下载和解析；Save_bolt组件负责将抓取到的产品评论信息进行持久化存储以供后续业务使用.

2.1.2 URL存储元信息

为了配合产品评论信息增量抓取过程，除了要记录每一个产品评论信息的URL地址，还需要同时记录产品当前的评论量、产品最近一次评论时间、采集周期、网页指纹. 本文将这一条记录称之为URL存储元信息. 具体存储格式如表1所示.

2.1.3 URL调度器设计

该模块主要是对产品URL进行管理调度，具体如图4所示. 调度器中的待采集队列使用的分布式内存队列-Beanstalkd，待采集队列中的URL主要来自两部分：对于新抓取到的产品URL，会通过预处理模块处理后直接放入待采集队列；而对于已经存在的产品URL，在每次增量抓取完成后，会通过采集周期调整模块处理后将该URL延迟（延迟时间为采集周期）放入待采集队列.

2.2 动态调整采集周期 2.2.1 Simhash算法计算网页指纹

Simhash算法的主要思想是降维，将高维的特征向量映射成一个f-bit的指纹(fingerprint)，然后通过比较两篇文章的f-bit指纹的Hamming Distance来判断这两篇文章是否重复或者高度近似. 算法伪代码如下：

Algorithm Simhash //计算网页指纹

　　Input doc //doc

　　Output f[i] //网页指纹

　　Begin

　1　 x ₁, x ₂…, x _n =the word of doc

　2　　c[1…m]=0//保存合并的中间结果

　3　　　For i From 1 To n

　4　　　h[i]=hash(x _i )

　5　　　w[i]=weight(h[i])

　6　　　　For j From 1 To m

　7　　　c[j]+=w[j]

　8　　End For

　9　　End For

　10　　For k From 1 To m

　11　　　If c[k]>0 Then

　12　　　　　　　f[i]=1

　13　　　　　Else

　14　　　　　　　f[i]=0

　15　　　　　End If

　16　　　End For

　17　　　return f

　 End

下面具体介绍一下SimHash算法计算网页指纹的过程，这里为了更具体解释SimHash算法，使用示例文本：“苹果手机质量很棒，配置很流畅，非常喜欢”.

(1) 分词.

将抓取的网页信息通过基于DOM树的Deep Web实体抽取技术^[14]处理后作为输入文本，使用IKAnalyzer分词器对其进行分词. 将示例中文本分词后得到：苹果(1)手机(2)质量(3)很(1)棒(1)配置(2)流畅(2)非常(1)喜欢(2)，括号里的数字表示相应特征词的权重.

(2) Hash.

通过Hash算法把上一步的特征词映射成对应的Hash值. 这里为了简单起见，假设特征词对应的Hash值如表2所示：

(3) 加权.

对第2步生成的Hash值，按照特征词的权重生成加权字符串，具体结果如表3所示.

(4) 合并.

将上面特征词生成的加权字符串累加，变成只有一个序列的字符串：-3、-1、1、7、-3.

(5) 降维.

把第4步计算出来的字符串转换成01串. 遍历第4步生成的字符串，如果该位大于0，则输出1，否则输出0，形成最终的网页指纹：00110.

2.2.2 计算汉明距离

根据Simhash算法求出的网页指纹，计算两个网页的汉明距离. 例如网页a的指纹为11001，网页b的指纹为10010，那么HDistance _a–b =3.

2.2.3 调整采集周期

本文设计了一个根据汉明距离来动态调整产品评论信息采集周期的方法SHHD. 由于Simhash算法中向量取64位时比较有效的^[15]，因此本文中的向量也取64位. 根据Google论文中陈述的实验结论^[15]：对于64位的Simhash指纹，在距离为3以内可以认为高度相似.

${t_{n + 1}} = {t_n} + \Delta t.$

(1)

其中，t _n+1 为调整后的采集周期；t _n 为当前的采集周期；∆t为调节因子

受到文献[2-3]以及TCP协议滑动窗口的拥塞控制算法的启发，设计了 ∆t的计算方法，具体如下：

(1) 当汉明距离处于[0, 3]区间时，表明产品评论信息在当前的采集周期内基本没有什么变化，即当前的采集频率大于产品评论信息产生频率，需要将当前的采集周期变大，该阶段可以称之为增长期.

(2) 当汉明距离处于[3，25）区间时，表明当前的采集周期可以满足采集任务，即当前的采集频率和产品评论信息产生频率相符，不需调整采集周期，该阶段可以称之为稳定期. 经过多次实验，发现端点取25可以较好地区分增长期和缩短期.

(3) 当汉明距离处于[25, 60]区间时，表明产品评论信息在当前的采集周期内变化比较大，即当前的采集频率小于产品频率信息产生频率，需要将当前的采集周期减少，该阶段可以称之为缩短期.

由于Simhash算法中向量的维度取64，根据汉明距离的定义可知，两个网页之间的汉明距离取[0, 64]区间某一个整数值. 根据式(1)计算出上一次采集的产品评论信息网页与此次采集的产品评论信息网页的汉明码距离，一般来说，汉明距离越大，表明网页在采集周期内变化比较大，此时需要提高采集频率，缩短采集周期；汉明码距离越小，表明网页在采集周期内变化比较小，可以相应的降低采集频率，增大采集周期.

3 实验与分析

由于该采集系统是基于Storm平台之上，因此，在做实验之前要先部署一个Storm集群. 本实验搭建的Storm集群由3个虚拟节点构成，具体配置如表4所示.

3.1 Storm集群的吞吐量分析

吞吐能力反映的是在单位时间内系统处理数据的规模. 本文分别在单机和Storm集群环境下对某商城的50款手机产品的评论信息进行采集，通过不断的增加集群中节点个数，记录采集完所有产品的评论信息所需要的时间来对比分析各自的吞吐能力. 为了提高实验结果的准确性，每项记录结果都是经过5次测试所得的平均值.

从表5可以看出，Storm集群在处理数据上的加速比与集群中节点的个数趋近线性增加，表明Storm集群有很好可扩展性. 可以预见，当采集需求增大时，可以通过增加Storm集群中节点个数的方法来提高信息的采集速度.

3.2 采集周期变化分析

为了方便测试，本文利用ECSHOP在本地搭建了一个模拟商城进行产品评论信息的抓取测试. 待测试的产品每10 min会自动添加一条评论信息，初始化产品评论信息的采集周期为1 min. 这里选取了产品评论信息对应的网页指纹随时间的变化情况中开始的一部分，具体如表6所示.

网页指纹变化如表7所示. 从表7可以看出，初期产品评论信息的采集周期呈指数方式增长. 在第5次采集时，产品添加一条新的评论信息，此时汉明距离为11，表示现在的采集周期比较合理，可以满足当前的采集需要，故下一次采集周期保持不变；第6次采集过后汉明距离为2，表示在前一个采集周期内产品没有新的评论信息产生，此时需要延长当前的采集周期，故下一次采集周期变为原来的2倍；第7次采集过后汉明距离为27，表示在前一个采集周期内产品新产生的评论信息比较多，此时需要缩短当前的采集周期，故下一次的采集周期变为之前的一半.

采集周期变化图如图5所示. 通过图5可以看出，在第5次采集过后，采集周期便在网页真实的变化周期(10 min)上下浮动，表明这种采集策略可以较好地对产品评论信息产生周期进行适应，有效地降低采集系统对系统资源和网络带宽的消耗，实现了适应性的增量的在线产品评论信息采集过程.

3.3 实验结果对比与分析

采集访问命中率及滞后时间如表8所示.

从表8中可以看出Poisson方法在采集访问命中率上比SHHD方法和SART方法取得更好的效果，但Poisson方法的获取信息的平均滞后时间相对于其他两种方法都要大，说明Poisson算法在优化的网页采集周期较多情况是大于网页实际的更新周期，才使得其采集命中率比较高，自然也就导致采集滞后时间比较大. SHHD方法无论是采集命中率上还是平均滞后时间上都优于SART方法，说明SHHD采集策略可以更好地对产品评论信息产生周期进行适应，尽早地获取产品新的评论信息.

4 结束语

本文提出了一种基于Storm的在线产品评论信息采集方法. 将传统的网络爬虫与时下最受欢迎的开源分布式流处理框架——Storm相结合，实现了产品评论信息的分布式爬取，并通过SHHD算法对采集周期进行优化，最终有效地降低采集系统对系统资源和网络带宽的消耗，实现了适应性的增量的在线产品评论信息采集过程. 实验结果表明，SHHD算法在信息获取的滞后时间上较Poisson、SART等方法具有明显的优势.