资源描述
资料内容仅供您学习参考,如有不当之处,请联系改正或者删除。
第1章 绪论
随着计算机技术、 通信网、 互联网的迅速发展和日益普及, Internet上的信息量快速增长。从海量的信息块中快速检索出用户真正需要的信息正变得很困难, 信息搜索应向着具有分布式处理能力方向发展, 本系统利用hadoop分布式开源框架良好的扩充能力、 较低的运作成本、 较高的效率和稳定性来满足需求。
现状:
缺陷和不足:
( 1) 结果主题相关度不高。
( 2) 搜素速度慢。
引入hadoop+nutch+solr的优点:
( 1) hadoop平台数据处理高效。hadoop集群处理数据比起单机节省数倍的时间, 数据量越大优势越明显, 满足信息采集对数据处理的速度和质量要求。
( 2) hadoop平台具有高扩展性。能够适当扩展集群数量来满足日益不断增加的数据量, 而这并不会毁坏原集群的特性。
( 3) 安全可靠性高。集群的数据冗余机制使得hadoop能从单点失效中恢复, 即Hadoop能自动进行数据的多次备份, 以确保数据不丢失, 即使当某个服务器发生故障时, 它也能重新部署计算任务。
( 4) Nutch不但提供抓取网页的功能, 还提供了解析网页、 建立链接数据库、 对网页进行评分、 建立solr索引等丰富的功能。
( 5) 经过Nutch插件机制实现了系统的可扩展性、 灵活性和可维护性, 提高了开发效率。能够根据用户需求进行灵活定制抓取和解析, 提高了系统使用性。
( 6) 经过solr集群, 采用分布式索引在不同的机器上并行执行, 实现检索服务器之间的信息交换。能够经过设定主题进行索引检索。
研究目标和内容
本文的研究目标是全面深入分析研究分布式搜索引擎, 进而优化分布式搜索引擎中的索引构建策略, 内容包括:
( 1) 深入研究hadoop分布式平台, 仔细剖析hadoop中的分布式文件系统HDFS和map/Reduce编程模型。
( 2) 深入研究Nutch架构 、 相关技术与体系结构, 着重研究分析Nutch插件系统的内部结构和流程; 对protocol-httpclient插件进行开发支持表单登录; 对 url过滤、 信息解析插件进行开发, 提高搜索的主题相关度; ( 实现用mapreduce的google的排序算法, 改进系统搜索的关联度) 。
系统功能结构
( 1) 本地资源解析模块
对本地文本pdf,word,excel内容解析和索引, 按照主题分类, 添加到相应的主题中进行搜素。
( 2) 搜索模块
用户根据不同主题进行内容索引、 关键词查询, 将跟查询关联度最高的前n个文档返回给用户, 并统计出在这些查询结果中出现频率最高的前n个词。用户可根据需求修改配置文件, 提高搜索的相关度。
( 3) 信息爬取模块
① 信息定制采集模块
1、 种子URL: 用作抓取器爬取的出发点, 也叫做根URL。
2、 关键字: 关键字的选择很重要, 描述了抓取任务的所属分类的主题方向。
3、 深度: 由于Nutch抓取模块采用的是广度优先的策略, 抓取深度的选择决定了抓取时间的长度和抓取网页数量的大小。一般根据所选取的种子URL的类型和详细程度以及对网页抓取规模的需求来进行设置。
在信息定制模块用户设置主题信息, url信息、 抓取深度的信息, 抓取线程根据定制信息, 开始抓取工作。( 综合型搜索引擎; 某一主题类网站, 垂直搜索引擎; 博客搜索引擎)
② 信息解析过滤模块
根据fiddle进行登录分析, 修改网络协议插件, 支持简单的一次跳转表单登录, 用户能够在配置文件中进行设置, 然后抓取内容; 复杂的登陆需要分析登陆过程, 写出相对应的网络协议插件。由于本系统在网络资源采集过程中支持个性化定制, 只对目标站点感兴趣的内容进行采集, 分析目标站点的结构特点, 在页面采集完成后, 从中提取出链接、 元数据、 正文、 标题、 关键字、 描述等信息, 进行后续的过滤和其它处理。链接的提取首先要判断页面类型, 页面的类型能够有应答头分析得出, 根据不同的类型选择相应的爬取和解析插件, 对遇到带有链接的标记如<a>、 <href>、 <frame>等, 就从标记结构的属性中找出 目标url, 并从成正确该标记之间抽取出正文作为该链接的说明文字, 链接文字一般能反映文章的主题信息, 系统设定阈值, 判断主题和说明性文字的相关性, 对爬取链接进行过滤, 加入到爬取链接列表中。定制采集的子模块, 根据正则表示式对网页内容进行过滤, 获取和处理跟主题相关的内容, 过滤无关的信息内容; 对网页编码格式进行提取, 实现内容编码的转换。( 下一步改进主题相关度链接过滤算法)
( 4) 系统管理模块
用户对根据需求对系统的配置参数进行修改。
论文组织结构
1、 绪论。
本章首先介绍了本文研究的背景及意义, 接着研究了信息采集与搜索技术的国内外发展现状, 最后给出了本文研究的内容和论文组织结构。
2、 关键技术。Hadoop、 Nutch、 Solr技术架构及文本检索算法
本章介绍了开源软件Hadoop、 Nutch、 Solr的基本情况;详细介绍了Hadoop框架及其进行分布式计算的编程模型MapReduce和数据存储系统HDFS; Nutch以Hadoop的分布式文件系统HDFS作为底层数据平台, 采用MapReduce编程方式实现数据的分布式处理, 以扩展机制为突出特性, 用户能够根据实际需求对其添加插件进行扩展改进, 构建自己的信息采集搜索系统; 经过Solr集群, 采用分布式索引在不同的机器上并行执行, 实现检索服务器之间的信息交换, 减小索引对机器的要求, 同时介绍了常见的文本检索算法VSM , pagerank和lucene默认的排序算法。
3、 系统环境配置。Hadoop+Nutch+Solr系统的运行环境配置与运行。
本章介绍配置Hadoop+Nutch+solr系统的运行环境并详细阐述其运行流程。
4、 基于Hadoop+Nutch+Solr的信息采集搜索系统的设计与实现。
本课题采用hadoop+Nutch+Solr开源软件, 缩短了开发时间而且能够根据个性化需要采集数据提高搜素结果的精度, 基于mapreduce实现了pagerank算法,将pagerank作为一个独立的索引项添加到nutch默认的lucene排序算法中, 用户能够根据需求自己定义排序的规则, 提高检索的相关度。( 基于hadoop的nutch网页排序算法研究与实现)
系统相关技术介绍
Hadoop
hadoop由 Apache公司于 年秋天作为Lucene的子项目Nutch的一部分正式引入。Hadoop被定位为一个易于使用的平台, 以HDFS、 MapReduce为基础, 能够运行上千台PCServer组成的系统集群, 并以一种可靠、 容错的方式分布式处理请求。本文基于Hadoop+Nutch+Solr开发的信息采集搜索项目, 现对Hadoop进行全面分析和深入研究。
Hadoop框架介绍
Hadoop是执行大数据分布式应用的开源框架, 凭借高效, 可靠, 可扩展等特性受到广泛应用, 它有两大最核心的模块: 进行分布式计算的MapReduce与底层的存储系统HDFS( Hadoop Distributed FileSystem分布式文件系统) 。
MapReduce中任务的分解( Map) 与结果的汇总( Reduce) 是其主要思想。Map就是将一个任务分解成多个任务, Reduce就是将分解后多任务分别处理, 并将结果汇总为最终结果。
Hadoop整体由九个子项目组成, 其中MapReduce和HDFS两大核心将在后文展开具体介绍。框架如下图所示, 项目功能如下表所示.
图 Hadoop框架图
子项目
功能
Hadoop Common
Hadoop系统核心, 提供子项目的基本支持
HDFS
实现高吞吐的分布式存储
MapReduce
执行分布式并行计算
HBase
一个可扩展的分布式数据库系统
Pig
为并行计算提供数据流语言和执行框架
Hive
提供类SQL语法进行数据查询的数据仓库
ZooKeeper
提供分布式锁等
Mahout
一个大规模机器学习和数据挖掘库
Arvo
Hadoop的RPC(远程过程调用)方案
表Hadoop子项目功能介绍
MapReduce编程模型
MapReduce是一种编程模型, 该模型将数据扩展到多个数据节点上进行处理, 它最早是Google提出的一个软件架构, 用于大规模数据集( 大于1TB) 的并行运算。并行编程模式的最大优点是容易扩展到多个计算节点上处理数据。开发者能够很容易就编写出分布式并行程序。
mapreduce的主要思想是将自动分割要执行的问题( 例如程序) 拆解成map( 映射) 和reduce( 化简) 的方式; 一个MapReduce作业( job) 首先会把输入的数据集分割为多个独立的数据块, 再以键值对形式输给Map函数并行处理。Map函数接受一个输入键值正确值, 产生一个中间键值对集合, 由MapReduce保存并集合所有具有相同中间key值的中间value值传递给Reduce函数, reduce对这些value值进行合并, 形成一个value值集合, 最终形成输出数据。 处理流程如下图:
MapReduce的处理流程
Hadoop的分布式文件系统( HDFS)
Hadoop分布式文件系统(HDFS)是Google GFS存储系统的开源实现, HDFS具有高容错性和高传输率, 特别适合具有大数据集的程序应用。 HDFS采用master/slave架构。一个HDFS集群包含一个单独的名字节点( Namenode) 和一定数目的数据节点( Datanode) 组成一个HDFS集群。HDFS被设计成一个能够在大集群中、 跨机器、 可靠的存储海量数据的框架。它将所有文件存储成block块组成的序列, 除了最后一个block块, 所有的block块大小都是一样的, 她们存放在一组Datanode中, 文件的所有block块都会因为容错而被复制, 每个文件的block块大小和容错复制份数都是可配置的,她们在Namenode的统一调度小进行数据块的创立、 删除和复制工作。
下图所示为HDFS的体系架构
图 HDFS体系结构图
Namenode和Datanode都能够在普通计算机上运行。Namenode作为master服务, 它负责管理文件系统的命名空间和客户端对文件的访问。NameNode会保存文件系统的具体信息, 包括文件信息、 文件被分割成具体block块的信息、 以及每一个block块归属的Datanode的信息, 对于整个集群来说, HDFS经过Namenode对用户提供了一个单一的命名空间; Datanode作为slave服务, 在集群中能够存在多个, 一般每一个Datanode都对应于一个物理节点, Datanode负责管理节点上它们拥有的存储, 它将存储划分为多个block块, 管理block块信息, 同时周期性的将其所有的block块信息发送给Namenode。
从上面的介绍能够看出, 在搭建好的Hadoop集群上, 大数据集首先会由HDFS安全稳定地分布存储到集群内的多台机器上, 再利用MapReduce模型将该数据集分解为较小的块( 一般为64MB) 进行处理, 特点是高效、 安全、 具备高吞吐量。Hadoop用户能够在不了解分布式底层细节的情况下很好地利用该分布式平台开发分布式程序, 进行高效数据存储和运算。因此Hadoop成为管理大量数据的关键技术, 在信息采集和搜索领域的使用范围越来越广。
hadoop具备以下突出的优点:
( 1) hadoop平台数据处理简单高效。hadoop运行在由普通PC机组建的大型集群上, 用户能够在平台上快速编写并行代码运行分布式应用, 避免耗时的数据传输问题; 集群处理数据比起单机节省数倍的时间, 数据量越大优势越明显, 满足信息采集对数据处理的速度和质量要求。
( 2) hadoop平台具有高扩展性。能够适当扩展集群数量来满足日益不断增加的数据量, 而这并不会毁坏原集群的特性。
( 3) 安全可靠性高。集群的数据冗余机制使得hadoop能从单点失效中恢复, 即Hadoop能自动进行数据的多次备份, 以确保数据不丢失, 即使当某个服务器发生故障时, 它也能重新部署计算任务。
Nutch
Nutch 是 Apache 基金会的一个开源项目, 它原本是开源文件索引框架 Lucene 项目的一个子项目, 后来渐渐发展成长为一个独立的开源项目。它基于 Java 开发, 基于 Lucene 框架, 提供 Web 网页爬虫功能。从 nutch0.8.0开始, Nutch 完全构建在 Hadoop 分布式计算平台之上, 因此基于 Hadoop 的 Nutch 信息采集系统能够部署在由成千上万计算机组成的大型集群上, Nutch 也分为2部分, 信息爬取和检索, 但nutch1.2版本之后, Nutch专注的只是爬取数据, 而全文检索的部分彻底的交给solr。nutch的抓取流程中, 抓取器也叫蜘蛛或者机器人, 以广度优先搜索( BFS) 的方式从企业内部网或者互联网抓取网页, 爬取过程包括了爬虫模块和解析模块。爬虫程序将网页页面抓回判断格式解析数据, 形成页面内容数据库。
种子url
nutch的采集过程要预先给定初始种子url, 而种子url的选择将直接影响主题搜索的质量, 因此选取初始种子url的原则是种子页面本身要具有较高的主题相关性。初始种子url既能够是一个网站的首页, 也能够是网站的子页面, 关键是要尽可能的覆盖主题资源, 最终实现抓取目标的最大化, 主要有四种方法生成初始种子url:
( 1) 人工指定: 给出某个领域的权威专家给出相关的种子页面。
( 2) 自动生成: 根据用户指定的部分关键词, 并将这些关键词提交给通用搜索引擎, 从检索结果中抽取前N个页面作为种子页面。
( 3) 混合模式: 即人工指定与自动生成相结合, 首先利用通用搜索引擎获得部分相关页面, 然后经过人工筛选、 过滤、 合并、 评价, 形成一个能充分反映主题特征的种子页面。
( 4) 增加爬虫的学习能力: 经过建立各个领域的主题种子库, 并对检索历史、 用户反馈信息进行分析的基础上, 动态优化产生相应主题的种子页面集。
种子的选取在实际操作中应该根据需求及领域的特征选择适当的方法。
Nutch插件机制
Nutch另外很吸引人的一点在于, 它提供了一种插件框架, 使得其对各种网页内容的解析、 各种数据的采集、 查询、 集群、 过滤等功能能够方便的进行扩展, 插件的扩展只需经过给定接口实现, 每个接口之下的实现相互独立, 用户能够专注于目标接口的扩展而不必担心该接口与其它接口的交互Nutch 的插件体系结构。nutch使用plugin系统有三个原因:
1、 可扩展性
经过plugin, nutch允许任何人扩展它的功能, 而我们要做的只是对给定的接口做简单的实现。
2、 灵活性
因为每个人都能够根据自己的需求而写自己的plugin, 这样plugin就会有一个很强大的资源库。这样对与应用nutch程序员来说你有了更多的关于内容爬取、 过滤的算法来选择。
3、 可维护性
一个plugin的开发者只要关注这个plugin所要实现的功能, 而不需要知道整个系统是怎么工作的, 仅仅需要知道的是plugin和plug之间交换的数据类型, 这使得内核更加简单, 更容易维护。
插件体系结构图
图 插件体系结构
插件的内部结构
图 插件内部结构
runtime : 描述了其需要的 Jar 包, 和发布的 Jar 包
requires : 描述了依赖的插件
extension : 描述了扩展点的实现
extension-point: 描述插件宣布可扩展的扩展点
Nutch经过插件机制实现了系统的可扩展性、 灵活性和可维护性, 使得各个部分的开发人员只需关注自己的领域, 不必去担心如何整合系统, 也极大的提高了开发效率。
爬虫技术
1、 网络爬虫
网络爬虫实际上是一个基于 web的程序, 它从初始的种子站点出发, 进行过滤检查, 当爬虫打开某个 HTML 页面后, 它会分析 HTML 标记结构来获取信息, 并获取指向其它页面的超级链接, 然后经过既定的搜索策略选择下一个要访问的站点。 从理论上讲, 如果为 Spider 指定个适当的初始文档集和个适当的网络搜索策略, 它就能够遍历整个网络。
为了解决Web采集的关键问题, 经过不断地研究与实践, 将爬行器由最早期单纯的基于整个Web的爬行器发展到可满足不同需要的多种采集技术的爬行器。大致能够分为以下几种类型:
第一种是基于整个Web的爬行器。主要是指目标为从一些种子URL扩充到整个Web的爬行器。
第二种是增量式的爬行器。传统的爬行器根据自己的需要采集足量的信息后停止采集, 当过一段时间这些数据过时后, 它会重新采集一遍来代替先前的信息, 称为周期性Web采集器。而增量式的爬行器对待就的页面采用增量式更新, 即采集器在需要的时候采集新产生的或己经发生了变化的页面, 而对没有变化的页面不进行采集。和周期性信息采集相比, 增量式信息采集能极大地减小数据采集量, 从而极大地减少了采集的时间与空间开销。可是与此同时, 增量式信息采集也增加了算法的复杂性和技术难度。
第三种是基于主题的爬行器是指选择性地搜寻那些与预先定义好的主题相关的页面的爬行器。和基于整个Web的爬行器相比, 它并不采集那些与主题无关的页面, 因此大大地节省了硬件和网络资源, 保存的页面也由于数量少而更新快。
第四种是基于用户个性化的爬行器。不同的用户对一个搜索引擎提交同一个检索词, 她们期待的结果是不尽相同的。而通用的搜索引擎却只能返回相同的检索结果, 这显然不完全符合用户的需要。而基于用户个性化的爬行器是一种轻量级的采集系统, 它的目标就是经过用户兴趣制导或与用户交互等手段来采集信息, 给用户提供个性化服务。
第五种是移动的爬行器。这种爬行器并不像其它爬行器一样在本地客户机向Web站点服务器发送页面请求, 而是将自己上载到它所要采集的服务器中, 在当地进行采集, 并将采集结果压缩后, 再回传到本地。这样做大量地节省了Web资源, 大量的剪裁工作将在被采集对象的服务器上完成。
第六种是基于元搜索的爬行器。它对用户的提交的查询请求经过多个领域或门户搜索引擎搜索, 并将结果整合后返回给用户。一般元搜索引擎并不保存Web页面的索引文件, 可是有一些元搜索引擎会保存为它服务的每个搜索引擎的信息特征, 以后根据用户请求做出选择。
Nutch使用累积式爬取与增量式爬取相结合的策略进行, 既保证了数据的完整性又保证了时效性。
2、 网络爬虫爬行策略
网页的抓取策略能够分为广度优先、 深度优先和最佳优先三种。深度优先在很多情况下会导致爬虫的陷入(trapped)问题, 当前常见的是广度优先和最佳优先方法。
1、 广度优先搜索
广度优先搜索策略是指在抓取过程中, 在完成当前层次的搜索后, 才进行下一层次的搜索。该算法的设计和实现相对简单。在当前为覆盖尽可能多的网页, 一般使用广度优先搜索方法。
下面, 我将以图示的方式介绍广度优先遍历的过程, 如下图所示。
图 ( )
选择A作为初始 种子节点url, 则广度优先搜索的过程, 如表( ) 所示。
表 广度优先搜索过程
操作
队列中的元素
初始
空
A入队列
A
A出队列
空
BCDEF入队列
BCDEF
B出队列
CDEF
C出队列
DEF
D出队列
EF
E出队列
F
H入队列
FH
F出队列
F
G入队列
HG
H出队列
G
I入队列
GI
G出队列
I
I 出队列
空
在表所示的搜索过程中, 出队列的节点顺序即是图( ) 的广度优先搜索过程。由此可见, 图( ) 所示的广度优先搜索过程的顺序为:
A-B-C-D-E-F-H-G-I。
2、 深度优先搜索
深度优先搜索策略从起始网页开始, 选择一个URL进入, 分析这个网页中的URL, 选择一个再进入。如此一个链接一个链接地抓取下去, 直到处理完一条路线之后再处理下一条路线, 但每深入一层, 网页价值和PageRank都会相应地有所下降。 图( ) 所示的深度优先广度优先搜索过程的顺序为:
A-B-C-D -E-H-I-F-G
3、 最佳优先搜索
最佳优先搜索策略按照一定的网页分析算法, 预测候选URL与目标网页的相似度, 或与主题的相关性, 并选取评价最好的一个或几个URL进行抓取。它只访问与主题相关的网页 。
信息检索技术
信息检索(IR), 通俗的讲, 就是要在一个很大的文本(有时可能是其它数据, 如图像等)集合中, 找到与用户需求相关的能够满足用户需求的非结构化信息。
向量空间模型( VSM)
向量空间模型将文档映射为一个特征向量V(d)=(t1,ω1(d); …; tn, ωn(d)), 其中ti(i=1,2, …,n)为一列互不雷同的词条项, ωi(d)为ti在d中的权值, 一般被定义为ti在d中出现频率tfi(d)的函数, 即 。
在信息检索中常见的词条权值计算方法为 TF-IDF 函数, 其中N为所有文档的数目, ni为含有词条ti的文档数目。TF-IDF公式有很多变种, 下面是一个常见的TF-IDF公式:
根据TF-IDF公式, 文档集中包含某一词条的文档越多, 说明它区分文档类别属性的能力越低, 其权值越小; 另一方面, 某一文档中某一词条出现的频率越高, 说明它区分文档内容属性的能力越强, 其权值越大。
两文档之间的相似度能够用其对应的向量之间的夹角余弦来表示, 即文档di, dj的相似度能够表示为
进行查询的过程中, 先将查询条件Q进行向量化, 主要依据布尔模型:
当ti在查询条件Q中时, 将对应的第i坐标置为1, 否则置为0, 即
从而文档d与查询Q的相似度为
在查询过程中, 能够计算出每个文档与查询的相似度, 进而能够根据相似度的大小, 将查询的结果进行排序。
向量空间模型能够实现文档的自动分类和对查询结果的相似度排序, 能够有效提高检索效率; 它的缺点是相似度的计算量大, 当有新文档加入时, 则必须重新计算词的权值。
Lucene Scoring 评分机制
solr使用lucene的内部评分机制, 现对lucene的评分机制进行介绍。
lucene 的评分公式:
score(q,d) = coord(q,d) · queryNorm(q) ·
∑
( tf(t in d) · idf(t)2 · t.getBoost() · norm(t,d) )
t in q
其中:
tf(t in d) 关联到项频率, 项频率是指 项 t 在 文档 d 中出现的次数 frequency。默认的实现是:
tf(t in d) =
frequency½
idf(t) 关联到反转文档频率, 文档频率指出现 项 t 的文档数 docFreq。docFreq 越少 idf 就越高。默认实现:
idf(t) =
1 + log (
numDocs
–––––––––
docFreq+1
)
coord(q,d) 评分因子, 是基于文档中出现查询项的个数。越多的查询项在一个文档中, 说明些文档的匹配程序越高。默认是出现查询项的百分比。
queryNorm(q)查询的标准查询, 使不同查询之间能够比较。此因子不影响文档的排序, 因为所有有文档都会使用此因子。默认值:
queryNorm(q) = queryNorm(sumOfSquaredWeights) =
1
––––––––––––––
sumOfSquaredWeights½
每个查询项权重的平分方和(sumOfSquaredWeights)由 Weight 类完成。例如 BooleanQuery 地计算:
sumOfSquaredWeights = q.getBoost() 2 ·
∑
( idf(t) · t.getBoost() ) 2
t in q
t.getBoost()查询时期的 项 t 加权( 如: java^1.2) , 或者由程序使用 setBoost()。
norm(t,d)压缩几个索引期间的加权和长度因子:
Document boost - 文档加权, 在索引之前使用 doc.setBoost()
Field boost - 字段加权, 也在索引之前调用 field.setBoost()
lengthNorm(field) - 由字段内的 Token 的个数来计算此值, 字段越短, 评分越高, 在做索引的时候由 Similarity.lengthNorm 计算。
以上所有因子相乘得出 norm 值, 如果文档中有相同的字段, 它们的加权也会相乘:
norm(t,d) = doc.getBoost() · lengthNorm(field) ·
∏
f.getBoost()
field f in d named as t
索引的时候, 把 norm 值压缩(encode)成一个 byte 保存在索引中。搜索的时候再把索引中 norm 值解压(decode)成一个 float 值, 这个 encode/decode 由 Similarity 提供。
solr使用了Lucene的内核, 也继承了Lucene的打分规则, 我们能够根据自己的应用实现评分算法, 换掉默认的; 也能够使用默认的, 利用修改solr配置文件, 来调节评分。
Page Rank算法
一个网页的重要性等于指向它的所有网页的重要性相加之和。
如果网页j存在一个指向网页i的连接, 则表明j的所有者认为i比较重要, 从而把j的一部分重要性得分赋予i。这个重要性得分值为:
为网页j的PageRank值, 为网页j的出链数。
一个页面的PageRank是由所有链向它的页面( 链入页面) 的重要性经过递归算法得到的。一个有较多链入的页面会有较高的等级, 相反如果一个页面没有任何链入页面, 那么它没有等级。
由于存在一些出链为0, 也就是那些不链接任何其它网页的网, 也称为孤立网页。因此需要对 PageRank公式进行修正, 即在简单公式的基础上增加了阻尼系数( damping factor) q, q一般取值q=0.85。
即网页i的PageRank值; 因此公式的意义是: 网页i的PageRank值=( 1-d) +d*( 链接到网页i的所有PR值/该网页的所有出链数量之和) 。
信息采集搜索系统的安装
本系统采用hadoop1.1.2+nutch1.6+solr4.10分布式集群进行信息的采集与搜索, 集群的配置情况如下图:
表( ) 系统配置
序号
名称
描述
1
Hadoop1.1.2
使用MapReduce进行并行爬取, 使用HDFS存储数据, Nutch的任务提交在Hadoop集群上, 支持分布式
2
Nutch1.6
主要负责爬取数据, 支持分布式
3
Solr4.10
主要负责检索, 对爬完后的数据进行搜索, 查询, 海量数据支持分布式
4
Centos6.5
Linux系统, 在上面运行hadoop、 nutch等应用
5
Tomcat7.0
应用服务器, 给Solr提供容器运行
6
JDK1.7
提供JAVA运行环境
7
Ant1.9
提供Nutch等源码编译
8
IKAnalyzer
对网页内容与标题进行分词, 便于全文检索
hadoop系统的运行环境配置
hadoop需要在Java环境和Unix系统下运行, 也能够跨平台运行, 本系统是在linux操作系统下运行, 需要配置完成以下运行环境:
· Java环境: jdk1.7版本
vi /etc/profile
export JAVA_HOME=/usr/jdk1.7
export JRE_HOME=$JAVA_HOME/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH
从而完成所需要的java环境配置。
· hadoop集群配置: hadoop1.1.2
我在这里做了5个机器的hadoop集群
Master.Hadoop
192.168.47.62
Slave1.Hadoop
192.168.47.63
Slave2.Hadoop
192.168.47.64
Slave3.Hadoop
192.168.47.65
Slave4.Hadoop
192.168.47.66
在 192.168.47.62上
vi /etc/profile
export HADOOP_HOME=/home/hadoopmaster/hadoop-1.1.2
export PATH=$PATH:$HADOOP_HOME/bin
vi /etc/hosts
127.0.0.1 localhost
192.168.47.62 Master.Hadoop
192.168.47.63 Slave1.Hadoop
192.168.47.64 Slave2.Hadoop
192.168.47.65 Slave3.Hadoop
192.168.47.66 Slave4.Hadoop
localhost Master.Hadoop
配置无密码登录, 在这里我不做介绍。
进入hadoop-1.1.2/conf下
vi masters
192.168.47.63(secondaryhost)
vi slaves
192.168.47.62
192.168.47.63
192.168.47.64
192.168.47.65
192.168.47.66
vi hadoop-1.12/conf /core-stie.xml
vi conf/hdfs-site.xml
vi conf/mapred-site.xml
把配置好的hadoop文件夹拷贝到集群的其它机器中。
nutch的运行环境配置
下载apache-nutch-1.6的源文件, 把nutch导入到eclipse进行二次开发的过程在这里不做介绍。
vi conf/nutch-site.xml
<property>
<name>plugin.includes</name>
<value>protocol-httpclient|urlfilter-regex|parse-(html|tika|js|pdf|msword)|recommquery|index-(basic|anchor)|scoring-opic|urlnormalizer-(pass|regex|basic)</value>
</property>
<property>
<name>http.timeout</name>
<value>10000</value>
</property
<property>
<name>http.agent.name</name>
<value>Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)Gecko/ 0101 Firefox/20.0</value>
</property>
<property>
<name>plugin.folders</name>
<value>./src/plugin</value>
</property>
<property>
<name>http.redirect.max</name>
<value>2</value>
</property>
<property>
<name>http.content.limit</name>
<value>-1</value>
</property>
<property>
<name>file.content.limit</name>
<value>-1</value>
</property>
<property>
<name>http.accept.language</name>
<value>en-us,en-gb,en;q=0.7,*;q=0.3</value>
</property>
Nutch与solr的集成配置
1、 将solr/example/webapps/solr.war拷贝到tomcat的webapps中
2、 进入到到tomcat7中, 对war进行解压, 然后删除war包。
3、 拷贝solr/example/lib/ext下的相关依赖jar包到webapps/solr/WEB-INFO/lib中
4、 修改web.xml的solr/home指定到solr所在的路径。
5、 修改tomcat/conf的server.xml文件中的编码加入一行URLEncoding="UTF-8"
6、 solr不会自动创立core,把multicore中的core0拷到solr/example/, 拷贝nutch的配置文件schema-solr4.xml到core0/conf/下, 重命名schema-solr4.xml为schema.xml, 修改solrconfig.xml要和对应的core对应, 7 、 加入分词工具, 在这里对我用的是IKAnalyzer。
基于Hadoop+Nutch+Solr的信息采集搜索系统的设计与实现
信息采集搜索系统的实现, 以第二章相关技术理论分析与研究为基础, 利用MapReduce编程模型在分布式处理方面的优点, 实现了pagerank算法在系统检索中的评分; 对nutch的url过滤, 内容解析插件进行改进, 实现了用户自订制链接和获取的主题内容; 对本地资料文件实现格式识别并抽取题名、 时间、 内容等文本信息保存为xml文件, 实现本地相关主题信息查询。系统采用IK分词器, 最终完成了信息采集与搜索的设计与实现。
系统结构总体设计
本系统部署在hadoop+nutch+solr的集群框架上, 分为四个部分, 系统功能组成如下:
系统功能组成图
资料文档解析, 实现单个文件和压缩文件上传, 对压缩文件自动解压; 对资料文件实现多格式识别, 例如pdf,word,html,excel等格式文件, 文件提取标题, 作者, 时间, 内容等关键信息, 转换为xml文件
展开阅读全文