关于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。

 

（这是hadoop提供的结合lucene的源码）


二 说明一下上述结论。

1， 我们知道lucene创建索引离不开Directory类，这个是所有read/write索引文件的基类，而如果要写入hdfs，显而易见，我们必须继 承这个基类，并重写里面的一些方法，所以就有了上图中FileSystemDirectory.java这个文件，以及网上一些其他类似的版本。上图是 hadoop contrib 提供的与lucene结合的源码结构，包括m/r的实现等等。而网上大部分的patch也好，分享也好都是基于此实现，只不过在不同的lucene版本上 做了一些微小的修改和调整。

2，先看一下FileSystemDirectory的内部类FileSystemIndexoutput

所有的写索引的操作都在这个里面。我们看一下下面这个方法

 

seek，这是不支持的，为什么不支持，因为hdfs不支持随机写，当然也不存在seek了。
当然我尝试过把这个方法注销掉，然后运行了自己的测试方法，很顺利的写入了hdfs，然而拉到本地却是无法读取，随后我用代码读取，得到了checksum错误，看上去只是校验码的错误，每次只差1，但是很遗憾，我在源码里注销掉校验码的判别，发现程序是没有问题了，但是确得不 到任何有效的索引。我估计是索引文件压根就没有正常写入所导致的。
当然我也尝试了一下用lucene本身的NIODirectory（直接写入本地）,我将写文件过程中涉及到的seek全部注销掉。最后得到了和上面一样的结果，seek是lucene写索引过程中不可缺少的，而hdfs是无法支持的，当然也就无法直接写了。
3，那么大家也许会问，那这个FileSystemDirectory有什么作用呢？是提供读索引文件的。虽然hdfs不支持随机写，但是是支持随机读的。而hadoop提供的包中，写文件是另一个类，看下图：



 
上述英文的描述大家看一下就明白了，重点说到：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去做更为简便和高效？

最后，可能因为研究的时间还是比较仓促，网上诸如此类的资料也不是太多，所以可能会理解上不够全面，如果大家有其他意见的话还是请一起讨论。

评论

3 楼 di1984HIT 2014-05-24  

谢谢，学习了。

2 楼 RRobinson 2014-03-29  

你好，我想问一下  hadoop提供的结合lucene的源码 从哪里下的

1 楼 kuaile777.happy 2013-01-07  

牛人，学习了