Nutch爬虫工作流程及文件格式详细分析

Nutch爬虫工作流程及文件格式详细分析





Nutch

主要分为两个部分：爬虫
crawler

和查询
searcher

。
Crawler

主要用于从网络上抓取网页并为这些网页建立索引。
Searcher

主要利用这些索引检索用户的查找关键词来产生查找结果。两者之间的接口是索引，所以除去索引部分，两者之间的耦合度很低。







Crawler

和
Searcher

两部分尽量分开的目的主要是为了使两部分可以分布式配置在硬件平台上，例如将
Crawler

和
Searcher

分别放在两个主机上，这样可以提升性能。





爬虫，

Crawler


：






Crawler

的重点在两个方面，
Crawler

的工作流程和涉及的数据文件的格式和含义。数据文件主要包括三类，分别是
web database

，一系列的
segment

加上
index
，三者的物理文件分别存储在爬行结果目录下的
db

目录下
webdb

子文件夹内，
segments

文件夹和
index
文件夹。那么三者分别存储的信息是什么呢？





Web database

，也叫
WebDB

，其中存储的是爬虫所抓取网页之间的链接结构信息，它只在爬虫
Crawler

工作中使用而和
Searcher

的工作没有任何关系。
WebDB

内存储了两种实体的信息：
page

和
link

。
Page

实体通过描述网络上一个网页的特征信息来表征一个实际的网页，因为网页有很多个需要描述，
WebDB

中通过网页的
URL

和网页内容的
MD5

两种索引方法对这些网页实体进行了索引。
Page

实体描述的网页特征主要包括网页内的
link

数目，抓取此网页的时间等相关抓取信息，对此网页的重要度评分等。同样的，
Link

实体描述的是两个
page

实体之间的链接关系。
WebDB

构成了一个所抓取网页的链接结构图，这个图中
Page

实体是图的结点，而
Link

实体则代表图的边。





一次爬行会产生很多个
segment

，每个
segment

内存储的是爬虫
Crawler

在单独一次抓取循环中抓到的网页以及这些网页的索引。
Crawler

爬行时会根据
WebDB

中的
link

关系按照一定的爬行策略生成每次抓取循环所需的
fetchlist

，然后
Fetcher

通过
fetchlist

中的
URLs

抓取这些网页并索引，然后将其存入
segment

。
Segment

是有时限的，当这些网页被
Crawler

重新抓取后，先前抓取产生的
segment

就作废了。在存储中。
Segment

文件夹是以产生时间命名的，方便我们删除作废的
segments

以节省存储空间。





Index

是
Crawler

抓取的所有网页的索引，它是通过对所有单个
segment

中的索引进行合并处理所得的。
Nutch

利用
Lucene

技术进行索引，所以
Lucene

中对索引进行操作的接口对
Nutch

中的
index
同样有效。但是需要注意的是，
Lucene

中的
segment

和
Nutch

中的不同，
Lucene

中的
segment

是索引
index
的一部分，但是
Nutch

中的
segment

只是
WebDB

中各个部分网页的内容和索引，最后通过其生成的
index
跟这些
segment

已经毫无关系了。





Crawler


工作流程：






在分析了
Crawler

工作中设计的文件之后，接下来我们研究一下
Crawler

的抓取流程以及这些文件在抓取中扮演的角色。
Crawler

的工作原理主要是：首先
Crawler

根据
WebDB

生成一个待抓取网页的
URL

集合叫做
Fetchlist

，接着下载线程
Fetcher

开始根据
Fetchlist

将网页抓取回来，如果下载线程有很多个，那么就生成很多个
Fetchlist

，也就是一个
Fetcher

对应一个
Fetchlist

。然后
Crawler

根据抓取回来的网页
WebDB

进行更新，根据更新后的
WebDB

生成新的
Fetchlist

，里面是未抓取的或者新发现的
URLs

，然后下一轮抓取循环重新开始。这个循环过程可以叫做“产生
/

抓取
/

更新”循环。





指向同一个主机上
Web

资源的
URLs

通常被分配到同一个
Fetchlist

中，这样的话防止过多的
Fetchers

对一个主机同时进行抓取造成主机负担过重。另外
Nutch

遵守
Robots Exclusion Protocol

，网站可以通过自定义
Robots.txt

控制
Crawler

的抓取。

在
Nutch

中，
Crawler

操作的实现是通过一系列子操作的实现来完成的。这些子操作
Nutch

都提供了子命令行可以单独进行调用。下面就是这些子操作的功能描述以及命令行，命令行在括号中。





1.


创建一个新的
WebDb (

admin db -create

).



2.


将抓取起始
URLs

写入
WebDB

中
(

inject

).



3.


根据
WebDB

生成
fetchlist

并写入相应的
segment(

generate

).



4.


根据
fetchlist

中的
URL

抓取网页
(

fetch

).



5.


根据抓取网页更新
WebDb (

updatedb

).



6.


循环进行
3

－
5

步直至预先设定的抓取深度。



7.


根据
WebDB

得到的网页评分和
links

更新
segments (

updatesegs

).



8.


对所抓取的网页进行索引
(

index

).



9.


在索引中丢弃有重复内容的网页和重复的
URLs (

dedup

).



10.


将
segments

中的索引进行合并生成用于检索的最终
index(

merge

).







Crawler

详细工作流程是：在创建一个
WebDB

之后
(

步骤
1),

“产生
/

抓取
/

更新”循环
(

步骤
3

－
6)

根据一些种子
URLs

开始启动。当这个循环彻底结束，
Crawler

根据抓取中生成的
segments

创建索引（步骤
7

－
10

）。在进行重复
URLs

清除（步骤
9

）之前，每个
segment

的索引都是独立的（步骤
8

）。最终，各个独立的
segment

索引被合并为一个最终的索引
index
（步骤
10

）。





其中有一个细节问题，
Dedup

操作主要用于清除
segment

索引中的重复
URLs

，但是我们知道，在
WebDB

中是不允许重复的
URL

存在的，那么为什么这里还要进行清除呢？原因在于抓取的更新。比方说一个月之前你抓取过这些网页，一个月后为了更新进行了重新抓取，那么旧的
segment

在没有删除之前仍然起作用，这个时候就需要在新旧
segment

之间进行除重。





另外这些子操作在第一次进行
Crawler

运行时可能并不用到，它们主要用于接下来的索引更新，增量搜索等操作的实现。这些在以后的文章中我再详细讲。





个性化设置：






Nutch

中的所有配置文件都放置在总目录下的
conf

子文件夹中，最基本的配置文件是
conf/nutch-default.xml

。这个文件中定义了
Nutch

的所有必要设置以及一些默认值，它是不可以被修改的。如果你想进行个性化设置，你需要在
conf/nutch-site.xml

进行设置，它会对默认设置进行屏蔽。





Nutch

考虑了其可扩展性，你可以自定义插件
plugins

来定制自己的服务，一些
plugins

存放于
plugins

子文件夹。
Nutch

的网页解析与索引功能是通过插件形式进行实现的，例如，对
HTML

文件的解析与索引是通过
HTML document parsing plugin

,

parse-html

实现的。所以你完全可以自定义各种解析插件然后对配置文件进行修改，然后你就可以抓取并索引各种类型的文件了。

Crawler


运行实例分析






下一篇文章里，我将利用
Nutch

爬虫对一个已知结构和内容的实验网络进行爬行和抓取，对抓取的过程以及结果文件进行内容分析来更进一步地了解
Nutch

爬虫。





备注

参考文章： http://today.java.net/pub/a/today/2006/01/10/introduction-to-nutch-1.html
本文章为原创，如要转载请务必注明本文章出处 http://blog.donews.com/52se
。