不简单的URL去重

发现我有好几篇blog的前缀都是用的“不简单”,它大概描述了这样一个状态:一个看起来很简单的任务在实践之后,发现其实很不容易。很多事情都是这样,如果不是亲自去做,如果不是仔细钻研,那就只能处于雾里看花的状态。
这让我想到另一个故事,在我毕业的那年曾经被某公司的CTO面试,他和我说过一句话让我至今记忆犹新,他跟我说技术其实是很简单的(几年后某位大牛也和我表达过类似的意思)。我一直琢磨这句话的含义,现在理解,他的意思应该是指无论多难的技术,只要你用心,总是能够学习和掌握的。

简单或者不简单,其实不是技术,而是我们做事的态度。

言归正传。
所谓的Url去重(我一直没找到对应的英文,URL Filtering ?),就是爬虫将重复抓取的URL去除,避免多次抓取同一网页。爬虫一般会将待抓取的URL放在一个队列中,从抓取后的网页中提取到新的URL,在他们被放入队列之前,首先要确定这些新的URL没有被抓取过,如果之前已经抓取过了,就不再放入队列。

最直观的做法 – hash表

为了尽快把整个爬虫搭建起来,最开始的URL去重采用方案是一个内存中的HashSet,这是最直观的方法,所有人都能想得到。HashSet中放置的就是URL的字符串,任何一个新的URL首先在HashSet中进行查找,如果HashSet中没有,就将新的URL插入HashSet,并将URL放入待抓取队列。
这个方案的好处是它的去重效果精确,不会漏过一个重复的URL。它的缺点是,我的爬虫第二天早上就挂了,Out Of Memory。因为随着抓取网页的增加,HashSet会一直无限制的增长。另外,网络中的很多URL其实是很长的,有大量的URL长度达到上百个字符。当然,因为我的爬虫是跑在一个小服务器上,JVM的内存本来就不多,否则它应该能再多撑1-2天。
简单估算一下,假设单个URL的平均长度是100 byte(我觉着这已经非常保守了),那么抓取1000万的URL就需要:
    100 byte * 10 000 000 = 1 GB
而1000万URL在整个互联网中实在是沧海一粟。可以了解,需要多大的内存才能装下所有URL的HashSet。

压缩URL

为了我的爬虫能再多撑几天,同时不想改动太多的代码,第二个版本增加了一个小功能,就是HashSet中不存储原始的URL,而是将URL压缩后再放进去。貌似有不少paper中讨论过如何对URL进行压缩,包括新浪微博中的短URL其实也是个不错的方案,可惜这些方法我都不会。为了偷懒,我直接用MD5对URL做编码。
MD5的结果是128 bit也就是16 byte的长度。相比于之间估计的URL平均长度100byte已经缩小了好几倍,可以多撑好多天了。
当然,哪怕找个一个可以压缩到极致的算法,随着URL越来越多,终有一天会Out Of Memory。所以,这个方案不解决本质问题。
MD5另外一个问题是,有可能两个相同的URL被映射成同一个MD5值,这样的话,它们中有一个就永远不会被抓取了。我不太确定的是,这个概率会有多大。如果非常小的话,这微小的误差倒也不会有太大影响。

Bloom Filter

基于内存的HashSet的方法存在一个本质的问题,就是它消耗的内存是随着URL的增长而不断增长的。除非能够保证内存的大小能够容纳下所有需要抓取的URL,否则这个方案终有一天会到达瓶颈。
这时候就会想,要找一个类似于HashSet的但所消耗的内存相对固定而不会不断增长的方案,于是自然想到了Bloom Filter。关于Bloom Filter的概念这里就不多谈了,网上随处可以找到。我简单尝试了一下Bloom Filter,但是很快就放弃了。基于Bloom Filter的方案有几个问题:
第一个是理论上的。Bloom Filter会将一些正常的样本(在我这就是没有抓取过的URL)过滤掉,即所谓的False Positive。当然,这概率有多大,取决于Bloom Filter的参数设置。但这引出了下一个问题;
第二个是实践中的,即Bloom Filter的那几个参数应该如何设置?m,k,n应该设置成多少才合适,这个我没有经验,而且可能需要反复的实验和测试才能够比较好的确定下来;
以上两个问题还不是我放弃Bloom Filter的根本原因,真实的原因是我在做的是一个爬虫框架,上面可以会启动很多的爬虫任务,每个任务可能抓取自己特定的URL,而且任务之间是独立的。这样,对于每个任务都需要有一个Bloom Filter,虽然对于单一任务它使用Bloom Filter所消耗的内存是固定的,但是任务的增多会导致更多的Bloom Filter,从而导致更多的内存消耗。仍然存在内存溢出的可能。
但如果只是一个抓取任务,那么采用Bloom Filter应该是一个非常不错的选择。

BerkeleyDB

我终于明白我所需要的其实是一个可以放在disk上的去重方案,这样,内存溢出将永远成不了可能。很早就知道有BerkeleyDB这么一个东西,但第一次真正了解还是在Amazon的Dynamo那篇论文中提到过采用了BerkeleyDB作为单机上的底层存储。当时觉着这东西真另类,原来还有叫做“DB”的东西却不支持SQL。那时候还没有NOSQL这词,把这样的东西叫做non-relational database。
BerkeleyDB是一个key-value database,简单的说,就是一个在disk上的hash表,这也是为什么它可以被用来做URL去重的原因。它另外一个另类的地方是,它是和程序运行在同一个进程空间中的,而不像一般的db,是做为单独的程序运行。
这里附上Heritrix中使用BerkeleyDB做URL去重的代码,一探究竟:(代码位于Heritrix源代码的org.archive.crawler.util.BdbUriUniqFilter)

有一堆做初始化和配置的函数就直接忽略了,真正相关的函数就只有两个:

    /**
     * Create fingerprint.
     * Pubic access so test code can access createKey.
     * @param uri URI to fingerprint.
     * @return Fingerprint of passed <code>url</code>.
     */
    public static long createKey(CharSequence uri) {
        String url = uri.toString();
        int index = url.indexOf(COLON_SLASH_SLASH);
        if (index > 0) {
            index = url.indexOf('/', index + COLON_SLASH_SLASH.length());
        }
        CharSequence hostPlusScheme = (index == -1)? url: url.subSequence(0, index);
        long tmp = FPGenerator.std24.fp(hostPlusScheme);
        return tmp | (FPGenerator.std40.fp(url) >>> 24);
    }

    /**
     * value: only 1 byte
     */
    private static DatabaseEntry ZERO_LENGTH_ENTRY = new DatabaseEntry(
            new byte[0]);

    protected boolean setAdd(CharSequence uri) {
        DatabaseEntry key = new DatabaseEntry();
        LongBinding.longToEntry(createKey(uri), key);
        long started = 0;
        
        OperationStatus status = null;
        try {
            if (logger.isLoggable(Level.INFO)) {
                started = System.currentTimeMillis();
            }
            status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);
            if (logger.isLoggable(Level.INFO)) {
                aggregatedLookupTime +=
                    (System.currentTimeMillis() - started);
            }
        } catch (DatabaseException e) {
            logger.severe(e.getMessage());
        }
        if (status == OperationStatus.SUCCESS) {
            count++;
            if (logger.isLoggable(Level.INFO)) {
                final int logAt = 10000;
                if (count > 0 && ((count % logAt) == 0)) {
                    logger.info("Average lookup " +
                        (aggregatedLookupTime / logAt) + "ms.");
                    aggregatedLookupTime = 0;
                }
            }
        }
        if(status == OperationStatus.KEYEXIST) {
            return false; // not added
        } else {
            return true;
        }
    }

简单解释一下:

第一个函数createKey是在做URL的压缩,它将任意长度的URL转换成一个long型的值。long型的取值范围有2^64,因此两个URL映射成同一个long型值的概率应该挺低的。但我也没太细看这个函数,所以它的效果到底如何不确定。

第二个函数setAdd就是将被压缩的URL写入到BerkeleyDB。之前说过,BerkeleyDB是一个key-value database,它的每条记录都包括了一个key和一个value。但是在URL去重中,value不重要(比如我们之前内存中用的也是HashSet而不是HashMap),因此这里统一用一个byte长度的值来表示value,就是这个static变量ZERO_LENGTH_ENTRY。

别看setAdd有这么多行,真正有用的就这一行:

status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);
将压缩后得到的long型值作为key,ZERO_LENGTH_ENTRY作为value插入到BerkeleyDB中,如果db中已经有了这个long型值,就会返回OperationStatus.KEYEXIST,表示对应的URL之前已经抓取到了,那么这个URL就不会放入待抓取队列中。

最后

比较遗憾的是,我还没抽出空对BerkeleyDB这个方案做性能测试,不确定它每秒能执行多少次setAdd操作,是否足够满足我们性能的要求。以后补上。

另外,虽然我不了解,但我认为像百度这样专业的搜索引擎,它的爬虫的URL去重方案可能比这里列举的要复杂的多,毕竟那个的各方面的要求也要更高。






发布了95 篇原创文章 · 获赞 114 · 访问量 117万+
展开阅读全文

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

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览