突 然发现这句话对于网络爬虫也是很有启发意义的，对于浩瀚无边的互联网而言，网络爬虫涉及到页面确实只是冰山一角。因此，如何确定一个页面的重要性，从而在 抓取过程中进行合理的调度，以最小的代价（硬件、带宽）获取到最大的利益（数量最多的重要的网页）是设计网络爬虫过程中的一个核心问题。
一个页面是否重要本来是一个比较主观的问题，见仁见智。但是如果大部分人都认为一个页面是重要的，那么我们大都会相信众人的判断，认为这个页面的确“重 要”的——这就是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当前的Cash，H表示在计算 过程中页面i累计收到的cash的总数。
OPIC代码：
- OPIC:
- On-line Page Importance Computation
-
- for each i let C := 1/n ;
- for each i let H := 0 ;
- let G:=0 ;
- do forever
- begin
- choose some node i ;
- %% each node is selected
- %% infinitely often
-
- H += C;
- %% single disk access per page
-
- for each child j of i,
- do C[j] += C/out;
- %% Distribution of cash
- %% depends on L
-
- G += C;
- C := 0 ;
- end
宋体"> Nutch使用了OPIC作为默认的URL调度策略，但是当前版本（0.9）的OPIC实现与Abiteboul在论文提出的OPIC并不完全相同，具体表现为：
宋体"> 1. Nutch中并没有区分C和H，使用score一个变量记录页面累积的分数，在分配过程中也是将这个累积的分数全部平均分配给子页面，分配完毕后分数也并不清零。
宋体"> 2. Nutch中并没有virtual root page，也就是说叶子页面（即没有outlink的页面）的分数将会丢失。
宋体"> Nutch分数计算功能是通过插件的形式提供的，用户可以通过新增插件的方式改变Nutch积分方式。Nutch提供了一个计算分数的接口 ScoringFilter，完成计算分数功能的类通过实现该接口以影响Nutch分数的计算方式，其默认的OPIC分数计算方法由类 OPICScoringFilter 提供。此外，参与计算分数的类还有 ScoringFilters，ParseOutputFormat。其中 ScoringFilters 负责将各个计分插件加载到系统中，并实现链式计分的过程；而ParseOutputFormat 在解析结果输出之前，将页面的分数分配到该页面的各个子页面中，使得Nutch的更新模块可以使用这些数据更新CrawlDB数据库。
