关于lucene和hadoop的整合研究(一)
由于工作需要，对lucene和hadoop的整合做了一些笔记，在此备忘。由于水平有限，不到位之处，请海涵。
另外，网上关于此类的文章也不多，大多是老外关于几个开源框架的说法，希望有更好的技术方案，请不吝指教一二。
首先Cloudera的hadoop0.20.2自带了一个hadoop-index-0.20.2-cdh3u4.jar的工具包，提供了lucene和hadoop整合的一些方法。网上大多数版本都是基于此，所以我先对此做了一些熟悉。
一 先说一下目前得出的几点个人的结论。
1， lucene是支持随机读写的，而hdfs只支持随机读，换言之，但凡有用到lucene处理的随机写的方法的时候，hdfs都不能处理。这里不讨论性能问题。只是说可行性。所以，直接将索引建立在hdfs是不可行的。
2， 目前能做到的如果不借助于local的文件而写入hdfs，唯一的方法就是把索引写入内存再写入hdfs。
上述英文的描述大家看一下就明白了，重点说到：FileSystemDirectory是一个只读的文件，索引文件因为hdfs只支持序列化的写所以无法被直接存在FileSystemDirectory上，所以会被存在lucene的本地目录上。
4,当然这个不带public的MixedDirectory是无法直接引用的，而是被下面这个类所引用：
从名字上来看这是和map/reduce相关的累，源码中，这是跑在一个reduce上写索引的类。我们看下上面的英文注解，重点部分是：perm dir和temp dir，即永久地址和临时地址，很明显，temp dir是我们每次写索引的地方，而perm dir可以是hdfs上某个位置，而每次在temp dir上创建一个新的索引版本之后，会将temp dir move到perm dir,随后删除temp dir。
结论：现在我们知道了，hadoop提供的这个和lucene结合的实质，是将索引写到本地文件，再传到hdfs上。
5,下面我跑了一下自带的测试类，而lucene的版本是2.3。看一下文件结构：
目录表示的很清楚，在map/reduce过程中会产生local的toBeDeleted文件夹，而在hdfs上的数据都是从local move得来的。
6，我在搜索资料的过程中，了解到几种开源产品，诸如blur , nutch , katta等用于整合lucene和hadoop，虽然我没有详细看过他们源码，但是从网友的讨论中得知，nutch也是基于先写本地再写hdfs，其他两个被使用的比较少，具体实现还不知道。
7，在这个实现中，索引的更新当然是无法直接写到hdfs上的，而是会借助于内存，然后就牵扯到了map/reduce的partition等等一些概念和一些具体的map/reduce的过程。个中细节我不是太熟悉，总之update的操作会借助到内存。
8，最后我尝试了一下写内存再写hdfs的过程，没什么问题。
三 抛砖引玉。
1，就目前来看，写索引到hdfs我们为何要直接去写？一方面lucene的设计本身就是随机的读写和hdfs顺序读写是完全不同的。另一方面，索引基于内存或者本地的效率往往是比较高。
2，我以为，用分布式去做索引的初衷是没有问题，甚至可以用m/r去搜索然后合并等等都没有问题。但是在读写索引的过程中，lucene和hdfs本身差别太大，直接读写hdfs困难重重。何不用内存和local tmp去做更为简便和高效？
最后，可能因为研究的时间还是比较仓促，网上诸如此类的资料也不是太多，所以可能会理解上不够全面，如果大家有其他意见的话还是请一起讨论。
页:
[1]