免规则采集器列表算法(10万个网站的采集范围是怎么样的?(组图))
优采云 发布时间: 2021-09-26 19:06免规则采集器列表算法(10万个网站的采集范围是怎么样的?(组图))
昨天,有网友表示,他最近面试了几家公司,被问了好几次问题,每次的回答都不是很好。
采访者:比如有10万个网站需要采集,你有什么方法可以快速获取数据?
要回答好这个问题,其实需要有足够的知识和足够的技术储备。
最近我们也在招聘,每周面试十几个人,感觉合适的只有一两个。他们大多和这位网友的情况一样,缺乏全局思维,即使是有三四年工作经验的人。司机。他们有很强的解决具体问题的能力,但很少从点到点思考问题,站在一个新的高度。
采集的10万个网站的覆盖范围已经超过了大多数专业舆情监测公司的数据采集。为了满足面试官提到的采集的要求,我们需要综合考虑从网站的采集到数据存储的方方面面,给出合适的方案,节约成本,提高工作效率。的目标。
下面我们就从网站的集合到数据存储的方方面面做一个简单的介绍。
一、100,000网站 他们来自哪里?
一般来说,采集的网站是随着公司业务的发展逐渐积累起来的。
我们现在假设这是一家初创公司的需求。公司刚刚成立,这么多网站,基本上可以说是冷启动。那么我们如何采集这 100,000 个 网站 呢?有几种方式:
1)历史业务的积累
不管是冷启动什么的,既然有采集的需求,就一定有项目或产品的需求。相关人员一定是前期调查了一些数据来源,采集了一些重要的网站。这些可以用作我们采集 网站 和 采集 的原创*敏*感*词*。
2)协会网站
在一些网站的底部,通常会有相关网站的链接。尤其是政府类的网站,一般都有下级相关部门的官网。
3)网站导航
有些网站可能会出于某种目的(如排水等)采集一些网站,并分类展示,方便人们查找。这些网站可以快速为我们提供第一批*敏*感*词*网站。然后,我们会通过网站关联等其他方式获得更多的网站。
4)搜索引擎
也可以准备一些与公司业务相关的关键词,在百度、搜狗等搜索引擎中搜索,通过对搜索结果的处理,提取出对应的网站作为我们的*敏*感*词*网站。
5)第三方平台
例如,一些第三方SaaS平台会有7-15天的免费试用期。因此,我们可以利用这段时间来采集与我们业务相关的数据,然后从中提取网站,作为我们最初的采集*敏*感*词*。
虽然,这个方法是网站采集最有效、最快捷的方式。不过在试用期间,获得10万个网站的可能性极小,所以需要结合上述关联网站等方式,快速获取所需的网站 .
通过以上五种方法,相信我们可以快速采集到我们需要的10万个网站。但是,这么多网站,我们应该如何管理呢?怎么知道正常不正常?
二、10万网站如何管理?
当我们采集到10万个网站时,我们首先面临的是如何管理,如何配置采集规则,如何监控网站正常与否等等。
1)如何管理
10万网站,如果没有专门的系统来管理,那将是一场灾难。
同时,由于业务需要,比如智能推荐,我们需要对网站进行一些预处理(比如打标签)。这时候就需要一个网站管理系统。
2)如何配置采集规则
我们前期采集的10万个网站只是首页。如果我们只将首页作为采集的任务,那么我们只能采集获取到首页的信息非常少,漏取率非常高。
如果要根据首页的URL执行整个站点采集,服务器资源消耗比较大,成本太高。因此,我们需要配置我们关心的列并对其执行采集。
然而,10万个网站,如何快速高效地配置列?目前我们通过自动解析HTML源代码来进行列的*敏*感*词*配置。
当然,我们也尝试过机器学习来处理,但效果不是很理想。
由于采集的网站数量需要达到10万的级别,所以对于采集一定不能使用xpath或者其他精确定位方法。不然配置10万网站的时候,黄花菜会冷的。
同时数据采集必须使用通用爬虫,使用正则表达式匹配列表数据。在采集的body中,使用算法解析时间、body等属性;
3)如何监控
由于有 100,000 个 网站,这些 网站 每天都会有 网站 修订,或列修订,或新/删除列等。因此,有必要根据采集的数据情况简单分析一下网站的情况。
比如一个网站几天没有新数据,肯定有问题。要么是网站的修改导致信息规律失效,要么是网站本身有问题。
为了提高采集的效率,可以使用单独的服务定期检查网站和列的状态。首先是检查网站和列是否可以正常访问;二是检查配置的列信息的正则表达式是否正常。以便运维人员对其进行维护。
三、任务缓存
10万网站,列配置完成后,采集的入口URL应该达到百万级别。采集器如何高效获取采集的这些入口URL?
如果把这些url放到数据库中,不管是MySQL还是Oracle,采集器获取采集的任务的操作都会浪费很多时间,大大降低采集@的效率>.
如何解决这个问题呢?内存数据库是首选,如Redis、Mongo DB等,一般采集使用Redis进行缓存。因此,您可以在配置列的同时将列信息同步到Redis 作为采集 任务缓存队列。
四、网站如何采集?
就好比想达到百万年薪,最大的可能就是去华为、阿里、腾讯等一线大厂,而且需要达到一定的水平。这条路注定是艰难的。
同样,如果你需要采集百万级的列表网址,常规的方法肯定是无法实现的。
必须采用分布式+多进程+多线程的方式。同时需要结合内存数据库Redis等进行缓存,实现任务的高效获取,对采集信息进行排序;
同时,发布时间、文字等信息的分析也必须经过算法处理。比如现在比较流行的GNE,
有些属性可以在列表采集中获取,所以尽量不要和正文放在一起进行分析。例如:标题。一般情况下,从列表中得到的title的准确率要比从信息html源代码中解析出来的算法要高很多。
同时,如果有一些特殊的网站或者一些特殊的需求,我们可以使用定制开发来处理。
五、统一数据存储接口
为了保持采集的时效性,10万个网站的采集可能需要十几二十台服务器。同时,在每台服务器上部署了N个采集器,加上一些自定义开发的脚本,采集器的总数将达到数百个。
如果每个采集器/custom 脚本都开发自己的数据保存接口,开发调试会浪费大量时间。而后续的运维也将是一件无忧无虑的事情。尤其是当业务发生变化并需要调整时。因此,统一的数据存储接口还是很有必要的。
因为数据存储接口是统一的,当我们需要对数据做一些特殊的处理,比如清理、校正等时,不需要修改每个采集存储部分。我们只需要修改接口,重新部署即可。
快速,方便,快捷。
六、数据和采集监控
覆盖10万个网站的采集,每天的数据量肯定超过200万。数据分析算法再准确,也永远达不到100%(90%已经很好了)。因此,数据分析必然存在异常。例如:发布时间大于当前时间,正文收录相关新闻信息等。
但是,由于我们已经统一了数据存储接口,所以这个时候我们可以在接口上进行统一的数据质量验证。为了根据异常情况优化采集器和自定义脚本。
同时还可以统计每个网站或采集列的数据。为了能够及时判断采集的网站/列的当前来源是否正常,以保证总有10万个有效的采集网站。
七、数据存储
由于每天的数据量很大采集,普通的数据库(如mysql、Oracle等)已经无法胜任。甚至像 Mongo DB 这样的 NoSql 数据库也不再适用。这时候,ES、Solr等分布式索引是目前最好的选择。
至于是否使用Hadoop、HBase等大数据平台,要看具体情况。在预算较小的情况下,可以先搭建分布式索引集群,再考虑大数据平台。
为了保证查询的响应速度,分布式索引中尽量不要保存文本信息。可以保存标题、发布时间、URL 等内容,以便在显示列表数据时减少二次查询。
在没有大数据平台的情况下,可以将文本保存在具有固定数据标准的txt等文件系统中。大数据平台后续上传后,即可转入HBASE。
八、自动化运维
由于服务器、采集器、自定义脚本较多,单纯依靠人工部署、启动、更新、运行监控已经非常繁琐,容易出现人为错误。
因此,必须有一个自动化的运维系统,可以实现采集器/scripts的部署、启动、关闭和运行,以便在发生变化时能够快速响应。
“比如有10万个网站需要采集,你怎么快速拿到数据?” 如果你能回答这些,拿到好offer应该就没有悬念了。