Nutch 二次開發總結 – Nutch查詢分析得出的結論

 Nutch構建好了一種搜尋引擎架構，在此基礎上可以進行二次開發，實現個人規模的搜尋引擎、企業區域網路搜尋引擎、對整個WEB的搜尋引擎等不同規模的搜尋引擎。另外還可以為達到一些特殊的目的建立起的搜尋引擎。不論是建立何種規模的搜尋引擎，一般情況下都需要對其進行二次開發，對原始碼進行相應的功能性修改。通過本次實驗，我們總結出一些二次開發中的重點環節，這裡做一個大致的描述。
1.1 資訊源選擇及規範制定
        對資訊源的選擇可以反映出搜尋引擎的業務範圍：如果選擇某一個網站或者網站群，那麼它是一個企業區域網路搜尋引擎之類的；如果選擇整個網路，那它是一個綜合型的搜尋引擎；如果選擇某一主題類網站或網頁，那麼它是一種垂直搜尋引擎；如果選擇的是部落格，那麼可以稱為部落格搜尋引擎；如果選擇的是某種格式的文檔，那麼可以稱作檔案搜尋引擎。因此，在做二次開發前，明確需求，分析主要的目標網站，選擇作為資訊源。
        Nutch通過制定相應的URL規則來達到對限定的URL進行爬取，即過濾資訊。預設情況下可以在相關的設定檔中進行配置，它用Regex來規範URL。當然，還可以自己編寫相應的外掛程式等來實現所制定的URL規範。
1.2 資訊預先處理
        這裡的資訊預先處理是指將Nutch爬蟲所下載下來的內容轉變為Nutch索引器所能調用的文本。資訊預先處理過程主要涉及到如下內容：
        （1）格式識別並抽取文本。一般情況下，Nutch爬蟲下載下來的文檔是HTML，但是網路上還存在諸多類型的其他文本：txt、doc、pdf、xls、rtf等等，甚至還有多媒體的文檔格式。在進行索引之前，必然從這些下載下來的檔案中抽取出文本資訊，針對不同的格式文檔抽取方式也不同。Nutch預設對HTML、TXT能直接處理，而其他的有些已經實現但並沒有載入。目前有很多開源軟體可以抽取文本資訊，如word文檔的poi、pdf文檔的pdf-reader等等。在二次開發時，需要對相應的文檔格式進行編寫抽取文本工具。
        （2）資訊過濾。這裡的資訊過濾是指從抽取的文本中濾去那些不希望使其存在的常值內容，這個過程也不一定是獨立的，可能會與上一個過程存在相交之處。舉個簡單的執行個體，比如針對某一個網站的某一部分網頁中的部分地區不希望被索引，那麼可以編寫一個相關的外掛程式來實現對這個網站的這類網頁進行過濾，去除這一地區內的內容。
        （3）編碼格式的轉換。網路上的資訊編碼格式五花八門，並不是特別規範。一般情況下，Nutch處理後都能實現編碼的統一，但是有些資訊卻不能很好地被預設程式轉換，這時候就應當對Nutch進行擴充，以實現編碼的轉換。
1.3 索引本土化構建
        以過資訊預先處理後的資訊可以直接為Nutch索引。在索引過程中，需要考慮的因素也有很多。一是中文類語言的分詞問題。這一點在前面實驗中已有詳細的分析並做了一些總結。二是資訊的進一步處理，這一過程是在尋找最能表達原文語義的語詞集合。另外還有一些其他相關技術如詞幹提取、停止詞、本體等等。這個過程是相當重要的一個過程，直接決定了查詢服務的效果。
1.4 定序制定
        定序的制定並不僅僅影響到查詢結果，可以說它貫穿在了整個搜尋引擎的工作過程中。因為能影響定序的因素有很多，比如說與使用者需求的相關性、系統業務需求等，具體的有如語詞在文獻中的詞頻、在整個文獻空間的詞頻、語詞位置等，甚至是資訊時間都會影響到排序。因此在二次開發時，需要根據需求，針對性地制定定序，並把它反映在系統中。
1.5 查詢系統及使用者介面
        Nutch的查詢系統是發布在Tomcat下的，它提供了一種類似於google的查詢介面，並且支援多語言。在實際的二次開發中，並不一定支援多種語言，可針對某一種語言進行改寫。另外還可以對查詢過程進行二次改發，改變它的查詢方式、添加分頁、增加summery等。對於使用者介面介面，則根據實際情況改寫即可。
 
Nutch查詢分析得出的結論
 通過實驗資料，可以得到一些關於Times New Roman">Nutch搜尋引擎的結論：
1、Times New Roman">Nutch預設索引方式是單詞切分，即Times New Roman">N-Grams中Times New Roman">N=1，這種分詞方式較為簡單，但是索引比較大，這一點可以用索引儲存大小來對比：Times New Roman">Nutch索引檔案大小有Times New Roman">85.8MB，而Times New Roman">paoding分詞後索引只有Times New Roman">76.8MB。因此Times New Roman">Nutch預設分詞索引量大，維護相對較難一些，另外還增加了查詢的複雜度。從統計資訊中可以看出，對於中文查詢而言，Times New Roman">Nutch預設檢出結果大，但是大多數結果都不相關；對於英文而言，效果相對較好，檢索也準確，相關性較好。這主要是Times New Roman">Nutch預設查詢時將查詢請求也按單字切分，在文檔中查詢包含這些單字的文檔，而似乎沒有考慮單字之間在位置上是否相鄰。
Times New Roman">        2、Times New Roman">Paoding索引中查詢出來的結果相對較少，但是準備度高，其原因在於Times New Roman">Paoding進行了按字典分詞索引，同時在查詢時也對請求進行了分詞，然後再構建查詢。但是可以看出對於“息管理”卻沒有查詢結果，Times New Roman">Paoding分詞將其分為了“息”Times New Roman">+“管理”，而猜想“息”字可能在索引中並沒有成為一個實際的索引項目，所以沒有相關記錄。那麼Times New Roman">Nutch為什麼不採用一定的策略檢索出相關性最高的呢？這裡我感覺Times New Roman">Nutch的檢索更像布爾檢索，而向量模型似乎沒有起到作用。
Times New Roman">        3、Times New Roman">Nutch預設索引方式和Times New Roman">Paoding索引後對於英文的影響並不大，結果相差不大，而且相對中文而言檢索效果也都較好。
Times New Roman">        4、對於“信管”和“資訊管理”，“諾基亞”與“Times New Roman">Nokia”檢索出的結果不一樣。但是按人的理解而言，每組中的兩個詞大致上應該是同一種含義，那麼是不是應當考慮採用某種機制把同一種含義的詞查詢裡都進行查詢呢？這裡不禁想到Times New Roman">Nutch的外掛程式中有一個Times New Roman">“ontology”外掛程式，它是一種本體外掛程式，這說明Times New Roman">Nutch已經想到了這樣一種機制，只是它並沒有把這進行完善，而本體庫的構建也是需要花費相當精力的。
Times New Roman">        5、另外查詢請求中有“神吹”，它是Times New Roman">BBS上某人的Times New Roman">ID號，對它進行查詢的語義表達感覺有些不明顯。如果對這種Times New Roman">ID也能進行查詢的話，那是不是應當單獨獨立出來成為一種虛擬人物搜尋引擎呢？
Times New Roman">        通過這一點發現，Times New Roman">Nutch對所有的網頁採用的同一種分析器，是不是應該對不同的網站調用不同的分析器以更好的搜集資訊呢？比如說針對某一網站左側邊欄目可以過濾掉，針對另一些網站頭部資訊可以過濾掉等等。於是，我在Times New Roman">Google裡提交了請求“神吹Times New Roman"> site：Times New Roman">bbs.ccnu.edu”發現結果量更大，說明Times New Roman">Google的資料處理能力遠遠越過了Times New Roman">Nutch；另外Times New Roman">Google和Times New Roman">Nutch一樣，將標題簡單的收錄，並沒有過濾掉標題內的都一樣的內容“Times New Roman">powered by discuz!”。對於Times New Roman">Google這樣的綜合性搜尋引擎，可能沒有精力去考慮對每一個網站都去進行這樣的分析，但是如果是利用Times New Roman">Nutch進行垂直搜尋引擎的話，必要的資料過濾主題過濾是需要的