Nutch搜索引擎
背景介绍
Nutch这个框架用于构建立可扩展的网络爬虫(crawler)和搜索引擎。它是Apache软件基金会(Apache Software Foundation)的一个项目，Lucene的一个子项目，遵循 Apache 许可(2.0)。
我们并不想多么深入地细究网络爬虫的知识一这个案例研究的目的是展示Hadoop 是如何实现捜索引擎各种典型、复杂处理任务的。感兴趣的用户可以在Nutch官方主页找到项目相关的大量专门信息。可以这样说， 为了创建和维护一个捜索引擎，必须要有下面的子系统。
网页数据库
这个数据库跟踪网络爬虫要抓取的所有网页和它们的状态，如上一次访问的时 间，它的抓取状态信息，刷新间隔，内容校验和，等等。用Nutch专用名词 来说，这个数据库称为CrawlDb。
爬取网页清单
网络爬虫定期刷新其web视图信息，然后下载新的网页(以前没有抓取的)或刷 新它们认为已经过期的网页。这些准备爬取的候选网页清单，Nutch称为 fetchlist。
原始网页数据
网页内容从远程网站下载，以原始的未解释的格式在本地存储成字节数组。 Nutch称这种数据为page content。
解析的网页数据
网页内容用适合的解析器进行解析——Nutch为各种流行格式的文档提供了解 析器，如HTML，PDF, Open Office和Microsoft Office,RSS等。
链接图数据库
对于计算基于链接(link)的网页排序(Page rank)值来说，如PageRank,这个数 据库是必须的。对于Nutch记录的每一个URL,它会包含一串指向它的其他 的口&值以及这些URL关联的锚文本(在HTML文件的锚文 本元素中得到）。这个数据库称为LinkDb。
全文检索索引
这是一个传统的倒排索引，基于搜集到的所有网页元数据与抽取到的纯文本内 容而建立。它是使用卓越的Lucene库来实现的。
前面我们简略地提到Hadoop作为一个组件在Nutch系统上得到实现，试图用它提 髙Nutch系统的可扩展性以及解决那些由集中式数据处理模型引起的一系列瓶颈问 题。Nutch也是第一个移植到Hadoop架构之上的公开的概念证明应用，后来它成 为Hadoop的一部分，并且事实证明，把Nutch算法和数据结构移植到Hadoop架 构所需的工作量惊人地少。这一特点有可能激励大家把Hadoop的开发作为一个子 项目，为除Nutch之外的其他应用提供可重用的架构。
目前，几乎所有的Nutch工具都通过运行一个或多个MapReduce作业来处理数据。
数据结构
在Nutch系统中维护着几种主要的数据结构，它们都利用Hadoop I/O类和数据格 式来构造。根据数据使用目的和数据创建之后的访问方式，.这些数据可以使用 Hadoop的映射(map)文件或顺序(sequence)文件进行保存。
因为数据是MapRedUce的作业产生和处理的，而这一过程反过来又会执行几个 map和reduce任务，所以它的硬盘存储格式符合常用的Hadoop输出格式，即MapFileOutputFormat 和 SequenceFileOutputFormat 两种格式。精确地说， 数据被保存成几个map文件或顺序文件，而文件数和创建数据作业中的reduce任 务数相等。为了简单，在下面几节的介绍中，我们忽略格式差异。
CrawlDb
CrawlDb存储毎个URL的当前状态信息，存储文件是map文件，形式是<url, CrawlDatum>,这里键使用文本格式，值使用Nutch特定的CrawlDatum类型(它 实现Writable接口）。为了对这些记录提供快速的随机访问能力(用户想在CrawlDb里面检查个人记录信 息的时候)，这些数据被存储成map文件而不是顺序文件。
CrawlDb最初是通过Injector工具创建的，它只是简单地把初始URL列表(种子列 表)的纯文本文件转换成一个map文件，格式如前所述。接着，用爬取和解析的网 页信息来对它做更新。稍后将对此进行详细介绍。
LinkDb
这个数据库为Nutch记载的毎个URL存储“入链接”（incoming link)信息。它采用 map文件格式<url,Inlinks>进行存储，其中Inlinks是URL列表和锚文本数 据。注意，这些信息在网页数据收集阶段并不是立刻可以得到的，但是可以获取反 向信息，就是这个页面的“出链接”(outlink)信息。反向链接的信息获取是通过一 个MapReduce作业完成的，相关详情可参见后文。
分段
在Nutch定义中，“分段”(segment)指的是爬取和解析URL组。图16-5展示了分 段的创建和处理过程。
一个分段（文件系统里的一个目录）包含以下几个部分（它们只不过是一些包含 MapFileOutputFormat 或 SequenceFileOutputFormat 格式数据的子目录）。
content
content包含下载页面的原始数据，存储为map文件，格式是<url, Content>。为了展示缓存页的视图，这里使用map文件存储数据，因为Nutch需要对文件做快速随机的访问。
crawl_generate
它包含将要爬取的URL列表以及从CrawlDb取到的与这些URL页相关的当 前状态信息，对应的顺序文件的格式<url, CrawlDatum>。这个数据采用顺 序文件存储，原因有二：第一，这些数据是按顺序逐个处理的，第二，map文 件排序键值的不变性不能满足我们的要求。我们需要尽量分散属于同一台主机 的URL,以此减少毎个目标主机的负载，这就意味着记录信息基本上是随机 排列的。
图16-5.分割
crawl_fetch
它包含数据爬取的状态信息，即爬取是否成功，响应码是什么，等等。这个数 据存储在map文件里，格式是<url, CrawlDatum>。
crawl_parse
毎个成功爬取并解析的页面的出链接列表都保存在这里，因此Nutch通过学习 新的URL可以扩展它的爬取前端页。
parse_data
解析过程中收集的元数据，其中还有页面的出链接列表。这些信息对 于后面介绍的建立反向图(入链接——ink)是相当关键的。
parse_text
页面的纯文本内容适合用Lucene进行索引。这些纯文本存储成map文件，格 式是
