Nutch 二次开发总结 - Nutch查询分析得出的结论

 Nutch构建好了一种搜索引擎架构，在此基础上可以进行二次开发，实现个人规模的搜索引擎、企业局域网搜索引擎、对整个WEB的搜索引擎等不同规模的搜索引擎。另外还可以为达到一些特殊的目的建立起的搜索引擎。不论是建立何种规模的搜索引擎，一般情况下都需要对其进行二次开发，对源代码进行相应的功能性修改。通过本次实验，我们总结出一些二次开发中的重点环节，这里做一个大致的描述。
1.1  信息源选择及规范制定
                对信息源的选择可以反映出搜索引擎的业务范围：如果选择某一个网站或者网站群，那么它是一个企业局域网搜索引擎之类的；如果选择整个网络，那它是一个综合型的搜索引擎；如果选择某一主题类网站或网页，那么它是一种垂直搜索引擎；如果选择的是博客，那么可以称为博客搜索引擎；如果选择的是某种格式的文档，那么可以称作文件搜索引擎。因此，在做二次开发前，明确需求，分析主要的目标网站，选择作为信息源。
                Nutch通过制定相应的URL规则来达到对限定的URL进行爬取，即过滤信息。默认情况下可以在相关的配置文件中进行配置，它用正则表达式来规范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 进行垂直搜索引擎的话，必要的数据过滤主题过滤是需要的