flink 使用布隆过滤器计算uv 布隆过滤器计数器

转载

晨曦微露s 2024-04-07 10:15:49

文章标签 flink 使用布隆过滤器计算uv bloom filter redis 数组 Redis 文章分类 架构后端开发

Bloom filter简介

关于布隆过滤器有众多文章做过介绍，这里不作详解，仅贴出简介：Bloom filter 是由 Howard Bloom 在 1970 年提出的二进制向量数据结构，它具有很好的空间和时间效率，被用来检测一个元素是不是集合中的一个成员。如果检测结果为是，该元素不一定在集合中；但如果检测结果为否，该元素一定不在集合中。因此Bloom filter具有100%的召回率。这样每个检测请求返回有“在集合内（可能错误）”和“不在集合内（绝对不在集合内）”两种情况，可见 Bloom filter 是牺牲了正确率和时间以节省空间。

flink 使用布隆过滤器计算uv 布隆过滤器计数器_redis

Bloom filter 优点就是它的插入和查询时间都是常数，另外它查询元素却不保存元素本身，具有良好的安全性。它的缺点也是显而易见的，当插入的元素越多，错判“在集合内”的概率就越大了，另外 Bloom filter 也不能删除一个元素，因为多个元素哈希的结果可能在 Bloom filter 结构中占用的是同一个位，如果删除了一个比特位，可能会影响多个元素的检测。

Counting Bloom filter

标准Bloom filter对于需要精确检测结果的场景将不再适用，而带计数器的Bloom filter的出现解决了这个问题。Counting Bloom filter实际只是在标准Bloom filter的每一个位上都额外对应得增加了一个计数器，在插入元素时给对应的 k （k 为哈希函数个数）个 Counter 的值分别加 1，删除元素时给对应的 k 个 Counter 的值分别减 1。

flink 使用布隆过滤器计算uv 布隆过滤器计数器_数组_02

Counting Bloom Filter通过多占用几倍的存储空间的代价，给Bloom Filter增加了删除操作。这其中最关键的问题是Counting Bloom filter需要增加多少存储量？在论文中给出了相关计算，假设counter数组的长度为m（对应bloom filter的位数组），Ci表示counter数组中第i个counter的大小，即哈希函数映射到第i位的次数，则每个counter最少位数N为：

flink 使用布隆过滤器计算uv 布隆过滤器计数器_redis_03

SBF（Spectral Bloom Filter）作为Counting Bloom Filter的一种实现，将所有counter排成一个位串，counter之间完全不留空隙，然后通过建立索引结构来访问counter，并达到了只使用O(N) + O(m)位的存储目标，O(m)的构建时间。虽然SBF解决了动态counter的存储问题，但其引入了复杂的索引结构，这让每个counter的访问变得复杂而耗时。

Dynamic Count Filter

为改进SBF的缺点，人们又发明了DCF（Dynamic Count Filter），其使用两个数组来存储所有的counter，它们的长度都为m（即bloom filter的位数组长度）。第一个数组是一个基本的CBF（即下图中的CBFV，counting bloom filter vector），counter的长度固定，为x = log(M/n)，其中M是集合中所有元素的个数，n为集合中不同元素的个数。第二个数组用来处理counter的溢出（即下图中的OFV，overflow vector），数组每一项的长度并不固定，根据counter的溢出情况动态调整。

flink 使用布隆过滤器计算uv 布隆过滤器计数器_flink 使用布隆过滤器计算uv_04

在查询一个counter时，DCF要求两次内存访问。假设想查询位置为j的counter的值，我们先读出CBFV和OFV的值，分别为Cj和OFj，那么counter的值就可以表示为Vj = (2x×OFj ＋ Cj)。

在集合增加元素时，如果OFV的最大值从2x – 1增加到2x，OFV就需要给每一项增加1位，否则就会溢出。对应的，当OFV的最大值从2x减少到2x – 1时，OFV就需要减少1位。每次OFV大小改变的时候都需要重新创建一个OFV数组，然后把旧OFV数组的值拷贝到新建的OFV数组中，最后把旧OFV数组的空间释放掉。对于减少的情况，可以采用一些策略延迟OFV的重建，以避免一些临时性的减少导致OFV反复重建。