Redis：HyperLogLog使用与应用场景

https://blog.csdn.net/maoyuanming0806/article/details/81814610

https://www.zhihu.com/question/65980801

Redis HyperLogLog介绍及应用

简介

Redis 在 2.8.9 版本添加了 HyperLogLog 结构

HyperLogLog 是用来做基数统计的算法，即对集合去重元素的计数

在输入元素的数量不超过2^64个，计算基数所需的内存最多12KB，该结构使用一种近似值算法，标准误差0.81%。

计算基数的方法分析

使用一般集合计算

随着统计元素的增加，内存消耗也剧增，资源消耗严重，不适合大数据量统计

bitmap

用位数组来表示各元素是否出现，每个元素对应一位，所需的总内存为n bit。能大大减少内存占用且位操作迅速。

如果要统计1亿个数据的基数值，大约需要内存100000000/8/1024/1024 ≈ 12M，内存减少占用的效果显著。然而统计一个对象的基数值需要12M，如果统计10000个对象，就需要将近120G，同样不能广泛用于大数据场景

但是这个方法是精确计算

概率算法

目前用于基数计数的概率算法包括:

• Linear Counting(LC)：早期的基数估计算法，LC在空间复杂度方面并不算优秀，实际上LC的空间复杂度与上文中简单bitmap方法是一样的（但是有个常数项级别的降低），都是O(Nmax)
• LogLog Counting(LLC)：LogLog Counting相比于LC更加节省内存，空间复杂度只有O(log2(log2(N​max)))
• HyperLogLog Counting(HLL)：HyperLogLog Counting是基于LLC的优化和改进，在同样空间复杂度情况下，能够比LLC的基数估计误差更小

算法白话说明

通俗点说明： 假设我们为一个数据集合生成一个8位的哈希串，那么我们得到00000111的概率是很低的，也就是说，我们生成大量连续的0的概率是很低的。生成连续5个0的概率是1/32，那么我们得到这个串时，可以估算，这个数据集的基数是32

应用场景

适用场景特点

• 非精确统计，HyperLogLog是近似值算法，有0.81%标准误差
• 数据量巨大，不大就用不上，大材小用，浪费空间
• 只能统计集合基数（去重）数量，而没办法去知道具体的内容，自然也没办法返回集合元素

应用场景举例

• 统计 IP 数
• 统计 UV 数
• 统计用户每天搜索不同词条个数

命令说明

pfadd

PFADD key element [element ...]

时间复杂度: O(1) to add every element

功能说明: 添加元素到计算空间

返回值

• 如果同时指定了key和element，那么如果执行命令后HyperLogLog的近视基数发生了变化，则返回1，否则返回0
• 如果只指定了key，那么如果Key存在，返回0，否则创建key，返回1

示例: PFADD hll a b c d e f g

PFCOUNT

PFCOUNT key [key ...]

时间复杂度

• 使用单个键调用时，O（1）的平均恒定时间非常短。
• 使用多个键时，O（N）N是键的数目，并且在使用多个键调用时，常数时间要大得多

功能说明: 计算传入的所有key对应的元素集合去重基数

返回值: 基数计数近似值（标准误差约0.81%）

示例: pfcount hll hll2

特别说明

作为调用此函数的副作用，HyperLogLog可能会被修改，因为后8个字节编码用于缓存目的的最新计算基数。因此从技术上讲PFCOUNT是写命令

当用单个键调用PFCOUNT时，性能也很出色，PFCOUNT使用缓存来记住先前计算的基数，这种变化很少改变，因为大多数PFADD操作不会更新任何寄存器

当PFCOUNT调用多个key时，HyperLogLogs需要合并计算，这是缓慢的，而且合并的基数不能被缓存，所以有多个key使用时PFCOUNT可能需要的时间在一个毫秒级的数量级，不应滥用

PFMERGE

PFMERGE destkey sourcekey [sourcekey ...]

时间复杂度: O（N）合并N个HyperLogLogs，但是具有恒定的时间

功能说明: 将sourcekey 合并到 destkey, 如果destkey不存在，则新创建一个空的HyperLogLog，如果destkey存在，则将其视为sourcekey之一

返回值: 只返回ok

示例: PFMERGE hll3 hll1 hll2

参考文章

Redis命令说明

Redis new data structure: the HyperLogLog

Redis：HyperLogLog使用与应用场景

神奇的HyperLogLog算法

 

 

作者：悬衡
链接：https://www.zhihu.com/question/65980801/answer/1055277576
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

HyperLogLog 就是专门用来估算基数（Distinct Value）的数据结构，而不是用来存具体内容。特点是非常的省内存，只占用固定几比特，就可以进行接近天文数字的基数估算。而 Set 和 SortedSet 进行数据存储时，占用的内存会随着存储元素的数量线性增长，当然，它存储的内容也更加详细。

HyperLogLog 的基本原理其实也不难理解，假设你抛了很多次硬币，你告诉在这次抛硬币的过程中最多只有两次扔出连续的反面，让我猜你总共抛了多少次硬币，我敢打赌你抛硬币的总次数不会太多，相反，如果你和我说最多出现了100次连续的反面，那么我敢肯定扔硬盘的总次数非常的多，甚至我还可以给出一个估计，这个估计要怎么给呢？其实是一个很简单的概率问题，假设1代表抛出正面，0代表反面：

1110100110

上图的抛硬币序列为例，其中最长的反面序列是"00"，我们顺手把后面那个1也给带上，也就是"001"，因为它包括了序列中最长的一串0，所以在序列中肯定只出现过一次，而它在任意序列出现出现且仅出现一次的概率显然是上图所示的三个二分之一相乘，也就是八分之一，所以我可以给出一个估计值，你大概总共抛了8次硬币。

 

这个抛硬币的序列和计数有什么关系呢？比如在数据库中，我只要在每次插入一条新的记录时，计算这条记录的hash，并且转换成二进制，就可以将其看成一个硬币序列了，比如：

hash(record) = 1110100110

这样我在内存中就只需要保存迄今为止所有记录 hash 的最长连续 0 的长度就可以了，达成了用固定比特长度进行任意大小的基数计算的小目标。

为了提升准确性，HyperLogLog 还会取 hash 的前几位作为桶标识进行分桶，在每个桶分别进行计数，取个平均作为最终结果。

HyperLogLog 结构的另一个特点，就是非常容易合并，只需要去对应桶中的最大值就可以了，比如 [1,2,1] merge [2,1,2] -> [2,2,2]。

现在我们再来理解一下 Redis HyperLogLog 结构的三个操作究竟是什么意思：

 

• PFADD hll ele：对 ele 算个 hash，找到它所属的桶，如果 ele 最长连续 0 的长度超过桶中所记录的最大值，则替换桶中原有值，否则直接忽略
• PFCOUNT hll：计算基数，每个桶的估计加起来取个平均
• PFMERGE hll3 hll1 hll2：将几个 HyperLogLog 结构合并，其实就是对应桶取最大值

 

Redis的所有HyperLogLog结构都是固定的16384个桶（2的14次方），并且有两种存储格式：

• 稀疏格式：HyperLogLog算法在刚开始的时候，大多数桶其实都是0，稀疏格式通过存储连续的0的数目，而不是每个0存一遍，大大减小了HyperLogLog刚开始时需要占用的内存
• 紧凑格式：用6个bit表示一个桶，需要占用12KB内存

可见在 Redis 中， HyperLogLog 结构最大内存占用不会超过 12KB。

 

为了回答得简洁明了，我对算法做了不少简化，如果想要了解更详细的内容的话，可以参考我的一篇文章：

悬衡：十分钟快速理解 HyperLogLog 算法​zhuanlan.zhihu.com