09网络爬虫系统项目建设方案详细.docx

上传人:b****2 文档编号:2466998 上传时间:2022-10-29 格式:DOCX 页数:9 大小:670.87KB
下载 相关 举报
09网络爬虫系统项目建设方案详细.docx_第1页
第1页 / 共9页
09网络爬虫系统项目建设方案详细.docx_第2页
第2页 / 共9页
09网络爬虫系统项目建设方案详细.docx_第3页
第3页 / 共9页
09网络爬虫系统项目建设方案详细.docx_第4页
第4页 / 共9页
09网络爬虫系统项目建设方案详细.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

09网络爬虫系统项目建设方案详细.docx

《09网络爬虫系统项目建设方案详细.docx》由会员分享,可在线阅读,更多相关《09网络爬虫系统项目建设方案详细.docx(9页珍藏版)》请在冰豆网上搜索。

09网络爬虫系统项目建设方案详细.docx

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

1.对项目的理解

1.1背景

持续推进企业信息化的全面深化改革,深入公司管理层、分公司及一线收集问题和需求,围绕“快、准、简、稳、智”五个标准,贯彻“零不爽”IT运营服务理念,提出了大数据应用建设内容,承接集团全网集约营销活动,提升本地精准营销服务,开展大数据合作运营分析,提升财务、业务价值、人力和光网的精确管理能力,优化领导视窗,建立网运综合评价体系,建设爬虫能力,实现智慧化运营

应用感知目标

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

Ø爬虫配置,系统维护功能简单易用,80%用户可以在经过简单培训后结合使用手册,完成爬虫的开发和平台的维护。

Ø爬虫平均宕机运行时间≤10小时/月。

平均故障恢复时间≤180分钟/次。

Ø爬虫可以自动根据爬虫节点的负载进行负载均衡处理,同时当爬虫出现不可恢复的错误时,可以智能的选择其他节点进行重新运行,保证爬虫任务可以正确完成。

2.系统整体架构

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.详细建设方案

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

从数据获取到处理、输出全站打通的,以一键自动发布到数据库/网站/微信公众号/邮箱等、导出到本地文件、或通过Webhook/GraphQL获取数据。

3.2多租户管理

3.2.1功能说明

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

3.2.2平台截图

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遵循RobotsExclusionProtocol,可以用robots.txt定义保护私有网页数据不被抓去。

上面这个抓取工具的组合是Nutch的最外层的,也可以直接使用更底层的工具,自己组合这些底层工具的执行顺序达到同样的结果。

这是Nutch的优势。

具体工作过程如下:

∙创建一个新的WebDB(admindb-create);

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

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

∙根据Fetchlist列表抓取网页的内容(fetch);

∙根据抓取回来的网页链接URL更新WebDB(updatedb);

∙重复上面c-e步骤直到到达指定的抓取层数;

3.9硬件配置方案

3.9.1主机、存储资源

本项目硬件配置包括数据库服务器2台、应用服务器2台,具体配置如下;

主机名称

CPU(个)

内存(G)

存储(G)

操作系统

描述

HR-APP-A

4

8

50

RedHat6.5

应用主机,需要安装Tomcat7.0.73和JDK1.7

HR-APP-B

4

8

50

RedHat6.5

应用主机,需要安装Tomcat7.0.73和JDK1.7

HR-DB-A

16

32

3515

oracle数据库主机,利旧

HR-DB-B

16

32

oracle数据库主机,利旧

3.9.2软件资源

1)数据库:

Oracle11g

2)操作系统:

RedHat6.5

3)应用服务器:

Tomcat7.0.73、JDK1.7

4)WEB服务器:

Nginx1.10.3(公用)

3.10资源估算

3.10.1存储

主机

存储(G)

估算依据

HR-APP-A

32

门户与应用脚本1G

系统缓存:

2G

Tomcat日志:

4G

临时数据接口存储:

8G

数据集成平台与启动缓存:

4G

系统冗余比例:

40%

总存储要求:

(1+2+4+8+4)/(1-40%)=31.66G

HR-APP-B

32

同上

HR-DB-A

HR-DB-B

3515

Oracle11g安装空间:

60G

系统表空间:

200G

应用表空间:

2200G

系统冗余比例:

30%

总存储要求:

(60+200+1600)/(1-30%)=3514.29G

3.10.2CPU与内存

满足日常运行要求即可。

建议配置如下:

应用服务器:

4Cpu/8G内存(保证Tomcat能正常运行即可)

数据库服务器:

16Cpu/32G内存(保证oracle11g能正常运行即可)

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1