论坛首页 Java企业应用论坛

OPIC in Nutch

浏览 2580 次
锁定老帖子 主题:OPIC in Nutch
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-03-15   最后修改:2009-03-25

  庄子曾说:“吾生也有涯,而知也无涯,以有涯随无涯,殆已”。当然,我们不能拿老祖宗这句话作为消极怠工的借口,不过在学习和工作的时候,的确需要要分辨事情的轻重缓急,否则一味蛮干,最终结果只能是--“殆已”。

  突然发现这句话对于网络爬虫也是很有启发意义的,对于浩瀚无边的互联网而言,网络爬虫涉及到页面确实只是冰山一角。因此,如何确定一个页面的重要性,从而在抓取过程中进行合理的调度,以最小的代价(硬件、带宽)获取到最大的利益(数量最多的重要的网页)是设计网络爬虫过程中的一个核心问题。
  一个页面是否重要本来是一个比较主观的问题,见仁见智。但是如果大部分人都认为一个页面是重要的,那么我们大都会相信众人的判断,认为这个页面的确“重要”的——这就是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

C

D

E

0injected

1.0

--

--

--

--

1

1.0*

0.5

0.5

--

--

2

1.0*

0.5*

0.5

0.25

0.25

3

1.0*

0.5*

0.5*

0.25

0.75

4

1.0*

1.25*

0.5*

0.25

0.75*

5

1.0*

1.25*

0.5*

0.25*

0.75*

 

  其实社区中也注意到Nutch在实现OPIC上的问题,也提出了自己的解决方案,具体的内容可以参考Nutch官方wiki上FixingOpicScoring[3]一文。

 

Reference
[1] Abiteboul et al., 2003  http://www2003.org/cdrom/papers/refereed/p007/p7-abiteboul.html
[2] Baeza-Yates, R., Castillo, C., Marin, M. and Rodriguez, A. (2005). Crawling a Country: Better Strategies than Breadth-First for Web Page Ordering. In Proceedings of the Industrial and Practical Experience track of the 14th conference on World Wide Web, pages 864–872, Chiba, Japan. ACM Press.
[3] Fixing the OPIC algorithm in Nutch  http://wiki.apache.org/nutch/FixingOpicScoring

 

论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics