Hadoop视角下的Nutch爬行性能优化-2019年文档

Hadoop视角下的Nutch爬行性能优化

0 引言

Nutch[1]是基于Lucene的开放源码的Web搜索引擎，基于Hadoop实现分布式Web页面的爬行、索引以及检索工作。 詹恒飞等[2]对通过修改Nutch在抓取Web页面时的默认等待时间及抓取行为等方式，达到优化Nutch的目的。NutchWiki[3]分析了Nutch从互联网抓取Web页面时，11种可能影响Nutch抓取速度的因素，并给出了相应的调优策略。文献[2-3]均从Nutch的爬行策略的角度对Nutch性能进行调优，但调优的角度局限在了Nutch爬行的业务逻辑本身。

Intel公司的技术白皮书[4]以实验的方式描述了不同集群环境以及相关参数配置对Hadoop job性能的影响。Impetus公司的技术白皮书[5]分析了Hadoop配置参数将直接影响MapReduce job的执行性能，并分析了相关的调优案例。Hansen等[6]以实验的方式，对Hadoop中典型的MapReduce job进行参数调优分析。文献[4-6]表明Hadoop配置参数可以影响Hadoop job运行性能。但以上文献均定性分析配置参数对job的影响，并没有定量描述job性能和参数的具体对应关系。对Hadoop进行调优仍需要丰富的相关知识和较多的反复参数调优的相关知识。

Herodotou等[7]提出基于代价的（Costbased）Hadoop

MapReduce job运行参数调优工具Starfish，对job进行监测并在job再次运行时通过生成针对当前job的优化参数，达到优化的目的。但Starfish仅作为工具针对一般Hadoop job的单次运行进行参数调优，应用受到局限。

本文立足于Hadoop视角，详细分析Nutch的Hadoop工作流特性，并基于Starfish对Nutch爬行时MapReduce job参数进行调优，从而提高job运行性能，达到优化Nutch爬行性能的效果。

1 Nutch爬行优化方案

Hadoop性能调优工具Starfish无法针对Nutch爬行过程中所产生的连续job进行应用。本文在分析Nutch的MapReduce job的工作流特征后，对Starfish模块进行拆解并与Nutch集成，从而最终达到对Nutch进行优化的目的。 1.1 MapReduce性能优化

Starfish是Herodotou等[8]开发的一个基于代价的用于Hadoop MapReduce job数据监测、job运行模拟以及参数性能调优的开源工具。

对于一个Hadoop MapReduce job，j=〈p，d，r，c〉它的性能可以表示为

perf=F（p，d，r，c）（1）

job优化是指基于特定代价模型F，对MapReduce程序p，在指定的输入数据d和集群资源状况r的条件下，寻找job执行

配置参数c，使得整个Map Reduce job性能perf达到一个近似最优值。

Starfish包含三个功能组件：

1）监测器（Profiler）。监测器基于BTrace[9]在job运行时监测和收集job profile数据。job profile数据包含了一个MapReduce job各阶段的数据流信息及其相应的时间和资源耗费代价。

2）条件假设（Whatif Engine）引擎。Whatif引擎在给定j=〈p，d，r，c〉的情况下，可以预测当job的输入数据大小变为d′，集群子节点数目变为r′以及job运行配置参数变为c′时， job j′=〈p，d′，r′，c′〉的执行时间。

Whatif引擎预测job的执行时间基于Hadoop Performance Model （HPM）[10]。HPM以非常细的粒度对MapReduce job整个工作流的各个阶段进行数学建模。

当已知j=〈p，d，r，c〉的job profile数据以及d′、r′和c′时，Whatif引擎根据HPM中模型生成虚拟job j′=〈p，d′，r′，c′〉的job profile数据，随即将此数据代入调度器模拟器中运行，最后计算出虚拟job j′=〈p，d′，r′，c′〉的运行时间。

3）基于代价的优化器（CostBased Optimizer，CBO）。CBO利用递归随机搜索（Recursive Random Search，RRS）算法[11]以及Whatif引擎完成对指定job配置参数的优化。

CBO利用RRS算法对job的参数进行多组的随机枚举，随后将枚举的每一组参数分别代入Whatif引擎，计算job在当前参数配置下的执行时间，最后选择使得job执行时间最少的一组配置参数作为job参数的优化结果。目前CBO可以支持对11个MapReduce job配置参数的优化。

第10期 周世龙等：Hadoop视角下的Nutch爬行性能优化 计算机应用 第33卷

1.2 Nutch爬行的MapReduce工作流特征 Nutch主要由爬行、索引和查询三个功能组件构成[12]。本文主要对Nutch爬行组件进行研究与性能优化。

Nutch基于Hadoop实现分布式爬行，以Hadoop视角来看，Nutch在爬行过程的各个阶段会向Hadoop提交一系列MapReduce job，这些job具有明显的循环特性以及严格的时序关系，本文称以上特性为Nutch爬行的工作流特性。 Nutch爬行各个阶段产生的job如下：

1） 产生并注入种子URL列表（Inject）。将种子URL格式化，过滤并消除非法URL。设置URL状态为unfetched并注入爬行数据库（CrawlDB）。Inject阶段产生2个job，本文定义为InjectA job和InjectB job。

2） 生成待爬行列表（Generate）。读取CrawlDB中数据，并生成需要从互联网上抓取的链接信息。Generate阶段产生两个2个job，本文定义为GenerateA job和GenerateB job。

3） 抓取Web页面（Fetch）。根据待爬行列表从互联网上抓取链接相对应的Web源页面。Fetch阶段产生1个job，本文定义为Fetch job。

4） 解析抓取内容（Parse）。对抓取的Web页面进行分析处理。Parse阶段产生1个job，本文定义为Parse job。 5） 更新爬行数据库（UpdateDB）。根据Fetch阶段和Parse阶段产生的内容更新CrawlDB中的URL状态信息。此阶段产生1个job，定义为UpdateDB job。

6） 更新链接数据库（Update LinkDB）。Nutch爬行阶段结束后，更新链接数据库并建立索引信息。这一阶段产生2个job，定义为LinkDBA和LinkDBB job。 Nutch爬行时的工作流循环如图1所示。

循环特性 Nutch在对互联网进行爬行时会进行多轮爬行，本文将爬行的轮次称作爬行深度。当Nutch爬行过程中没有到达指定爬行深度时，会不停循环执行2）～5）四个阶段中的5个job。每完成一次循环，则进入下一个爬行深度。当达到指定爬行深度后，Nutch更新链接数据库，完成爬行工作。 时序性 Nutch爬行中所产生的一系列job中，当前一个job结束后，后一个job才会开始。Nutch爬行时产生的job具有严格的时序性。如果Hadoop集群只用来Nutch爬行时，那么在任意时刻，集群中有仅有唯一的Nutch job在运行。 图片

图1 Nutch工作流循环 由Nutch工作流特性可知：

1） Nutch爬行过程会向Hadoop提交的一系列job，由循环特性可知爬行job会重复运行，适用于Starfish的调优原理。 2） Nutch工作流的时序性决定在爬行过程中的任意时刻，集群中仅运行唯一的MapReduce job，因此对job进行监测不会受到来自其他job运行对集群监测环境的影响，使Starfish监测的数据不受干扰。

Nutch工作流的两个特性符合Starfish进行参数优化的条件。本文利用Starfish针对Nutch爬行job进行参数调优，最终达到优化Nutch的目的。

1.3 持续优化模块的设计与实现

持续优化通过对Nutch当前爬行的jobi进行监测，搜集运行时数据（job profile数据）进行暂存。然后使用暂存的job profile数据生成优化后参数，替换新一轮的相同类型的jobi+1的默认配置参数，从而使jobi+1以优化参数运行，完成Nutch的优化。

式（2）：对于特定类型的Nutch job的运行，对job运行时的数据进行监测并暂存，Pi表示jobi的运行时捕获生成的job profile数据。

式（3）、（4）：当此类job在下一轮运行前，根据本次job profile数据生成相应的优化参数替换原有默认参数并运

行，完成job的优化。confi表示基于job的profile数据、job下一次执行的输入数据、集群当前资源配置情况以及MapReduce程序生成的优化后的参数。表1对比了parse job优化前后部分配置参数的变化。

2 优化测量与数据分析

为了测量优化效果，本文通过对Nutch在默认配置下和优化以后爬行相同网页数量所消耗的时间进行对比。 2.1 实验环境

本文的实验平台为基于Xen的虚拟化平台。集群拥有1个主节点，3个从节点。集群节点配置均为：Intel Xeon 2.13GHz双核处理器，内存4GB，网络带宽100Mb/s，每台主机均有独立IP地址，并通过校园网接入教育科研网。

实验爬虫为Nutch1.4版本，实验对比原版以及优化后Nutch的爬行时间。爬行种子URL相同，爬行深度为50轮，每轮爬行一万个Web页面，总共爬行50万个页面。 2.2 持续监测优化实验及其分析 2.2.1 实验数据对比

实验对比Nutch1.4原版和优化版本的爬行时间，测试结果如图3所示。

图3对比了优化前（Def）Nutch的爬行和持续监测优化（Opt）的效果。可以看出，当爬行到50万个页面时，优化后的Nutch比优化前节省了4h左右的时间。因此，Hadoop视角下针对Nutch

生成优化参数的方式进行优化，取得了一定效果，Nutch爬行时间缩短了5%。 图片

图3 默认与优化版本Nutch爬行时间对比 2.2.2 监测代价分析

实验发现，优化虽然取得了一定的效果，但对Nutch爬行时间的减少并不是特别理想。

由于Starfish基于BTrace来完成对job的动态监测。BTrace动态拦截job在运行时的Java字节码，并向其注入额外的用于完成监测功能的字节码。而动态地对Java字节码进行拦截和注入给job执行带来额外的负荷，影响优化的效果。 2.3 间隔监测优化 2.3.1 间隔监测设计

由于BTrace进行动态监测会导致爬行性能的下降，因此本文尝试降低监测Nutch的频度，在工作流循环中的后续相同类型的job均使用前几轮监测的数据结果进行优化参数的生成。 间隔监测持续优化算法伪代码如下：

本文来源：https://www.bwwdw.com/article/kl4x.html