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

最新推荐文章于 2017-11-06 19:09:53 发布

zfrong

最新推荐文章于 2017-11-06 19:09:53 发布

阅读量885

点赞数

分类专栏： NUTCH Hadoop /HDFS/ZFS 文章标签：工作 lucene plugins 存储 database parsing

Hadoop /HDFS/ZFS 同时被 2 个专栏收录

20 篇文章 0 订阅

订阅专栏

NUTCH

15 篇文章 0 订阅

订阅专栏

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