突 然发现这句话对于网络爬虫也是很有启发意义的,对于浩瀚无边的互联网而言,网络爬虫涉及到页面确实只是冰山一角。因此,如何确定一个页面的重要性,从而在 抓取过程中进行合理的调度,以最小的代价(硬件、带宽)获取到最大的利益(数量最多的重要的网页)是设计网络爬虫过程中的一个核心问题。
一个页面是否重要本来是一个比较主观的问题,见仁见智。但是如果大部分人都认为一个页面是重要的,那么我们大都会相信众人的判断,认为这个页面的确“重 要”的——这就是Google的PageRank算法的核心思想。不过在具体PageRank中,这个判断的过程是采用网页间的超链接来实现的。 PageRank成就了Google的辉煌,自然有它的过人之处,不过PageRank计算对象是所有“已经抓取下来”的网页,该算法通过这些网页的相互 连接关系以迭代的方式计算出各个网页的重要性——页面的PageRank。也就是说,我们在计算PageRank的过程中,是不会有新的页面加入的,我们 将这种计算方式称为“离线”(off-line)的计算方式。PageRank能够很好地反应出已有页面间的相对重要性,因此十分适合于查询结果的排序。 但是,PageRank是一种离线的计算方式,在一次计算过程中不能加入新的页面,而且计算过程是一个迭代过程,需要较长的计算时间,因此并不适合于网络 爬虫的URL调度,动态决定URL的抓取顺序。
针对这个问题,大家提出了很多解决方案[1]。其中,Abiteboul (Abiteboul et al., 2003)[2] 提出了一种基于OPIC (On-line Page Importance Computation)算法的抓取策略.在OPIC中,每一个页面都有一个初始的"cash” 。在抓取的过程中,这些"cash"将会平均地分配给该页面指向的页面,这个分配过程是一次完成的。基于OPIC的网络爬虫在抓取过程中将以待抓取页面累 积的"cash"的多少为依据,优先抓取"cash"数量最多的页面。OPIC算法如下所示,其中C[i]表示页面i当前的Cash,H[i]表示在计算 过程中页面i累计收到的cash的总数。
- OPIC:
- On-line Page Importance Computation
- for each i let C[i] := 1/n ;
- for each i let H[i] := 0 ;
- let G:=0 ;
- do forever
- begin
- choose some node i ;
- %% each node is selected
- %% infinitely often
- H[i] += C[i];
- %% single disk access per page
- for each child j of i,
- do C[j] += C[i]/out[i];
- %% Distribution of cash
- %% depends on L
- G += C[i];
- C[i] := 0 ;
- end
Nutch使用了OPIC作为默认的URL调度策略,但是当前版本(0.9)的OPIC实现与Abiteboul在论文提出的OPIC并不完全相同,具体表现为:
1. Nutch中并没有区分C[i]和H[i],使用score一个变量记录页面累积的分数,在分配过程中也是将这个累积的分数全部平均分配给子页面,分配完毕后分数也并不清零。
2. Nutch中并没有virtual root page,也就是说叶子页面(即没有outlink的页面)的分数将会丢失。
Nutch分数计算功能是通过插件的形式提供的,用户可以通过新增插件的方式改变Nutch积分方式。Nutch提供了一个计算分数的接口 ScoringFilter,完成计算分数功能的类通过实现该接口以影响Nutch分数的计算方式,其默认的OPIC分数计算方法由类 OPICScoringFilter 提供。此外,参与计算分数的类还有 ScoringFilters,ParseOutputFormat。其中 ScoringFilters 负责将各个计分插件加载到系统中,并实现链式计分的过程;而ParseOutputFormat 在解析结果输出之前,将页面的分数分配到该页面的各个子页面中,使得Nutch的更新模块可以使用这些数据更新CrawlDB数据库。
为了能够形象地展示Nutch的URL调度过程,我构建了一个微型的站点,站点只包含了五张网页,其拓扑结构如下图所示。
下面表格展示了Nutch的抓取流程,表格中,每一行中被粗体标注数字对应的URL为被调度器选中的URL,将在下一轮被抓取;“*”表示该网页已被抓取;“--”表示该网页尚未被系统获知。
|
A |
B |
< |