海量数据处理——布隆过滤器（Bloom Filter）
Bloom Filter是1970年由Bloom提出的，最初广泛用于拼写检查和数据库系统中。近年来，随着计算机和互联网技术的发展，数据集的不断扩张使得Bloom Filter获得了新生，各种新的应用和变种不断涌现。Bloom Filter是一个空间效率很高的随机数据结构，它由一个位数组和一组hash映射函数组成。Bloom Filter可以用于检索一个元素是否在一个集合中，它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率。因此Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下,Bloom Filter通过极少的错误换取了存储空间的极大节省。
（1）实例比较
假设要你写一个网络蜘蛛（web crawler）。由于网络间的链接错综复杂，蜘蛛在网络间爬行很可能会形成“环”。为了避免形成“环”，就需要知道蜘蛛已经访问过那些URL。给一个URL，怎样知道蜘蛛是否已经访问过呢？稍微想想，就会有如下几种方案：
1. 将访问过的URL保存到数据库。
2. 用HashSet将访问过的URL保存起来。那只需接近O(1)的代价就可以查到一个URL是否被访问过了。
3. URL经过MD5或SHA-1等单向哈希后再保存到HashSet或数据库。
4. Bit-Map方法。建立一个BitSet，将每个URL经过一个哈希函数映射到某一位。
方法1~3都是将访问过的URL完整保存，方法4则只标记URL的一个映射位。以上方法在数据量较小的情况下都能完美解决问题，但是当数据量变得非常庞大时问题就来了：
方法1的缺点：数据量变得非常庞大后关系型数据库查询的效率会变得很低。而且每来一个URL就启动一次数据库查询是不是太小题大做了？
方法2的缺点：太消耗内存。随着URL的增多，占用的内存会越来越多。就算只有1亿个URL，每个URL只算50个字符，就需要5GB内存。
方法3：由于字符串经过MD5处理后的信息摘要长度只有128Bit，SHA-1处理后也只有160Bit，因此方法3比方法2节省了好几倍的内存。
方法4消耗内存是相对较少的，但缺点是单一哈希函数发生冲突的概率太高。还记得数据结构课上学过的Hash表冲突的各种解决方法么？若要降低冲突发生的概率到1%，就要将BitSet的长度设置为URL个数的100倍。
实质上上面的算法都忽略了一个重要的隐含条件：允许小概率的出错，不一定要100%准确！也就是说少量url实际上没有没网络蜘蛛访问，而将它们错判为已访问的代价是很小的——大不了少抓几个网页呗。
（2）Bloom Filter定义
Bloom Filter是一个有m位的位数组，初始全为0，并有k个各自独立的哈希函数。
（注：Bloom Filter跟单哈希函数Bit-Map不同之处在于：Bloom Filter使用了k个哈希函数，每个字符串跟k个bit对应。从而降低了冲突的概率）
添加操作：
每个元素，用k个哈希函数计算出大小为k的哈希向量（h1,h2...hk），将向量里的每个哈希值对应的位设置为1。时间复杂度为o(n)，一般字符串哈希函数的时间复杂度也就是o(n)。
查询操作：和添加类似,先计算出哈希向量，如果每个哈希值对应的位都为1，则该元素存在。时间复杂度与添加操作相同。
（3）False Position
如果某元素不在Bloom Filter中，但是它所有哈希值的位置均被设为1。这种情况就是False Position，也就是误判。Bloom Filter允许这种情况发生，且不可避免，我们关心的是False Position发生的概念，如何使其降低到最小。
1）哈希函数的选择
哈希函数的选择对性能的影响应该是很大的，一个好的哈希函数要能近似等概率的将字符串映射到各个Bit。选择k个不同的哈希函数比较麻烦，一种简单的方法是选择一个哈希函数，然后送入k个不同的参数。
2）bit数组大小的选择
哈希函数个数k、位数组大小m及字符串数量n之间存在相互关系。相关文献证明了对于给定的m、n，当 k = ln(2)* m/n 时出错的概率是最小的。
（4）优缺点
优点：
查询操作十分高效
节省空间
易于扩展成并行
集合计算方便
代码实现方便
缺点：
有误判的概率，即存在False Position
无法获取集合中的元素数据
不支持删除操作（删除会影响其他字符串）
- 注：对于不支持删除操作，现在对其进行了扩展：Counting bloomfilter(CBF)，这是一种基本Bloom Filter的变体，CBF将基本Bloom Filter每一个Bit改为一个计数器，这样就可以实现删除字符串的功能了。
（5）实际应用
1）加速查询
适用于一些key-value存储系统，当values存在硬盘时，查询就是件费时的事。将Storage的数据都插入Filter，在Filter中查询都不存在时，那就不需要去Storage查询了。当False Position出现时，只是会导致一次多余的Storage查询。其示意图：
如：Google的BigTable也使用了Bloom Filter，以减少不存在的行或列在磁盘上的查询，大大提高了数据库的查询操作的性能。
Internet Cache Protocol中的Proxy-Cache很多都是使用Bloom Filter存储URLs，除了高效的查询外，还能很方便得传输交换Cache信息。
2）网络应用
P2P网络中查找资源操作，可以对每条网络通路保存Bloom Filter，当命中时，则选择该通路访问。
广播消息时，可以检测某个IP是否已发包。
检测广播消息包的环路，将Bloom Filter保存在包里，每个节点将自己添加入Bloom Filter。
信息队列管理，使用Counter Bloom Filter管理信息流量。
3）垃圾邮件地址过滤
像网易，QQ这样的公众电子邮件（email）提供商，总是需要过滤来自发送垃圾邮件的人（spamer）的垃圾邮件。一个办法就是记录下那些发垃圾邮件的email 地址。由于那些发送者不停地在注册新的地址，全世界少说也有几十亿个发垃圾邮件的地址，将他们都存起来则需要大量的网络服务器。如果用哈希表，每存储一亿个 email 地址，就需要1.6GB 的内存（用哈希表实现的具体办法是将每一个email 地址对应成一个八字节的信息指纹，然后将这些信息指纹存入哈希表，由于哈希表的存储效率一般只有50%，因此一个email 地址需要占用十六个字节。一亿个地址大约要1.6GB， 即十六亿字节的内存）。因此存贮几十亿个邮件地址可能需要上百GB 的内存。而Bloom Filter只需要哈希表1/8 到1/4 的大小就能解决同样的问题。Bloom Filter决不会漏掉任何一个在黑名单中的可疑地址。而至于误判问题，常见的补救办法是在建立一个小的白名单，存储那些可能别误判的邮件地址。
（6）代码实现
代码实现请见：http://blog.csdn.net/forestlight/article/details/6839180 ，该文章中给出了一个比较详细的实现用例，其中有几个难点：
1）Bloom Filter的创建函数BLOOM *bloom_create(size_t size, size_t nfuncs, ...)；这是一个可变参数函数，里面涉及了可变参数的内容，如vg_list,vg_start,vg_arg,vg_end这些，可参考上一篇文章“关于C、C++中可变参数的简介——(va_list,va_start,va_arg,va_end)”。
2） 关于typedef unsigned int (*hashfunc_t)(const char *); 这是一个函数类型的指针，可参考以前写的“指针函数 vs 函数指针” 。
