网络爬虫系统项目建设方案

精选文档精选文档PAGEPAGE16精选文档PAGE

目录

1.对项目的理解-6-1.1背景-6-

1.2业务目标错误!不决义书签。

1.3应用感知目标-6-

2.系统整体架构-7-

2.1技术框架-7-

2.2数据架构-7-

2.3功能模块-8-

2.4功能模块-9-

2.5应用部署架构-10-

3.详尽建设方案-11-

3.1一站式大数据采集、储存、冲洗、训练、导出-11-

3.2多租户管理-11-

功能说明-11-

平台截图-11-

3.3丰富的数据接口-11-

3.4平台高可用性-11-

3.5抓取高效性-12-

3.6高可扩展性-12-

3.7可视化爬虫界面-12-

3.8抓取过程-12-

3.9硬件配置方案-13-

主机、储存资源-13-

软件资源-14-

3.10资源估量-14-

储存-14-

CPU与内存-15-

4.系统安全与系统测试错误!不决义书签。

4.1系统管理以及系统安全举措错误!不决义书签。

4.2系统测试的方法和环境 错误!不决义书签。

5.工程进度安排及项目实行人员资质 错误!不决义书签。

5.1工程进度安排错误!不决义书签。

5.2项目支撑人员构成表错误!不决义书签。

5.3支撑人员有关证明资料错误!不决义书签。

杨继营（项目负责人） 错误!不决义书签。

李筠错误!不决义书签。

邹娟错误!不决义书签。

邱文川错误!不决义书签。

唐亮错误!不决义书签。

赵柏杰错误不决义书签。!

刘子悦错误!不决义书签。

曹平错误!不决义书签。

陈汉雄错误!不决义书签。

陈一错误!不决义书签。

付敏健错误!不决义书签。

张福元!不决义书签。错误

何州鹏错误!不决义书签。

黄华金错误!不决义书签。

黄习文错误!不决义书签。

李佳错误不决义书签。!

李威虎错误!不决义书签。

刘起云错误!不决义书签。

冼锡勇错误!不决义书签。

杨锋错误!不决义书签。

邹兴错误不决义书签。!

6.售后服务及质量保证举措、技术支持和保修等 错误!不决义书签。

6.1培训错误!不决义书签。

6.2保护与升级错误!不决义书签。

6.3质量保证期内的服务错误!不决义书签。

6.4寿命期内维修服务 错误!不决义书签。

7.人员培训计划、安排错误!不决义书签。8.分工界面及工作内容错误!不决义书签。

8.1技术支持错误!不决义书签。

8.2培训推行错误!不决义书签。

8.3售前阶段的配合服务错误!不决义书签。

8.4售中阶段的配合服务 错误!不决义书签。

8.5售后阶段的配合服务 错误!不决义书签。

9.技术承诺错误!不决义书签。

9.1知识产权错误!不决义书签。

9.2安全方案错误!不决义书签。

9.3电话技术支持服务错误!不决义书签。

9.4版本管理和软件补丁服务错误!不决义书签。

9.5技术资料服务错误!不决义书签。

9.6重要通信保障服务错误!不决义书签。

9.7应急方案设计与预演服务错误!不决义书签。

9.8协助故障定位服务 错误!不决义书签。

10.有关事例错误!不决义书签。

对项目的理解

1.1背景

连续推动公司信息化的全面深入改革，深入公司管理层、分公司及一线采集问题和需

求，环绕“快、准、简、稳、智”五个标准，贯彻“零不爽” IT营运服务理念，提出了大

数据应用建设内容，承接公司全网集约营销活动，提高当地精确营销服务，展开大数据合

作营运剖析，提高财务、业务价值、人力和光网的精确管理能力，优化领导视窗，成立网

运综合议论系统，建设爬虫能力，实现智慧化营运

应用感知目标

爬虫页面响应及内容加载在 5秒内，内容展现响应速度时间小于 5秒。

爬虫配置，系统保护功能简单易用， 80%用户能够在经过简单培训后联合使用手册，完

成爬虫的开发和平台的保护。

爬虫均匀宕机运转时间≤ 10小时/月。均匀故障恢复时间≤ 180分钟/次。

爬虫能够自动依据爬虫节点的负载进行负载平衡办理，同时当爬虫出现不行恢复的错

误时，能够智能的选择其余节点进行从头运转，保证爬虫任务能够正确达成。

系统整体架构

2.1技术框架

散布式爬虫框架采纳Nutch。Nutch是一个开源Java实现的搜寻引擎,它供应了我们运转

自己的搜寻引擎所需的所有工具 ,包含全文搜寻和Web爬虫。

Nutch鉴于Lucene，近似Google的完好网络搜寻引擎解决方案，鉴于 Hadoop的散布式处

理模型保证了系统的性能，插件体制保证了系统的可客户化，并且很简单集成到自己的应

用之中。

整体上Nutch能够分为两部分：抓取部分和搜寻部分。抓取程序抓取页面并把抓取回来

的数据做成反向索引，搜寻程序则对反向索引搜寻回答用户的恳求。抓取程序和搜寻程序

的接口是索引，二者都使用索引中的字段。抓取程序和搜寻程序能够分别位于不一样的机器

上。

2.2数据架构

抓取程序是被Nutch的抓取工具驱动的。这是一组工具，用来成立和保护几个不一样的数

据构造：webdatabase、segments、theindex三种不一样的数据构造：

Thewebdatabase（简称WebDB）：这是一个特别储存数据构造，用来映像被抓

取网站数据的构造和属性的会合。 WebDB用来储存从抓取开始（包含从头抓取）

的所有网站构造数据和属性。 WebDB不过被抓取程序使用，搜寻程序其实不使用它。

WebDB储存两种实体：页面和链接。页面表示网络上的一个网页， 这个网页的URL

作为标示被索引，同时成立一个对网页内容的 MD5哈希署名。跟网页有关的其余

内容也被储存，包含：页面中的链接数目（外链接），页面抓守信息（在页面被重

复抓取的状况下），还有表示页面级其余分数。链接表示从一个网页的链接到其余

网页的链接。所以WebDB能够说是一个网络图，节点是页面，链接是边；

Segment：这是网页的会合，并且它被索引。 Segment的Fetchlist是抓取程序

使用的URL列表，它是从WebDB中生成的。Fetcher的输出数据是从 Fetchlist中抓

取的网页。Fetcher的输出数据先被反向索引，而后索引后的结果被储存在 segment

中。Segment的生命周期是有限制的，当下一轮抓取开始后它就没实用了。所以删

除超出指准时间限期的segment是能够的。并且也能够节俭许多磁盘空间。 Segment

的命名是日期加时间，反响出相应的存活周期；

Theindex：索引库是反向索引所有系统中被抓取的页面，它其实不直接从页面反向索引

产生，而是归并好多小的 segment的索引产生的。Nutch使用Lucene来成立索引，所以所有

Lucene有关的工具API都用来成立索引库。需要说明的是 Lucene的segment的观点和Nutch的

segment观点是完好不一样的。Lucene的segment是Lucene索引库的一部分，而Nutch的Segment

是WebDB中被抓取和索引的一部分。

2.3功能模块

爬虫平台分精爬与通爬两大功能模块，以知足不一样租户的数据采集需求，多租户的系

统功能逻辑以下：

1、精爬

租户登岸云爬虫管理平台，在线编写爬虫脚本，云爬虫系统按计划编写的脚本规则爬

取相应页面的指定部分（比方详细议论列表），并存入大数据平台、成立全文索引。

2、通爬

调用方调用由云爬虫系统供应的通爬接口，云爬虫系统及时依据策略（代理 IP等）爬

取结果返回调用方，并存入 Hadoop平台、成立全文索引。

2.4功能模块

爬虫平台的物理架构以下，按层次区分，主要分为接入层、采集层和长久层，以下列图

所示：

1、接入层

接入层包含Web与接口。Web主机负责负载平衡分派任务，以及展现任务列表。在 Web

页面上，租户能够依据需要创立新的爬取任务。关于创立成功的爬取任务，能够经过 Web

页面查察其基本信息。RESTAPI则负责对外供应爬虫能力接口。

2、采集层

采集层包含爬虫主机与信息行列主机。爬虫主机负责接收 Web主机分派的任务，包含

抓取网页并返回内容、对抓取的内容进行分析和构造化， 以及将构造化的结果进行长久化。

Redis作为信息行列，负责进行任务的散发。

3、长久层

往常网络爬虫抓取的数据量特别大，而储存大批的数据需要较大的储存空间，所以持

久层采纳了中国挪动苏州研发中心自研的 Hadoop平台产品。

2.5应用部署架构

爬虫平台的应用部署架构以下，主要分为 Web服务域和采集服务域。

1、Web服务域

供应给租户用来编写调试爬虫脚本，安装了 WebUI、Scheduler等组件。

2、采集服务域

用来进行数据采集和结果返回，各 Spider节点安装了Fetcher、Processor、Result_Worker、

RestAPI、Selenium、PhantomJS等组件。

详尽建设方案

3.1一站式大数据采集、储存、冲洗、训练、导出

从数据获得到办理、输出全站打通的，以一键自动公布到数据库

邮箱等 、导出到当地文件 、或经过 Webhook/GraphQL获得数据。

/网站/微信民众号

/

3.2多租户管理

功能说明

云爬虫和互联网数据储存剖析平台 PaaS化，实现了多租户和租户间的资源隔绝能力。

平台截图

3.3丰富的数据接口

扩展了多种数据接口的读写能力，如关系型数据库 Oracle、非关系型HBase、HDFS文

件、ES以及流式信息接口 Kafka，以此来支持如精爬、通爬等不一样的业务需求。

3.4平台高可用性

云爬虫平台的所有爬取节点和数据储存剖析节点均匀的散布在多台物理节点上，单台

机器的宕机不会惹起整个爬取进度的中止，这类散布式架构提高了系统整体的强健性。

3.5抓取高效性

单机模式下的网络爬虫效率不高，不可以知足大规模的抓取任务需求，云爬虫平台为爬虫租

户分派多个爬取节点，经过读取共享任务池来共同履行抓取任务，每个爬取节点都能够看

成是一个单机的网络爬虫，能大幅度的提高页面的抓取效率。

3.6高可扩展性

支持静态爬取和动向衬着的主流网站数据爬取，如天猫、京东、大众议论、豆瓣等，能够

依据目前爬虫任务量动向地调理爬虫节点数目，比起传统爬虫方式灵巧性更强。同时，租

户在编写脚本时自定义程度高，同意租户依据不一样的爬取需求自定义爬取范围。

3.7可视化爬虫界面

云爬虫平台为爬虫租户供应了一个可视化页面来编写调试爬虫脚本，平台支持静态和

动向衬着的主流网站爬取，同时能依据业务紧迫程度动向调整各爬虫任务的优先级，并提

供了一个爬取数据结果的页面导出功能，方便样例数据查察，系统页面以下列图所示：

3.8抓取过程

抓取是一个循环的过程，抓取工具从WebDB中生成了一个Fetchlist会合；抽取工具根

据Fetchlist从网络上下载网页内容；工具程序依据抽取工具发现的新链接更新WebDB，而后重生成新的Fetchlist，循环往复。这个抓取循环在Nutch中常常指：generate/fetch/update

循环。

一般来说同一域名下的 URL链接会被合成到同一个 Fetchlist。这样做的考虑是：当同

时使用多个工具抓取的时候，不会产生重复抓取的现象。 Nutch按照RobotsExclusion

Protocol,能够用robots.txt定义保护私有网页数据不被抓去。

上边这个抓取工具的组合是 Nutch的最外层的，也能够直接使用更基层的工具， 自己组

合这些基层工具的履行次序达到相同的结果。这是 Nutch的优势。详细工作过程以下：

创立一个新的 WebDB(admindb-create)；

把开始抓取的跟 URL放入WebDb(inject)；

从WebDb的新segment中生成Fetchlist(generate)；

依据Fetchlist列表抓取网页的内容(fetch)；

依据抓取回来的网页链接URL更新WebDB(updatedb)；

重复上边c-e步骤直到抵达指定的抓取层数；

3.9硬件配置方案

主机、储存资源

本项目硬件配置包含数据库服务器 2台、应用服务器2台，详细配置以下；

主机名称 CPU(个 内存(G) 储存(G) 操作系 描绘

) 统

HR-APP-A4850RedHat应用主机，需要安装6.5和JDK1.7HR-APP-B4850RedHat应用主机，需要安装6.5和JDK1.7HR-DB-A16323515oracle数据库主机，利旧HR-DB-B1632oracle数据库主机，利旧

软件资源

1）数据库： Oracle11g

2）操作系统：RedHat6.5

3）应用服务器：、JDK1.7

4）WEB服务器：Nginx（公用）

3.10资源估量

储存

主机 储存(G) 估量依照

HR-APP-A 32 门户与应用脚本 1G

系统缓存：2GTomcat日记：4G暂