最靠谱的是hyperloglog库，纯Python实现、无C依赖、API极简；默认precision=10，误差约±1.5%，内存约12KB；精度可调，但需权衡误差与内存。
HyperLogLog在Python里用哪个库最靠谱？
Python标准库不带HyperLogLog，redis-py自带pfadd/pfcount但只限Redis服务端；本地内存估算得靠第三方。目前最成熟的是hyperloglog（PyPI上同名包），纯Python实现、无C依赖、API极简，比pyhll更轻量，也比自己用bitarray手撸更稳。
- 安装：
pip install hyperloglog - 初始化：
hll = HyperLogLog()，默认误差率约0.81%，内存占用约12KB - 如果你对精度敏感，可显式指定
HyperLogLog(precision=14)（precision范围10–16，每+1内存×2，误差率÷√2）
往HLL里加UV时，为什么必须用字符串且要一致哈希？
HyperLogLog内部对输入做hash(value) & 0xffffffff，再取低p位作桶索引，高(32−p)位算零前缀长度。如果传入对象类型不统一（比如有时传int用户ID，有时传str邮箱），Python的hash()行为在不同进程/Python版本下不一致，导致同一UV被算作多个值。
- 必须统一转成字符串：
hll.add(str(user_id))或hll.add(email.strip().lower()) - 避免直接传
bytes，因为hash(b"123") != hash("123") - 如果UV来自数据库整型ID，别图省事写
hll.add(user_id)——看似能跑，实则跨机器结果不可复现
单机HLL和分布式场景下的merge陷阱
HyperLogLog支持hll1.update(hll2)合并，这是它能用于分片统计的关键。但注意：
- 合并是“无损”的：A.merge(B)后，A的估算值 ≈ A∪B的真实基数
- 不能靠
len(set(all_items))验证合并结果——数据量大时根本跑不完 - 分布式下常见错误：各worker各自初始化
HyperLogLog()，处理完发回主节点合并；但如果某个worker中途崩溃重跑，而没清空旧HLL状态，就会重复计数 - 更稳妥的做法：每个worker输出序列化后的
hll.digest()（bytes），主节点用HyperLogLog.from_bytes()重建再merge，避免状态污染
误差有多大？什么时候不该用HLL？
官方文档说相对标准误差≈1.04/√2^p。用默认precision=10（即1024个桶）时，误差约±1.5%；设为14时降到±0.2%，但内存涨到192KB。
立即学习“Python免费学习笔记（深入）”；
- 适合场景：日活/周活统计、AB测试分流去重、实时大屏UV趋势
- 不该用的场景：
- UV量级小于1万——此时
set()内存开销更低，且绝对准确 - 需要精确知道“哪些UV重复了”——HLL只回答“有多少”，不存原始值
- 要求误差<0.1%且UV超10亿——考虑
HyperLogLog++（datasketch库支持），它修正了小集合偏差和稀疏区估计
- UV量级小于1万——此时
实际部署时最容易忽略的一点：HLL对象本身不序列化其内部桶数组的稀疏表示，pickle保存的是全量数组。如果用precision=14，单个HLL pickle后体积近200KB，高频存取会吃I/O。真要持久化，优先用digest() + from_bytes()。
