yuqing/dataCollection.md

（待续，未完...）


## 项目简述

舆情系统中数据采集是一个关键部分，此部分核心技术虽然由爬虫技术框架构建，但抓取海量的互联网数据绝不是靠一两个爬虫程序能搞定，特别是抓取大量网站的情况下，每天有大量网站的状态和样式发生变化以后，爬虫程序能快速的反应和维护。一旦分布式的爬虫规模大了以后将会出现很多问题，都是种种技术挑战，会有很多门槛，例如：

1.检测出你是爬虫，拉黑你IP(人家究竟是通过你的ua、行为特则还是别的检测出你是爬虫的?你怎么规避?)

2人家给你返回脏数据，你怎么辨认?

3对方被你爬死，你怎么设计调度规则?

4要求你一天爬完10000w数据，你一台机器带宽有限，你如何用分布式的方式来提高效率?

5数据爬回来，要不要清洗?对方的脏数据会不会把原有的数据弄脏?

6对方的部分数据没有更新，这些未更新的你也要重新下载吗?怎么识别?怎么优化你的规则?

7数据太多，一个数据库放不下，要不要分库?

8对方数据是JavaScript渲染，那你怎么抓?要不要上PhantomJS?

9对方返回的数据是加密的，你怎么解密?

10对方有验证码，你怎么破解?

11对方有个APP，你怎么去得到人家的数据接口?

12数据爬回来，你怎么展示?怎么可视化?怎么利用?怎么发挥价值?

13等等...

在大规模互联网数据采集时，必须要构建一个完整的数据采集系统。否则，你的项目开发效率和数据采集效率会很低下。同时，还会很多让你意想不到的问题发生。

<br><br>
## 开源技术栈
- Java EE
- SpringBoot
- HttpClient
- webMagic
- Spider-flow
- Redis
- MySQL
- VUE
- Tomcat
- Nginx
- Zookeeper
- Kafka
- RabbitMQ
- Bootstrap


## 总体架构
![输入图片说明](ProIMG/Qon4S9stvKHpWoe8RSYMLw.png)
  （这是最早期系统架构图）  

## 数据处理流程
![输入图片说明](ProIMG/-SaHmZ-9GeADfc121RJbqw.png)
（这是最早期系统设计图）

## 信源管理
信源，信息来源的简称。
<br><br>
我们需要对采集 类型，内容，平台，地区 等多种属性进行管理。我们对此开发了三代信源管理平台。
##### 一代产品形态
![输入图片说明](ProIMG/spider-factory-1.png)

##### 二代产品形态
![输入图片说明](ProIMG/spider-factory-2.png)

##### 三代产品形态
 ![输入图片说明](ProIMG/spider-factory-3.png)

## 站点画像  

采用模拟浏览器请求技术实现深度和广度抓取算法，总体分3个环节,对整个站点进行 1)全站扫描、2)数据储存、3)特性分析。 <br>
- siteMeta <br>
识别整个网站的结构，并且解析存储，给每一个抓取的网站都建立一个“小档案”库。 <br><br> 
- siteIndex <br>
在识别基础上把所有网页都预存储下来，并且提取各种特征值进行分析计算，从站点目录，到站点栏目，以及每个抓取目标页面都会标记不同的特性参数。 <br><br>
- siteFeatures<br>
最后将整体分析演算的结果，还原成这个网站的抓取画像和特性，以便于机器将会知道采用哪种抓取策略自动去匹配这个网站的特性抓取，基于这样的设计可以实现大规模数据采集无人值守的效果，也就是百度、谷歌 这些大型搜索引擎实现的数据效果。<br>

用“探头机器人”对整个网站预抓取一遍，相当于一个先头部队，把抓取网站的情况搞清楚以后，很快机器就知道采取哪种采集策略，大量需要采集的网站，只有极小的部分需要人工干预采集，而且更不需要编写一行爬虫采集代码，完全是自动化及低代码化大规模数据采集。


## 数据抓取
- 自动抓取 <br>
有了网站的画像属性，就知道匹配那种采集抓取策略了，大部分网站就能自动抓取就自动识别抓取数据，无需人工干预。<br>

- 人工配置 <br>
有的网站抓取难度大，采用可视化技术将整个站点的标签提取出来给开发工程师，他们将可以快速的对网站的抓取进行配置。
我们在采集任何一个网站的时候将会有各种“探头”对网站的结构，广告位，关键性内容，导航栏，分页，列表，站点特性，站点数据量，抓取难易度，站点更新频率，等等。
<br>

- 采集模板 <br>
为了简化人工操作，提高工作效率，我们还提供了爬虫模板。爬虫模板的意义在于，用户遇到一个配置繁琐的站点，不用从头开始，只需要到爬虫模板库里面找类似的模板即可，如图所示：
![输入图片说明](ProIMG/spider-factory-templeta.png)
<br> 

## 数据暂存
- 暂存  <br>
如果把数据直接储存到系统大数据库里，一旦有大量采集的脏数据下来就是浪费时间和精力，所有数据都会预演储存一遍，储存完成后会有程序对此核对监测，以免数据字段漏存，错存。
- 预警  <br>
如果在暂存环节发现储存错误，将会及时通过邮件发送对研发工程师提醒，告知错误内容，让其对此修正。
<br>


## 低代码开发

- 配置<br>
目前的爬虫工厂已经一个低代码化开发的平台了，更准确的说，我们不是在上面开发，而且在上面进行爬虫配置对数据采集抓取。如图所示：
![输入图片说明](ProIMG/spider-factory-4.png)


- 维护 <br>
通过低代码的方式的开发，我们对爬虫的维护更加方便，只需要在web管理界面中，修改爬虫抓取配置即可，同时还可以在线调试，查看具体的抓取错误日志。否则某一个站点抓取出现问题，都不知道是哪台服务器上的哪个爬虫抓取错误。各种站点爬虫的量一旦大起来，维护成本极高。
![输入图片说明](ProIMG/spider-work-err.png)

<br>

## 分布式采集
- 控制器(master)

  爬虫工厂有一个web控制管理后台，开发者可以在上面添加需要采集的任务计划和数据采集抓取的规则策略，控制器只对采集任务下发抓取指令，不做任何抓取操作。

- 分发器(dispatch)

  控制器(master)通过rabbitMQ消息将抓取的任务下发给任何一台执行端， 消息中包含抓取的策略指令及采集目标，分发器只管发送指令和策略。

- 执行器 (downloader)

  执行端可以部署在全世界任何一台能连接互联网的机器上，只要这台机器能上网，能接受分发器下发的采集任务 就能把数据采集下来，同时把采集的数据回传给中央数据仓库。


<br>

## 爬虫管理
- 爬虫状态

爬虫分布式在很多台服务器上，不知道在哪个服务器上的哪个爬虫程序出了问题是很痛苦的事情。所以，我们需要能对服务器监控，对服务器上每一个爬虫程序进行监控。监控每个爬虫运行是否正常，监控每个运行爬虫的服务器是否正常。

- 采集状态

抓取的站点时常发生变化，我们就需要知道每个目标采集的站点抓取的数据是否都正常的采集下来了，通过给每个爬虫编上采集任务编号，展示在web界面上，就可以直观的看见数据采集下来的效果。通过邮件告警和每天发送邮件统计数据，可以实时对采集状态进行监控。

<br> 

## 反爬策略

- 模拟请求头

- 代理IP池

<br> 


## 采集分类

- 网站采集

x

- app 采集

x

- 公众号采集

x

- 小程序采集

x

- (短)视频采集

x
<br>

## 采集日志
- 日志跟踪ID
 

- 数据生命周期
<br><br>


## 数据解析
- 自动解析

- 手动解析

<br> 


## 数据储存
##### 异步调用

通过kafka中间件将数据通过消息的形式发送给储存端子系统。
<br><br>
##### 更多内容
[【数据处理】技术架构说明文档](https://gitee.com/stonedtx/yuqing/blob/master/dataProcessing.md) 

<br><br><br><br>