注：布隆过滤是用来处理海量数据且允许存在误判

布隆过滤器提出

布隆过滤器概念

布隆过滤器的理论知识

布隆过滤器的实现

布隆过滤器的删除

布隆过滤器优点

布隆过滤器缺陷

布隆过滤器的应用场景

哈希切分

布隆过滤器/哈希切分面试题

布隆过滤器提出

我们在使用新闻客户端看新闻时，它会给我们不停地推荐新的内容，它每次推荐时要去重，去掉那些已经看过的内容。问题来了，新闻客户端推荐系统如何实现推送去重的？用服务器记录了用户看过的所有历史记录，当推荐系统推荐新闻时会从每个用户的历史记录里进行筛选，过滤掉那些已经存在的记录。如何快速查找呢？

用哈希表存储用户记录，缺点：浪费空间
用位图存储用户记录，缺点：位图一般只能处理整形，如果内容编号是字符串，就无法处理了。
将哈希与位图结合，即布隆过滤器

布隆过滤器概念

布隆过滤器是由布隆（Burton Howard Bloom）在1970年提出的一种紧凑型的、比较巧妙的概率型数据结构，特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”，它是用多个哈希函数，将一个数据映射到位图结构中。此种方式不仅可以提升查询效率，也可以节省大量的内存空间。

详解布隆过滤器的原理，使用场景和注意事项

布隆过滤器的理论知识

布隆过滤器的插入根据哈希函数将数据映射在比特位上，但是哈希无法避免的就是哈希冲突，只用一个哈希函数哈希冲突的概率很大：

从上图很明显发现，"@(#&$&("和"string"冲突了，映射到同一个比特位上，在插入时"@(#&$&("并没有插入该字符串，但是由于"@(#&$&("哈希值和"string"一样导致查找"@(#&$&("时被认为存在而误判，由于哈希中哈希冲突是无法避免的，这里只能去减小哈希冲突的概率，无法像哈希表那样完全解决。

所以，布隆过滤器的不存在是准确的，存在是“可能存在”的。

实现上：

增加布隆过滤器的长度
减小哈希冲突可以多增加哈希函数，让一个字符串映射多个位置，达到减小哈希冲突的结果如下图

如上图，一个key映射多个比特位降低了误判的概率，但是误判在所难免，当一个key映射三个比特位时，只有三个比特位都满足才判断存在，但是可能会出现上图情况，"@(#&$&("的哈希值在前三个字符串都出现过，导致的误判。

事实上并非一味增加布隆过滤器长度或者增加哈希函数的个数就是好的

布隆过滤器的长度会直接影响误报率，布隆过滤器越长其误报率越小，但是占用的空间会随着布隆过滤器的长度而增加；过小的布隆过滤器很快所有的bit位均为 1，那么查询任何值都会返回“可能存在”，起不到过滤的目的了。

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

对于如何取舍布隆过滤器的长度和哈希函数的个数：

上图是大佬们整理的哈希函数个数，布隆过滤器，插入元素个数，误报率之间的影响图

上图是大佬们对如何选择适合业务的k和m值，推导出的公式

（若想更直观看几个之间的关系则可以参考Bloom Filters - the math）

我们可以根据实际业务需求根据上面的公式来设置我们需要的k和m

PS：哈佛大学的一篇论文Building a better bloom filter中指出布隆过滤器的哈希函数只需要两个即可，哈希函数多了反而会增加误判率

论文链接：Building a better bloom filter

有了以上的理论知识，我们知道：

布隆过滤器的思想是将一个元素用多个哈希函数映射到一个位图中，因此被映射到的位置的比特位一定为1。所以可以按照以下方式进行查找：分别计算每个哈希值对应的比特位置存储的是否为零，只要有一个为零，代表该元素一定不在哈希表中，否则可能在哈希表中。

注意：布隆过滤器如果说某个元素不存在时，该元素一定不存在，如果该元素存在时，该元素可能存在，因为有些哈希函数存在一定的误判。

布隆过滤器的实现

#pragma once 
#include <string>
#include <iostream>
#include <bitset>
using namespace std;

namespace mystl
{

  struct BKDRHash
  {
    size_t operator()(const string& s)
    {
      size_t hashi = 0;
      for(auto& ch : s)
        hashi = hashi * 131 + ch;
      return hashi;
    }
  };

  struct SDBMHash
  {
    size_t operator()(const string& s)
    {
      size_t hashi = 0;
      for(auto& ch : s)
        hashi = hashi * 65599 + ch;
      return hashi;
    }
  };

  //M：布隆过滤器长度
  //布隆过滤器一般用来处理字符串，默认给string
  template<size_t M, class K = string, class HashFunc1 = BKDRHash, class HashFunc2 = SDBMHash>
  class BoolmFilter
  {
  public:
    void set(const K& key)
    {
      size_t hash1 = HashFunc1()(key) % M;//计算位置1
      size_t hash2 = HashFunc2()(key) % M;//计算位置2
  
      _bs.set(hash1);
      _bs.set(hash2);
    }

    bool test(const K& key)
    {
     //只要有一个位置不满足要求就不是我们要找的
      size_t hash1 = HashFunc1()(key) % M;
      if(!_bs.test(hash1))
        return false;
      size_t hash2 = HashFunc2()(key) % M;
      if(!_bs.test(hash2))
        return false;
      //即使全部满足也存在误判
      return true;//存在误判
    }

  private:
    bitset<M> _bs;//位图
  };
}

这里使用的哈希函数由各种字符串Hash函数提供。

布隆过滤器的删除

面试题：

如何扩展BloomFilter使得它支持删除元素的操作

布隆过滤器不能直接支持删除工作，因为在删除一个元素时，可能会影响其他元素

比如：删除"string"元素，如果直接将该元素所对应的二进制比特位置0，“hashfunc”元素也可能被删除，因为这两个元素在多个哈希函数计算出的比特位上如果刚好有重叠。

一种支持删除的方法：将布隆过滤器中的每个比特位扩展成一个小的计数器，插入元素时给k个计数器(k个哈希函数计算出的哈希地址)加一，删除元素时，给k个计数器减一，通过多占用几倍存储空间的代价来增加删除操作。

删除的缺陷：

无法确认元素是否真正在布隆过滤器中
会出现如下图情况，待查找字符串并不在布隆过滤器中，删除了哈希值对应的bit反而会删除错已存储字符串的bit

存在计数回绕

已存储字符串中多个字符串映射到同一个bit导致删除“不干净”，如下图：

将12，32，43删除后"@(#&$&("查找仍然存在，虽然是误判导致的，但是也确实存在该问题；当然存在删除后将别的字符串给删除的可能（恰好该字符串与其他元素映射到同样的bit上，但是该字符串并不存在然后执行了删除操作将其他字符串给删除了）

要想删除一个元素就是要将哈希值对应的全部比特位置0，即标记为存计数，但是空间会暴涨，1bit标识一个位置/8bit标识一个位置（0~255）/16bit标识一个位置（0~65535），一般要实现删除设置8bit标识一个位置，可以看得出来空间是会暴涨很多，会违背使用布隆过滤器的初衷（占用少的空间）

也正是因为上面的情况，所以布隆过滤器的删除并不是很好的操作，而且布隆过滤器是为了过滤并不是为了删除，所以一般并不会实现删除这个操作，这里只做介绍不实现。

布隆过滤器优点

增加和查询元素的时间复杂度为:O(K), (K为哈希函数的个数，一般比较小)，与数据量大小无
关
哈希函数相互之间没有关系，方便硬件并行运算
布隆过滤器不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势
在能够承受一定的误判时，布隆过滤器比其他数据结构有这很大的空间优势
数据量很大时，布隆过滤器可以表示全集，其他数据结构不能
使用同一组散列函数的布隆过滤器可以进行交、并、差运算

布隆过滤器缺陷

有误判率，即存在假阳性(False Position)，即不能准确判断元素是否在集合中(补救方法：再建立一个白名单，存储可能会误判的数据)
不能获取元素本身
一般情况下不能从布隆过滤器中删除元素
如果采用计数方式删除，可能会存在计数回绕问题

布隆过滤器的应用场景

注册时快速判断一个昵称是否被使用过

不在，没有使用过直接使用；在，再去数据库中查找确认

黑名单

不在，通行；在，再去数据库中查找确认

过滤层，提高查找数据效率

使用布隆过滤器，当数据不在时直接返回结果；在时，再去数据库中查找数据确认

哈希切分

面试题：

给一个超过100G大小的log file，log中存着IP地址，设计算法找到出现次数最多的IP地址？
如何找到topK的IP？如何直接用Linux系统命令实现？

思路：将文件分成多个文件统计。

但是平分成多个文件是不对的，因为相同的ip可能会被分到不同的文件中，如果相同的ip被分到不同的文件中，统计的是就是错的，但是遇到相同也不能将两个文件合并，不然分成多个文件就没意义了

所以此时需要使用哈希切割，使用哈希函数进行切割，依次从文件中读取ip，hashi = HashFunc(ip) % 100（假设分成100个文件），就会切割成100个小文件，相同的ip一定进入相同的小文件（ip相同一定映射到同一个文件中），不同的ip可能会进入同一个小文件中

使用map<string, int> countmap依次对每个小文件统计次数，统计完再调用countmap.clear()清理掉再统计另一个文件，使用pair<ip, int> maxip寻找次数最多的ip，建小堆priority_queue<pair<ip, int>, greater> minHeap找出次数topK的ip

但是上面仍然存在问题：

某个相同ip太多
映射冲突到这个编号文件的ip太多

导致某个小文件太大，第一个问题可以通过只增加计数处理，第二个问题只能针对当前的小文件再次使用新的哈希函数进行哈希切分，分成另外一堆小文件进行处理

解决方法：

使用异常，通过捕获内存不足的异常来处理上面的问题

try {
    countmap[ip]++;
} catch (exception& e) {
    //捕获内存不足的异常，说明内存不够
    countmap.clear();//将之前的统计清空
    //针对这个小文件，再次更换哈希函数，进行哈希切分，再切分成小文件
    //再对小文件依次统计
}

Linux命令实现：

cat file.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n K

这将输出出现次数最多的前K个IP地址。其中，file.log是你的日志文件名，K是你想要查找的IP地址数量。

上面是针对数据量并不是很大的处理，针对数据量大还是得和上面一样处理，即使用分布式算法——哈希分桶法
Hash分桶法：

将100G文件分成1000份，将每个IP地址映射到相应文件中：file_id = HashFunc(ip) % 1000
在每个文件中分别求出最高频的IP，再合并Hash分桶法
使用Hash分桶法把数据分发到不同文件
各个文件分别统计topK
最后TopK汇总

假设求top10：
sort log_file | uniq -c | sort -nr k1,1 | head -10