[原]基于hadoop搜索引擎实践——二级索引文件(五)

标签: | 发表时间:2014-10-29 01:10 | 作者:long1657
出处:http://blog.csdn.net/long1657
基于hadoop搜索引擎——二级索引文件
    一般生成的倒排表文件会比源文件暂用空间大,主要是倒排表文件所记录的信息比较详细。它记录了所有的索引词记录(TERM_RECORD)信息,对于常见的关键词(TERM),其MULTI_INFO可能包含几万甚至几十万个SINGLE_INFO.
    由于倒排表文件很大。系统难以将其在同一时刻全部装入内存;另外一面,用户在查询时只会用到几个TERM及其对应的MULTI_INFO。为了提高查询速度,将倒排文件以Hash表的方式存储在内存中,这样在接受查询TERM的请求时,可以快速返回对应的MULTI_INFO,因此,本系统将倒排表文件划分成若干个字表文件(每个子表文件包含一部分TERM_RECORD),并建立一个描述TERM和其所在子表文件位置的对应关系的索引文件(索引词表)。
1.分割倒排索引文件
    为了保证数据分布的均衡性,在分隔倒排表文件时,精良保证字表文件的大小相差不多。为了达到这一目标,利用MapReduce编程模型具有的2阶段性,完成对倒排表文件的分割。 
    MR程序对数据的处理过程包括Map和Reduce两个阶段。在Map阶段结束后,通过分区(Partition)过程,Mapper发射出来的数据,Partitioner分配至各个Reducer处理。默认情况下,Partitioner将具有相同的key的<key,value>对发送至同一个Reduce函数处理。分割倒排表文件算法的设计思路是改写分布式系统提供的Partitioner函数,令其在洗牌过程中将数据均匀分布给各个Reducer函数,而不是根据key的情况进行分发。Partitiner算法代码如下:
    public class SplitFilePartitioner<K, V> extends Partitioner<K, V> {
    public static int lastID = 0;
    @Override
    public int getPartition(K key, V value, int partitionNum) {
        this.lastID++;
        lastID = (this.lastID % partitionNum);
        return lastID;
    }
}


2.生成二级索引文件
     分割后的倒排字表文件中都互不重复地保存了倒排文件的部分信息。然而,在执行一个查询TERM的命令时,系统并不知道"TERM_RECORD"保存在哪个字表中。因此,需要建立一个索引文件,该文件保存每个TERM与其所在字表(包括在字表中位置)的映射关系,具体格式定义如下:
    (1)索引文件(INDEX_FILE)由若干词及其索引信息组成。每个词及其索引信息是由一个索引词(TERM)和该词的索引信息(INDEX_INFO)组成的,其中TERM和INDEX_INFO之间用空格隔开。索引词记录按照顺序最佳的方式存放,之间用制表符分隔,表示格式如下:
    TERM+'\t'+INDEX_INFO+'\n';
    (2)每个词的索引信息(INDEX_INFO)由子表编号(TABLE_ID),这条索引记录相在该子表中德偏移量(OFFSET)组成,其间用空格隔开。表示如下:
    INDEX_INFO=TABLE_ID+空格+OFFSET
    代码如下:
   
public static class TokenIndexMapper extends
            Mapper<LongWritable, Text, Text, Text> {

        @Override
        protected void map(LongWritable key, Text value, Context context)
                throws IOException, InterruptedException {
            String line = value.toString();
            FileSplit split = (FileSplit) context.getInputSplit();
            context.write(new Text(line.split("\t")[0]), new Text(split
                    .getPath().toString() + " " + key.get()));
        }
    }

    public static class TokenIndexReducer extends
            Reducer<Text, Text, Text, Text> {
        @Override
        protected void reduce(Text key, Iterable<Text> values, Context context)
                throws IOException, InterruptedException {
            boolean flag = true;
            while (values.iterator().hasNext()) {
                if (flag) {
                    context.write(key, values.iterator().next());
                    flag = false;
                }else{
                    values.iterator().next();
                }
            }
        }
    }

    在经过过滤源文件数据,建立倒排表文件,生成二级索引文件等一系列工作之后,整个系统的核心离线工作部分就全部完成了。此后,每当从前台接收到一个TERM查询时,本系统首先从索引文件(INDEX_FILE)中找出这个TERM保存在什么子表的位置(INDEX_INFO);然后打开对应的子表文件并定位相应的位置,读出这个TERM及其对应的MULTI_INFO;最后分析MULTI_INFO中每个SINGLE_INFO的信息,从过滤后的源文件(FlITERED_SOURCE_FILE)中找出相应的帖子信息返回即可。
具体实现代码可以查看:
参考文献:
1.刘鹏,hadoop实战,电子工业出版社,2011.9

作者:long1657 发表于2014-10-28 17:10:51 原文链接
阅读:73 评论:0 查看评论

相关 [hadoop 搜索引擎 实践] 推荐:

[原]基于hadoop搜索引擎实践——二级索引文件(五)

- - long1657的专栏
基于hadoop搜索引擎——二级索引文件.     一般生成的倒排表文件会比源文件暂用空间大,主要是倒排表文件所记录的信息比较详细. 它记录了所有的索引词记录(TERM_RECORD)信息,对于常见的关键词(TERM),其MULTI_INFO可能包含几万甚至几十万个SINGLE_INFO..     由于倒排表文件很大.

基于Nutch+Hadoop+Hbase+ElasticSearch的网络爬虫及搜索引擎

- - zzm
网络爬虫架构在Nutch+Hadoop之上,是一个典型的分布式离线批量处理架构,有非常优异的吞吐量和抓取性能并提供了大量的配置定制选项. 由于网络爬虫只负责网络资源的抓取,所以,需要一个分布式搜索引擎,用来对网络爬虫抓取到的网络资源进行实时的索引和搜索. 搜 索引擎架构在ElasticSearch之上,是一个典型的分布式在线实时交互查询架构,无单点故障,高伸缩、高可用.

SEO实践(2)——让网站对搜索引擎友好

- - SEM WATCH
在该系列文章的第一篇中,提到SEO应该是以数据为基础的,并略为展开写了一些数据方面的准备工作. 数据虽然是非常重要的,但它扮演的角色只能是辅助:发现问题、总结改进、作为决策的参考因素等,但都无法脱离既有的SEO方法而独立存在. 而SEO的方法,应该分为两种或四种: 使网站对搜索引擎友好、使网站对搜索引擎的用户友好.

搜索引擎-信息检索实践—网络爬虫

- - CSDN博客互联网推荐文章
网络爬虫有两个任务:下载页面和发现URL. 1.从请求队列中取出URL,下载对应页面,解析页面,找到链接标签. 2.网络爬虫发现了没有遇到过的URL,将其加入请求队列. 网络爬虫使用礼貌策略(politeness policy):. 网络爬虫不会在特定的网络服务器上一次抓取多个页面,在同一个网络服务器的两次请求之间,网络爬虫会等待一定时间.

SEO实践(3)——让网站对搜索引擎的用户友好

- - SEM WATCH
该系列前的两篇文章提及SEO数据的准备工作、以及如何让网站对搜索引擎友好,难以避免的涉及了不少技术层面上的内容. 这篇总算能进入稍微轻松点的话题,因为让网站对搜索引擎的用户友好,只需要我们从常识出发就可以了——尽管往往越是常识越容易成为盲点. 不知是否有人在疑惑,为什么不是对网站自己的用户友好,而是对搜索引擎的用户友好.

Hadoop调优与实践的Cheat Sheets

- alex - NoSQLFan
虽然只有一张图,但是内容却非常丰富,可以说是Hadoop调优的Cheat Sheets. NoSQLFan已将图片转存到115网盘以便大家下载. 115地址:http://u.115.com/file/aqzdgi99. 原地址:HadoopPerformanceTuningGuide.pdf. 百度Hadoop分布式系统揭秘:4000节点集群.

uSniff:BT种子搜索引擎

- leqoqo - 软件志
一、uSniff相关信息: 1、官方主页:http://www.usniff.com/ 2、简介:uSniff是一个BT种子搜索引擎,简单、易用、实时是其最大的优点,其搜索引擎数据库包含了17个知名种子站点的种子信息,目的是想发展成为世界上最大的BT种子搜索引擎,而且对于每个种子,该搜索引擎都会进行安全认证,以保证用户的正常使用.

分布式计算开源框架Hadoop入门实践

- - ITeye博客
一、分布式计算开源框架Hadoop实践. 在 SIP项目设计的过程中,对于它庞大的日志在开始时就考虑使用任务分解的多线程处理模式来分析统计,在我从前写的文章《Tiger Concurrent Practice --日志分析并行分解设计与实现》中有所提到. 但是由于统计的内容暂时还是十分简单,所以就采用Memcache作为计数器,结合MySQL就完成了访问 控制以及统计的工作.

文章: Hadoop MapReduce开发最佳实践(上篇)

- - InfoQ cn
本文是Hadoop最佳实践系列第二篇,上一篇为《 Hadoop管理员的十个最佳实践》. 百度技术沙龙第三十四期:机器学习之多媒体方向的思考(2013年1月12日 周六). 百度技术沙龙特约观察员火热招募中,2013,因为有你更精彩. GitHub运维专家Jesse Newland QCon分享Github ChatOps机器人与GitHub架构演进.

文章: Hadoop管理员的十个最佳实践

- - InfoQ cn
接触Hadoop有两年的时间了,期间遇到很多的问题,既有经典的NameNode和JobTracker内存溢出故障,也有HDFS存储小文件问题,既有任务调度问题,也有MapReduce性能问题.遇到的这些问题有些是Hadoop自身的缺陷(短板),有些则是使用的不当. 白皮书下载:利用您的私有或混合云加速业务成果.