布隆过滤器(Bloom Filter)

介绍：

　　布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

 应用例子：

  • 　网页URL的去重；
  • 　　垃圾邮件的判别；
  • 　　集合重复元素的判别；
  • 　　查询加速（比如基于key-value的存储系统）等。

 前提知识点：Bitset

　　Java BitSet可以按位存储，计算机中一个字节(byte)占8位(bit)；

　　而BitSet是位操作的对象，值只有0或1（即true 和 false），内部维护一个long数组，初始化只有一个long segement，所以BitSet最小的size是64；随着存储的元素越来越多，BitSet内部会自动扩充，一次扩充64位，最终内部是由N个long segement 来存储；

　　默认情况下，BitSet所有位都是0即false；基本原理是，用1位来表示一个数据是否出现过，0为没有出现过，1表示出现过。使用用的时候既可根据某一个是否为0表示此数是否出现过。

一个1G的空间，有 8*1024*1024*1024=8.58*10^9bit，也就是可以表示85亿个不同的数。

例子：

　　比如有一堆数字，需要存储，source=[3,5,6,9]
　　用int就需要4*4个字节。
　　java.util.BitSet可以存true/false。
　　如果用java.util.BitSet，则会少很多，其原理是：
　　　　1，先找出数据中最大值maxvalue=9
　　　　2，声明一个BitSet bs,它的size是maxvalue+1=10
　　　　3，遍历数据source，bs[source[i]]设置成true.
　　最后的值是： (0为false;1为true)
　　　　　　bs [ 0, 0, 0, 1, 0, 1, 1, 0, 0, 1]
                                        3,      5, 6,         9
　　这样一个本来要int型需要占4字节共32位的数字现在只用了1位！
　　比例32:1 
　　这样就省下了很大空间
　　通常用在数据统计、分析的领域

jdk实现BitSet底层为什么使用long，不用int？

　　JDK选择long数组作为BitSet的内部存储结构是出于性能的考虑，因为BitSet提供and和or这种操作，需要对两个BitSet中的所有bit位做and或者or，实现的时候需要遍历所有的数组元素。使用long能够使得循环的次数降到最低，所以Java选择使用long数组作为BitSet的内部存储结构。

　　从数据在栈上的存储来说，使用long和byte基本是没有什么差别的，除了编译器强制地址对齐的时候，使用byte最多会浪费7个字节(强制按照8的倍数做地址对其)，另外从内存读数组元素的时候，也是没有什么区别的，因为汇编指令有对不同长度数据的mov指令。所以说，JDK选择使用long数组作为BitSet的内部存储结构的根本原因就是在and和or的时候减少循环次数，提高性能。

布龙过滤器的原理

　　HashMap 的问题
　　讲述布隆过滤器的原理之前，我们先思考一下，通常你判断某个元素是否存在用的是什么？应该蛮多人回答 HashMap 吧，确实可以将值映射到 HashMap 的 Key，然后可以在 O(1) 的时间复杂度内返回结果，效率奇高。但是 HashMap 的实现也有缺点，例如存储容量占比高，考虑到负载因子的存在，通常空间是不能被用满的，而一旦你的值很多例如上亿的时候，那 HashMap 占据的内存大小就变得很可观了。

　　还比如说你的数据集存储在远程服务器上，本地服务接受输入，而数据集非常大不可能一次性读进内存构建 HashMap 的时候，也会存在问题。

布隆过滤器数据结构

　　布隆过滤器是一个 bit 向量或者说 bit 数组，长这样：

　

　　如果我们要映射一个值到布隆过滤器中，我们需要使用多个不同的哈希函数生成多个哈希值，并对每个生成的哈希值指向的 bit 位置 1，例如针对值 “baidu” 和三个不同的哈希函数分别生成了哈希值 1、4、7，则上图转变为：

　　Ok，我们现在再存一个值 “tencent”，如果哈希函数返回 3、4、8 的话，图继续变为：

　　值得注意的是，4 这个 bit 位由于两个值的哈希函数都返回了这个 bit 位，因此它被覆盖了。现在我们如果想查询 “dianping” 这个值是否存在，哈希函数返回了 1、5、8三个值，结果我们发现 5 这个 bit 位上的值为 0，说明没有任何一个值映射到这个 bit 位上，因此我们可以很确定地说 “dianping” 这个值不存在。而当我们需要查询 “baidu” 这个值是否存在的话，那么哈希函数必然会返回 1、4、7，然后我们检查发现这三个 bit 位上的值均为 1，那么我们可以说 “baidu” 存在了么？答案是不可以，只能是 “baidu” 这个值可能存在。

　　这是为什么呢？答案跟简单，因为随着增加的值越来越多，被置为 1 的 bit 位也会越来越多，这样某个值 “taobao” 即使没有被存储过，但是万一哈希函数返回的三个 bit 位都被其他值置位了 1 ，那么程序还是会判断 “taobao” 这个值存在。

如何选择哈希函数个数和布隆过滤器长度

　　很显然，过小的布隆过滤器很快所有的 bit 位均为 1，那么查询任何值都会返回“可能存在”，起不到过滤的目的了。布隆过滤器的长度会直接影响误报率，布隆过滤器越长其误报率越小。

另外，哈希函数的个数也需要权衡，个数越多则布隆过滤器 bit 位置位 1 的速度越快，且布隆过滤器的效率越低；但是如果太少的话，那我们的误报率会变高。

　　k 为哈希函数个数，m 为布隆过滤器长度，n 为插入的元素个数，p 为误报率。

如何选择适合业务的 k 和 m 值呢，这里直接贴一个公式：

如何推导这个公式这里只是提一句，因为对于使用来说并没有太大的意义，你让一个高中生来推会推得很快。k 次哈希函数某一 bit 位未被置为 1 的概率为：

(1-\frac{1}{m})^{k}

插入n个元素后依旧为 0 的概率和为 1 的概率分别是：

\left( 1-\frac{1}{m} \right)^{nk} 1- \left( 1-\frac{1}{m} \right)^{nk }

标明某个元素是否在集合中所需的 k 个位置都按照如上的方法设置为 1，但是该方法可能会使算法错误的认为某一原本不在集合中的元素却被检测为在该集合中（False Positives），该概率由以下公式确定

\left[ 1- \left( 1-\frac{1}{m} \right)^{nk} \right]^{k}\approx\left( 1-e^{-kn/m} \right)^{k}

 最佳实践

　　常见的适用常见有，利用布隆过滤器减少磁盘 IO 或者网络请求，因为一旦一个值必定不存在的话，我们可以不用进行后续昂贵的查询请求。

　　另外，既然你使用布隆过滤器来加速查找和判断是否存在，那么性能很低的哈希函数不是个好选择，推荐 MurmurHash、Fnv 这些。

大Value拆分

　　Redis 因其支持 setbit 和 getbit 操作，且纯内存性能高等特点，因此天然就可以作为布隆过滤器来使用。但是布隆过滤器的不当使用极易产生大 Value，增加 Redis 阻塞风险，因此生成环境中建议对体积庞大的布隆过滤器进行拆分。

　　拆分的形式方法多种多样，但是本质是不要将 Hash(Key) 之后的请求分散在多个节点的多个小 bitmap 上，而是应该拆分成多个小 bitmap 之后，对一个 Key 的所有哈希函数都落在这一个小 bitmap 上。

　　

资料：https://zhuanlan.zhihu.com/p/43263751　

posted @ 2019-05-02 15:46  myseries  阅读(6470)  评论(0)  编辑  收藏  举报