Nutch 是一個開源Java 實現(xiàn)的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具。包括全文搜索和Web爬蟲。

盡管Web搜索是漫游Internet的基本要求， 但是現(xiàn)有web搜索引擎的數(shù)目卻在下降。并且這很有可能進一步演變成為一個公司壟斷了幾乎所有的web搜索為其謀取商業(yè)利益。這顯然 不利于廣大Internet用戶。

Nutch為我們提供了這樣一個不同的選擇。相對于那些商用的搜索引擎， Nutch作為開放源代碼搜索引擎將會更加透明，從而更值得大家信賴。 現(xiàn)在所有主要的搜索引擎都采用私有的排序算法， 而不會解釋為什么一個網(wǎng)頁會排在一個特定的位置。除此之外, 有的搜索引擎依照網(wǎng)站所付的 費用， 而不是根據(jù)它們本身的價值進行排序。與它們不同，Nucth沒有什么需要隱瞞。也沒有 動機去扭曲搜索的結果， Nutch將盡自己***的努力為用戶提供***的搜索結果。

Nutch目前***的版本為version v2.2.1。

Nutch 致力于讓每個人能很容易, 同時花費很少就可以配置世界***的Web搜索引擎. 為了完成這一宏偉的目標, Nutch必須能夠做到:

1. 每個月取幾十億網(wǎng)頁
2. 為這些網(wǎng)頁維護一個索引
3. 對索引文件進行每秒上千次的搜索
4. 提供高質(zhì)量的搜索結果

組成

爬蟲crawler和查詢searcher。Crawler主要用于從網(wǎng)絡上抓取網(wǎng)頁并為這些網(wǎng)頁建立索引。Searcher主要利用這些索引檢索用戶的查找關鍵詞來產(chǎn)生查找結果。兩者之間的接口是索引，所以除去索引部分，兩者之間的耦合度很低。

Crawler和Searcher兩部分盡量分開的目的主要是為了使兩部分可以分布式配置在硬件平臺上，例如將Crawler和Searcher分別放在兩個主機上，這樣可以提升性能。

爬蟲

Crawler的重點在兩個方面，Crawler的工作流程和涉及的數(shù)據(jù)文件的格式和含義。數(shù)據(jù)文件主要包括三類，分別是web database，一系列的segment加上index，三者的物理文件分別存儲在爬行結果目錄下的db目錄下webdb子文件夾內(nèi)，segments文件夾和index文件夾。那么三者分別存儲的信息是什么呢？

一次爬行會產(chǎn)生很多個segment，每個segment內(nèi)存儲的是爬蟲Crawler在單獨一次抓取循環(huán)中抓到的網(wǎng)頁以及這些網(wǎng)頁的索引。Crawler爬行時會根據(jù)WebDB中的link關系按照一定的爬行策略生成每次抓取循環(huán)所需的fetchlist，然后Fetcher通過fetchlist中的URLs抓取這些網(wǎng)頁并索引，然后將其存入segment。Segment是有時限的，當這些網(wǎng)頁被Crawler重新抓取后，先前抓取產(chǎn)生的segment就作廢了。在存儲中。Segment文件夾是以產(chǎn)生時間命名的，方便我們刪除作廢的segments以節(jié)省存儲空間。

Index是Crawler抓取的所有網(wǎng)頁的索引，它是通過對所有單個segment中的索引進行合并處理所得的。Nutch利用Lucene技術進行索引，所以Lucene中對索引進行操作的接口對Nutch中的index同樣有效。但是需要注意的是，Lucene中的segment和Nutch中的不同，Lucene中的segment是索引index的一部分，但是Nutch中的segment只是WebDB中各個部分網(wǎng)頁的內(nèi)容和索引，***通過其生成的index跟這些segment已經(jīng)毫無關系了。

Web database，也叫WebDB，其中存儲的是爬蟲所抓取網(wǎng)頁之間的鏈接結構信息，它只在爬蟲Crawler工作中使用而和Searcher的工作沒有任何關系。WebDB內(nèi)存儲了兩種實體的信息：page和link。Page實體通過描述網(wǎng)絡上一個網(wǎng)頁的特征信息來表征一個實際的網(wǎng)頁，因為網(wǎng)頁有很多個需要描述，WebDB中通過網(wǎng)頁的URL和網(wǎng)頁內(nèi)容的MD5兩種索引方法對這些網(wǎng)頁實體進行了索引。Page實體描述的網(wǎng)頁特征主要包括網(wǎng)頁內(nèi)的link數(shù)目，抓取此網(wǎng)頁的時間等相關抓取信息，對此網(wǎng)頁的重要度評分等。同樣的，Link實體描述的是兩個page實體之間的鏈接關系。WebDB構成了一個所抓取網(wǎng)頁的鏈接結構圖，這個圖中Page實體是圖的結點，而Link實體則代表圖的邊。

在創(chuàng)建一個WebDB之后(步驟1), “產(chǎn)生/抓取/更新”循環(huán)(步驟3－6)根據(jù)一些種子URLs開始啟動。當這個循環(huán)徹底結束，Crawler根據(jù)抓取中生成的segments創(chuàng)建索引（步驟7－10）。在進行重復URLs清除（步驟9）之前，每個segment的索引都是獨立的（步驟8）。最終，各個獨立的segment索引被合并為一個最終的索引index（步驟10）。

其中有一個細節(jié)問題，Dedup操作主要用于清除segment索引中的重復URLs，但是我們知道，在WebDB中是不允許重復的URL存在的，那么為什么這里還要進行清除呢？原因在于抓取的更新。比方說一個月之前你抓取過這些網(wǎng)頁，一個月后為了更新進行了重新抓取，那么舊的segment在沒有刪除之前仍然起作用，這個時候就需要在新舊segment之間進行除重。

Nutch和Lucene

Nutch是基于Lucene的。Lucene為Nutch提供了文本索引和搜索的API。

一個常見的問題是：我應該使用Lucene還是Nutch？

最簡單的回答是：如果你不需要抓取數(shù)據(jù)的話，應該使用Lucene。

常見的應用場合是：你有數(shù)據(jù)源，需要為這些數(shù)據(jù)提供一個搜索頁面。在這種情況下，***的方式是直接從數(shù)據(jù)庫中取出數(shù)據(jù)并用Lucene API 建立索引。

在你沒有本地數(shù)據(jù)源，或者數(shù)據(jù)源非常分散的情況下，應該使用Nutch。

在分析了Crawler工作中設計的文件之后，接下來我們研究Crawler的抓取流程以及這些文件在抓取中扮演的角色。Crawler的工作原理：首先Crawler根據(jù)WebDB生成一個待抓取網(wǎng)頁的URL集合叫做Fetchlist，接著下載線程Fetcher根據(jù)Fetchlist將網(wǎng)頁抓取回來，如果下載線程有很多個，那么就生成很多個Fetchlist，也就是一個Fetcher對應一個Fetchlist。然后Crawler用抓取回來的網(wǎng)頁更新WebDB，根據(jù)更新后的WebDB生成新的Fetchlist，里面是未抓取的或者新發(fā)現(xiàn)的URLs，然后下一輪抓取循環(huán)重新開始。這個循環(huán)過程可以叫做“產(chǎn)生/抓取/更新”循環(huán)。

指向同一個主機上Web資源的URLs通常被分配到同一個Fetchlist中，這可防止過多的Fetchers對一個主機同時進行抓取造成主機負擔過重。另外Nutch遵守Robots Exclusion Protocol，網(wǎng)站可以通過自定義Robots.txt控制Crawler的抓取。

在Nutch中，Crawler操作的實現(xiàn)是通過一系列子操作的實現(xiàn)來完成的。這些子操作Nutch都提供了子命令行可以單獨進行調(diào)用。下面就是這些子操作的功能描述以及命令行，命令行在括號中。

1. 創(chuàng)建一個新的WebDb (admin db -create).

2. 將抓取起始URLs寫入WebDB中 (inject).

3. 根據(jù)WebDB生成fetchlist并寫入相應的segment(generate).

4. 根據(jù)fetchlist中的URL抓取網(wǎng)頁 (fetch).

5. 根據(jù)抓取網(wǎng)頁更新WebDb (updatedb).

6. 循環(huán)進行3－5步直至預先設定的抓取深度。

7. 根據(jù)WebDB得到的網(wǎng)頁評分和links更新segments (updatesegs).

8. 對所抓取的網(wǎng)頁進行索引(index).

9. 在索引中丟棄有重復內(nèi)容的網(wǎng)頁和重復的URLs (dedup).

10. 將segments中的索引進行合并生成用于檢索的最終index(merge).

原文出自：http://blog.csdn.net/u012965373/article/details/41113441