scrapy_redis去重优化(已有7亿条数据),附Demo福利

背景:

前些天接手了上一位同事的爬虫,一个全网爬虫,用的是scrapy+redis分布式,任务调度用的scrapy_redis模块。

大家应该知道scrapy是默认开启了去重的,用了scrapy_redis后去重队列放在redis里面。我接手过来的时候爬虫已经有7亿多条URL的去重数据了,再加上一千多万条requests的种子,redis占用了一百六十多G的内存(服务器,Centos7),总共才一百七十五G好么。去重占用了大部分的内存,不优化还能跑?

一言不合就用Bloomfilter+Redis优化了一下,内存占用立马降回到了二十多G,保证漏失概率小于万分之一的情况下可以容纳50亿条URL的去重,效果还是很不错的!在此记录一下,最后附上Scrapy+Redis+Bloomfilter去重的Demo(可将去重队列和种子队列分开!),希望对使用scrapy框架的朋友有所帮助。

接下来还会对种子队列进行优化,详见:《scrapy_redis种子优化》


记录:

我们要优化的是去重,首先剥丝抽茧查看框架内部是如何去重的。

  • 因为scrapy_redis会用自己scheduler替代scrapy框架的scheduler进行任务调度,所以直接去scrapy_redis模块下查看scheduler.py源码即可。
  • 在open()方法中有句self.df = RFPDupeFilter(...),可见去重应该是用了RFPDupeFilter这个类;再看下面的enqueue_request()方法,里面有句if not request.dont_filter and self.df.request_seen(request):return,看来self.df.request_seen()这就是用来去重的了。
  • 按住Ctrl再左键点击request_seen查看它的代码,可看到下面的代码:
def request_seen(self, request):
    fp = request_fingerprint(request)
    added = self.server.sadd(self.key, fp)
    return not added
  • 可见scrapy_redis是利用set数据结构来去重的,去重的对象是request的fingerprint。至于这个fingerprint到底是什么,可以再深入去看request_fingerprint()方法的源码(其实就是用hashlib.sha1()对request对象的某些字段信息进行压缩)。我们用调试也可以看到,其实fp就是request对象加密压缩后的一个字符串(40个字符,0~f)。


是否可用Bloomfilter进行优化?
以上步骤可以看出,我们只要在这个request_seen()方法上面动些手脚即可。由于现有的七亿多去重数据存的都是这个fingerprint,所有Bloomfilter去重的对象仍然是request对象的fingerprint。更改后的代码如下:

    def request_seen(self, request):
        fp = request_fingerprint(request)
        if self.bf.isContains(fp):    # 如果已经存在
            return True
        else:
            self.bf.insert(fp)
            return False

self.bf是类Bloomfilter()的实例化,关于这个Bloomfilter()类,详见《基于Redis的Bloomfilter去重(附Python代码)》


以上,优化的思路和代码就是这样;以下将已有的七亿多的去重数据转成Bloomfilter去重。

  • 内存将爆,动作稍微大点机器就能死掉,更别说Bloomfilter在上面申请内存了。当务之急肯定是将那七亿多个fingerprint导出到硬盘上,而且不能用本机导,并且先要将redis的自动持久化给关掉。
  • 因为常用Mongo,所以习惯性首先想到Mongodb,从redis取出2000条再一次性插入Mongo,但速度还是不乐观,瓶颈在于MongoDB。(猜测是MongoDB对_id的去重导致的,也可能是物理硬件的限制)
  • 后来想用SSDB,因为SSDB和Redis很相似,用list存肯定速度快很多。然而SSDB唯独不支持Centos7,其他版本的系统都可。。
  • 最后才想起来用txt,这个最傻的方法,却是非常有效的方法。速度很快,只是为了防止读取时内存不足,每100万个fingerprint存在了一个txt,四台机器txt总共有七百个左右。
  • fingerprint取出来后redis只剩下一千多万的Request种子,占用内存9G+。然后用Bloomfilter将txt中的fingerprint写回Redis,写完以后Redis占用内存25G,开启redis自动持久化后内存占用49G左右。


福利福利:

献上Demo一个,链接:使用Bloomfilter去重的scrapy_redis

Demo功能:启动spider1(或spider2),start_urls中有10条URL,其中4条是重复的,可以看到 parse1() 只处理了去重后的6条URL。

Demo去重功能的迁移:

  • 将BloomfilterOnRedis_Demo目录下的 scrapy_redis 文件夹拷贝到你项目中settings.py的同级目录,在settings.py中增加几个字段:
FILTER_URL = None
FILTER_HOST = 'localhost'
FILTER_PORT = 6379
FILTER_DB = 0
# REDIS_QUEUE_NAME = 'OneName'   # 如果不设置或者设置为None,则使用默认的,每个spider使用不同的去重队列和种子队列。如果设置了,则不同spider共用去重队列和种子队列

"""
    这是去重队列的Redis信息。
    原先的REDIS_HOST、REDIS_PORT只负责种子队列;由此种子队列和去重队列可以分布在不同的机器上。
"""
  • 以上两个步骤即可实现BloomfilterOnRedis去重。(注意import scrapy_redis要改成import 项目名.scrapy_redis,即导入这个新的scrapy_redis,不要导错了!)
  • 特别说明一下REDIS_QUEUE_NAME这个字段。刚才放在demo里面的有spider1和spider2,分别启动一下两个爬虫,可以看到两个爬虫的去重队列和种子队列的名字是不一样的,即不是共用一个去重队列和种子队列的。如果项目需要,不同spider也要使用同一个去重队列和种子队列,则将这个REDIS_QUEUE_NAME设置成你想要的名字,此时同一个项目下的不同爬虫也会使用同一个去重队列和种子队列。
  • 如果待去重的数据量比较大,需要修改scrapy_redis/dupefilter.py中第14行的blockNum值,默认blockNum=1。Bloomfilter算法是有漏失概率的(即不存在的会误判为存在),在保证漏失率小于万分之一的情况下,一个blockNum可满足7千万条数据的去重,一个blockNum占用256M内存(注意Linux如果开了自动持久化,redis占用内存会加倍)。



转载请注明出处,谢谢!(原文链接:http://blog.csdn.net/bone_ace/article/details/53099042

没有更多推荐了,返回首页