heritrx增量抓取

转载地址：http://blog.youkuaiyun.com/historyasamirror/article/details/6706174

虽然打着Heritrix的名头，但本文更多的还是谈谈增量抓取的基本思想，Heritrix只是正好被用来做为例子。

如果你不是随便写个爬虫抓着玩，那么一定会碰到一个问题，就是增量抓取。不管是百度，google这样的广泛搜索引擎，还是现在很火的垂直搜索，增量抓取一定都是做爬虫的最需要考虑的问题。
之所以需要增量抓取的原因，有两个：
1. 网站总是在不断的发生着变化。或者添加了新的网页，或者旧的网页内容发生了变化；
2. 并没有机制能够将网站发生的变化主动的推送给搜索引擎，如果有这种机制，一切都将变得简单，也就不需要爬虫去做增量抓取；

增量抓取的目的就在于尽可能快的抓取到变化了的网页（包括新增的和发生变化的旧的网页）：
之所以需要尽可能的快，是因为这直接关系到搜索引擎提供的信息的时效性。假设一个网页发生了变化，而爬虫一个月之后才重新重新抓取，那么意味着搜索引擎内关于这个网页的信息在这一个月之内都是过时的；
之所以是尽可能的快，是因为爬虫的增量抓取这种方式永远都不可能保证一定能够及时发现变化的网页。哪怕重复抓取的频率很快，也不能避免网页在两次抓取之间发生了变化。如果希望达到实时性，就只能通过接口调用。比如google为了实时搜索twitter的信息，购买了twitter的数据，twitter只要产生新的数据就会推送给google；再比如我之前听过一个“去哪儿”的讲座，为了保证搜索到的机票价格一定是最及时的，在每次搜索的时候，都实时的调用航空公司的接口实时的获取机票价格，这是一个典型的牺牲服务的响应速度而保证信息时效性的例子（几年前听说的，不确定还是这么做...）；

根据前述，构建一个增量抓取的爬虫主要有两个要素：
1. 如何能够尽可能快；
2. 怎样判断网页发生了变化；

先说第一点。如果是抓取特定的网站，那么可以引入一些先验知识。比如，网站的索引页总是能够关联上哪些新增加的网页，一个网站的变化频率也可以简单的估计。通过引入这些知识，爬虫可以很容易的很快的找到那些可能发生变化的网页。而对于像百度这样的搜索引擎，因为需要抓取所有的网页，它不太可能去一一分辨每个网站的索引页，这种情况下，就必须有动态学习和调节网站抓取频率的机制，对于那些变化快的网站/网页，重复抓取的频率就应该高，而那些几乎不变化的网页，重复抓取的间隔就可以很长。
关于第二点，看上去似乎很简单，只需要字符串比较一下新的网页和上次抓取的版本是否发生了变化。但是在很多情况下，网页的字符可能发生了微小的变化，但并不意味着网页的实质内容发生了变化。举例来说，网页上有个地方写着系统的当前时间，这意味着每次查看该网页时间都会变，但是，网页的真正内容可能从未发生过变化。如何过滤这些信息而能够判断网页内容的真实变化并不是一件容易的事。

说了这么多干巴巴的东西，还是看看Heritrix怎么做的吧。
（以下的内容需要对Heritrix的架构和模块有一个基本的了解）

为了实现Heritrix的增量抓取功能，需要在Processing Chains中添加几个新的组件，如下图：

在Extractor Processing Chain的最前端，加入一个新的模块：HttpContentDigest，这个模块会对有Fetch Processing Chain抓取下来的网页产生一个摘要，这个摘要就是为了判断网页是否发生了变化，这个摘要的产生必须要考虑到我们之前提到过的网页的细节发生变化，但是内容无变化的这种情况；

HttpContentDigest之后会有一个ChangeEvaluator的模块，这个模块根据HttpContentDigest产生的新的网页摘要以及上一次抓取生成的旧的摘要的对比，判断网页是否发生了变化；

在Post Processing Chain中会加入一个WaitEvaluator，这个模块的作用，是根据ChangeEvaluator的结果动态的调节该网页的抓取频率，并给出该网页下一次的抓取时间。还是举例说，比如这个url之前的抓取频率是1天，意味着1天重复抓取一次。如果ChangeEvaluator判断本次抓取网页的内容发生了变化，那么WaitEvaluator会将该url的抓取频率设置为 1天 / 2 = 12小时，意味着它的抓取频率需要更快；如果网页内容没有发生变化，那么新的抓取间隔会被设置为 1天 * 2 = 2天。

其本质就是根据网页抓取后内容是否变化来动态调节抓取频率。

此外，Heritrix的Froniter也需要改成AdaptiveRevisitFrontier。Heritrix默认的Froniter内部是一个FIFO的队列，而AdaptiveRevisitFrontier内部则是一个优先级队列。它根据WaitEvaluator设定的wait time（也就是抓取间隔）来排列url，判断哪个url应该被调度。

（注：AdaptiveRevisitFrontier是一个实验性质的Froniter： EXPERIMENTAL Frontier that will repeatedly visit all encountered URIs. Wait time between visits is configurable and is determined by seperate Processor(s). See WaitEvaluators See documentation for ARFrontier limitations.）