布隆过滤器(Bloom Filter)详解 布隆过滤器(Bloom Filter)详解

布隆过滤器(Bloom Filter)详解

2012-07-13 18:35 by Haippy, 29358 阅读, 6 评论, 收藏编辑html

 

布隆过滤器[1](Bloom Filter)是由布隆(Burton Howard Bloom)在1970年提出的。它其实是由一个很长的二进制向量和一系列随机映射函数组成,布隆过滤器能够用于检索一个元素是否在一个集合中。它的优势是空间效率和查询时间都远远超过通常的算法,缺点是有必定的误识别率(假正例False positives,即Bloom Filter报告某一元素存在于某集合中,可是实际上该元素并不在集合中)和删除困难,可是没有识别错误的情形(即假反例False negatives,若是某个元素确实没有在该集合中,那么Bloom Filter 是不会报告该元素存在于集合中的,因此不会漏报)。算法

在平常生活中,包括在设计计算机软件时,咱们常常要判断一个元素是否在一个集合中。好比在字处理软件中,须要检查一个英语单词是否拼写正确(也就是要判断 它是否在已知的字典中);在 FBI,一个嫌疑人的名字是否已经在嫌疑名单上;在网络爬虫里,一个网址是否被访问过等等。最直接的方法就是将集合中所有的元素存在计算机中,遇到一个新 元素时,将它和集合中的元素直接比较便可。通常来说,计算机中的集合是用哈希表(hash table)来存储的。它的好处是快速准确,缺点是费存储空间。当集合比较小时,这个问题不显著,可是当集合巨大时,哈希表存储效率低的问题就显现出来 了。好比说,一个象 Yahoo,Hotmail 和 Gmai 那样的公众电子邮件(email)提供商,老是须要过滤来自发送垃圾邮件的人(spamer)的垃圾邮件。一个办法就是记录下那些发垃圾邮件的 email 地址。因为那些发送者不停地在注册新的地址,全世界少说也有几十亿个发垃圾邮件的地址,将他们都存起来则须要大量的网络服务器。若是用哈希表,每存储一亿 个 email 地址, 就须要 1.6GB 的内存(用哈希表实现的具体办法是将每个 email 地址对应成一个八字节的信息指纹(详见:googlechinablog.com/2006/08/blog-post.html), 而后将这些信息指纹存入哈希表,因为哈希表的存储效率通常只有 50%,所以一个 email 地址须要占用十六个字节。一亿个地址大约要 1.6GB, 即十六亿字节的内存)。所以存贮几十亿个邮件地址可能须要上百 GB 的内存。除非是超级计算机,通常服务器是没法存储的[2]。(该段引用谷歌数学之美:http://www.google.com.hk/ggblog/googlechinablog/2007/07/bloom-filter_7469.html)数据库

基本概念

若是想判断一个元素是否是在一个集合里,通常想到的是将全部元素保存起来,而后经过比较肯定。链表,树等等数据结构都是这种思路. 可是随着集合中元素的增长,咱们须要的存储空间愈来愈大,检索速度也愈来愈慢。不过世界上还有一种叫做散列表(又叫哈希表,Hash table)的数据结构。它能够经过一个Hash函数将一个元素映射成一个位阵列(Bit Array)中的一个点。这样一来,咱们只要看看这个点是否是 1 就知道能够集合中有没有它了。这就是布隆过滤器的基本思想。数组

Hash面临的问题就是冲突。假设 Hash 函数是良好的,若是咱们的位阵列长度为 m 个点,那么若是咱们想将冲突率下降到例如 1%, 这个散列表就只能容纳 m/100 个元素。显然这就不叫空间有效了(Space-efficient)。解决方法也简单,就是使用多个 Hash,若是它们有一个说元素不在集合中,那确定就不在。若是它们都说在,虽然也有必定可能性它们在说谎,不过直觉上判断这种事情的几率是比较低的。浏览器

优势

相比于其它的数据结构,布隆过滤器在空间和时间方面都有巨大的优点。布隆过滤器存储空间和插入/查询时间都是常数。另外, Hash 函数相互之间没有关系,方便由硬件并行实现。布隆过滤器不须要存储元素自己,在某些对保密要求很是严格的场合有优点。缓存

布隆过滤器能够表示全集,其它任何数据结构都不能;安全

k 和 m 相同,使用同一组 Hash 函数的两个布隆过滤器的交并差运算可使用位操做进行。服务器

缺点

可是布隆过滤器的缺点和优势同样明显。误算率(False Positive)是其中之一。随着存入的元素数量增长,误算率随之增长。可是若是元素数量太少,则使用散列表足矣。网络

另外,通常状况下不能从布隆过滤器中删除元素. 咱们很容易想到把位列阵变成整数数组,每插入一个元素相应的计数器加1, 这样删除元素时将计数器减掉就能够了。然而要保证安全的删除元素并不是如此简单。首先咱们必须保证删除的元素的确在布隆过滤器里面. 这一点单凭这个过滤器是没法保证的。另外计数器回绕也会形成问题。数据结构

False positives 几率推导

假设 Hash 函数以等几率条件选择并设置 Bit Array 中的某一位,m 是该位数组的大小,k 是 Hash 函数的个数,那么位数组中某一特定的位在进行元素插入时的 Hash 操做中没有被置位的几率是:

那么在全部 k 次 Hash 操做后该位都没有被置 "1" 的几率是:

若是咱们插入了 n 个元素,那么某一位仍然为 "0" 的几率是:

于是该位为 "1"的几率是:

如今检测某一元素是否在该集合中。标明某个元素是否在集合中所需的 k 个位置都按照如上的方法设置为 "1",可是该方法可能会使算法错误的认为某一本来不在集合中的元素却被检测为在该集合中(False Positives),该几率由如下公式肯定:

其实上述结果是在假定由每一个 Hash 计算出须要设置的位(bit) 的位置是相互独立为前提计算出来的,不难看出,随着 m (位数组大小)的增长,假正例(False Positives)的几率会降低,同时随着插入元素个数 n 的增长,False Positives的几率又会上升,对于给定的m,n,如何选择Hash函数个数 k 由如下公式肯定:

此时False Positives的几率为:

而对于给定的False Positives几率 p,如何选择最优的位数组大小 m 呢,

上式代表,位数组的大小最好与插入元素的个数成线性关系,对于给定的 m,n,k,假正例几率最大为:

 

下图是布隆过滤器假正例几率 p 与位数组大小 m 和集合中插入元素个数 n 的关系图,假定 Hash 函数个数选取最优数目:

 

Bloom Filter 用例

Google 著名的分布式数据库 Bigtable 使用了布隆过滤器来查找不存在的行或列,以减小磁盘查找的IO次数[3]。

Squid 网页代理缓存服务器在 cache digests 中使用了也布隆过滤器[4]。

Venti 文档存储系统也采用布隆过滤器来检测先前存储的数据[5]。

SPIN 模型检测器也使用布隆过滤器在大规模验证问题时跟踪可达状态空间[6]。

Google Chrome浏览器使用了布隆过滤器加速安全浏览服务[7]。

在不少Key-Value系统中也使用了布隆过滤器来加快查询过程,如 Hbase,Accumulo,Leveldb,通常而言,Value 保存在磁盘中,访问磁盘须要花费大量时间,然而使用布隆过滤器能够快速判断某个Key对应的Value是否存在,所以能够避免不少没必要要的磁盘IO操做,只是引入布隆过滤器会带来必定的内存消耗,下图是在Key-Value系统中布隆过滤器的典型使用:

 

布隆过滤器相关扩展

 Counting filters

基本的布隆过滤器不支持删除(Deletion)操做,可是 Counting filters 提供了一种能够不用从新构建布隆过滤器但却支持元素删除操做的方法。在Counting filters中原来的位数组中的每一位由 bit 扩展为 n-bit 计数器,实际上,基本的布隆过滤器能够看做是只有一位的计数器的Counting filters。原来的插入操做也被扩展为把 n-bit 的位计数器加1,查找操做即检查位数组非零便可,而删除操做定义为把位数组的相应位减1,可是该方法也有位的算术溢出问题,即某一位在屡次删除操做后可能变成负值,因此位数组大小 m 须要充分大。另一个问题是Counting filters不具有伸缩性,因为Counting filters不能扩展,因此须要保存的最大的元素个数须要提早知道。不然一旦插入的元素个数超过了位数组的容量,false positive的发生几率将会急剧增长。固然也有人提出了一种基于 D-left Hash 方法实现支持删除操做的布隆过滤器,同时空间效率也比Counting filters高。

Data synchronization

Byers等人提出了使用布隆过滤器近似数据同步[9]。

Bloomier filters

Chazelle 等人提出了一个通用的布隆过滤器,该布隆过滤器能够将某一值与每一个已经插入的元素关联起来,并实现了一个关联数组Map[10]。与普通的布隆过滤器同样,Chazelle实现的布隆过滤器也能够达到较低的空间消耗,但同时也会产生false positive,不过,在Bloomier filter中,某 key 若是不在 map 中,false positive在会返回时会被定义出的。该Map 结构不会返回与 key 相关的在 map 中的错误的值。

Compact approximators[11]

Stable Bloom filters[12]

Scalable Bloom filters[13]

Attenuated Bloom filters[14]