Hadoop和分布式Lucene

Lucene是大家用的最多的开源搜索引擎。本文不探讨Lucene如何实时更新（http://issues.apache.org/jira/browse/LUCENE-1313），和如何修改Lucene评分机制，添加如PageRank评分因子，本文只讨论分布式的Lucene。

 

 

说到Lucene一般都会提到Nutch，Hadoop最早是Doung Cutting为了Nutch的crawler和indexer所开发的做为nutch的两个package。Hadoop在Nutch中的作用就是抓取页面和建立索引。其抓取和建索引详见页面。因为Hadoop的seek能力限制，Nutch的分布式搜索使用手动配置的机制，缺少管理索引能力和服务器的机制。具体步骤：在webserver中修改search-servers.txt把搜索服务的服务器地址和服务端口添加进去，然后把nutch-site.xml中的searcher.dir指到search-servers.txt保存的目录，在提供搜索服务的服务器上手动的从HDFS中拷贝索引文件到本地。启动DistributedSearch.Server提供搜索服务。Nutch节点失效通过搜索请求IPC调用的超时来通知。

 

Lucene另一种分布式搜索是使用Solr（本人不太熟悉Solr）。所有的更新是在Solr的主服务器，通过cron自动分发到搜索服务器。搜索通过只定shards的host:port/base_url分发到各个搜索服务器。url例子：http://localhost:8983/solr/select?shards=192.168.1.27:8983/solr,192.168.1.28:8983&q=solr。缺点是没有全局的Lucene评分机制中的idf、lengthNorm因子，没有节点失效处理机制。由于分发document到shards使用uniqueId.hashCode() % numServers机制，可扩展性大打折扣。最近Rackspace结合Sorl，Hadoop和Tomcat来搜索邮件日志数据，文档中看不出使用何种机制失效处理机制等。

 

在Hadoop的wiki中提到由HP Lab实现的Distributed Lucene，但是自从08年5月18日提交了一次source后就没了下文。

 

Katta分布式搜索是101tec.com贡献的一个开源项目。主要目的提供高有效性的搜索服务，并提供负载平衡。Katta使用zookeeper保证主节点和搜索节点的有效性，指派索引文件给搜索节点，察觉搜索节点的失效。每一个搜索节点在启动时往zookeeper的“/nodes”节点写一个短暂的znode。主节点设定watch事件察觉这个znode的变化。即当节点和zookeeper server连接断开时，zookeeper自动把这个znode删除，并通知主节点。同样，相同的程序处理主节点失效。当前只有一个活动的主节点往zookeeper中写“/master” 这个znode。备用的主节点设定watch事件察觉这个znode的变化，并把自己变成活动的主节点。当有新的索引被部署时在zookeeper中“/index” znode下添加一个znode，主节点把这个索引分配给搜索节点。“/nodes-to-shards”目录保存每一个搜索节点的znode，在每一个znode下是这个搜索节点被分配的索引文件列表。“/shards-to-nodes”目录保存每一个搜索节点的znode，在每一个znode下是这个搜索节点已经部署的索引文件列表。

Katta现阶段没有实时更新。（正在计划，可能类似于Dynamo，更新的一致性，采用类似于 Quorum 系统的一致性协议实现），没有LRU或LFU缓存策略。其分布式TF-IDF的解决方案：分为两次发送请求。首先向每个搜索节点发送获取document frequency（只读取tis文件）的请求，然后再向每个搜索节点发送搜索请求，把document frequency和query一起发送。

 

在Hadoop的contrib中的index是使用MapReduce建立Lucene索引的，不是用来搜索用的。

 

通过上面的软件，我们可以建立一个自动化的搜索服务。建立一个web控制服务器来监控整个过程。先使用hadoop的MapReduce来建立索引，在提交job是设定job.end.notification.url到我们的控制服务器，控制服务器接受到建立索引的任务已经完成，就可把索引分配给Katta提供搜索服务。