《Redis深度历险》HyperLogLog

HyperLogLog

基本使用

如果需要统计UV（每日访问用户数），而不需要过于精确数据量又比较大的情况下可以采用这种结构，它的标准误差为0.81%，但是set结构要节省空间。
它是Redis的一种高级数据结构。
使用pfadd key element [element...] 来向key中增添emement（可增添多个）
使用pfcount key获取数量
可就能够很好的解决日活用户的问题
还有pfmerge destkey sourcekey [sourcekey....]可用于汇总多个pf计数，注意这是有误差的，所以如果destkey远大于sourcekey，那么就可能莫得效果，还是原值，相反被误差掉的就是原值了。

用脚本测一波准确率还是挺高的。

import redis.clients.jedis.Jedis;
/**
 * @创建人 YDL
 * @创建时间 2020/6/12 3:18
 * @描述
 */
public class PfTest {
    public static void main(String[] args) {
        try(Jedis jedis = new Jedis()) {
            jedis.del("set");
            for (int i = 0; i < 100000; i++) {
                jedis.pfadd("set", "user" + i);
            }
            System.out.println(100000+" "+jedis.pfcount("set"));
            for (int i = 0; i < 100000; i++) {
                jedis.pfadd("set", "user" + i);
            }
            System.out.println(100000+" "+jedis.pfcount("set"));
        }
    }
}

实现原理

哇？书中给个图然后给个实验代码就算讲完了？让我自己去悟嘛？？？
参考了这篇文章
我大概有点意会了，它是基于这样的假设，当某个随机数为某值时比较大概率是进行了n次操作（可类比为抛硬币，因为计算机中的二进制与硬币的正反是对应的，如果连续两次为正面那么抛的次数不会太多，如果连续99次为正面那个次数肯定会很多了）
当然如果只基于“一次”抛全部硬币的就作为判断肯定是误差极大的（划分不精细），那么比较常规的思路就是多次求和取平均，但是一些极端值的存在会严重影响到输出结果(因为极端值的出现的概率较小)，所以就使用调和平均数，相对比较偏向大多数值。

书中代码

这相当于只抛一次n枚硬币的代码，如果某个值介于2^k~2^k+1直接那么它们就算同样的数，但是这样误差肯定会很大

public class PfTest {
   
    static class BitKeeper{
        private int maxbits;
        获取一个随机数然后求取该随机数的前导0，如果前导0大于了之前的前导0则更新
        public void random(){
            long value = ThreadLocalRandom.current().nextLong(2L<<32);
            int bits = lowZeros(value);
            if(bits>this.maxbits)
                this.maxbits =bits;
        }
        //获取低位的0的数量，对应前导0
        private int lowZeros(long value){
            int i =1;
            for(;i<32;i++){
                if(value>>i<<i!=value){
                    break;
                }
            }
            return i-1;
        }
    }
    static class Experiment{
        private int n;
        private BitKeeper keeper;
        public Experiment(int n){
            this.n = n;
            this.keeper = new BitKeeper();
        }

        public void work(){
        等价于一次抛n个硬币
            for(int i=0;i<n;i++){
                this.keeper.random();
            }
        }
        public void debug(){
            System.out.printf("%d %.2f %d\n",
                    this.n,Math.log(this.n)/Math.log(2),
                    this.keeper.maxbits);
        }
    }
    @Test
    public void test(){
        for(int i=1000;i<100000;i+=100){
            Experiment exp = new Experiment(i);
            exp.work();
            exp.debug();
        }
    }
}

实验结果发现，硬币的数量n与随机数最大前导0的2^k 近似相等。
n介于2^k~2^k+1之间。

这个相当于分桶（多次计算）+求调和平均数（Hn=n/(1/a1+1/a2+…+1/an)），这个算法会比较偏向于比较集中的数字

public class PfTest {

   //BitKeeper代码基本不变
	
	//分1024个桶，就是算1024次
    static class Experiment{
        private int n,k;
        private BitKeeper[] keepers;
        public Experiment(int n){
            this(n,1024);
        }
        public Experiment(int n,int k){
            this.k = k;
            this.n = n;
            this.keepers = new BitKeeper[k];
            for(int i=0;i<k;i++){
                this.keepers[i] = new BitKeeper();
            }
        }

       public void work(){
            for(int i=0;i<this.n;i++){
                long m = ThreadLocalRandom.current().nextLong(1L<<32);
                BitKeeper keeper = keepers[(int)(((m&0xfff0000)>>16)%keepers.length)];
                keeper.random(m);
            }
        }

        public double estimate(){
            double sumbitsInverse = 0.0;
            for(BitKeeper keeper:keepers){
                sumbitsInverse += 1.0/(float)keeper.maxbits;
            }
            double avgBits = (float)keepers.length/sumbitsInverse;
            return Math.pow(2,avgBits)*this.k;
        }
    }
    @Test
    public void test(){
        for(int i=100000;i<1000000;i+=100000){
            Experiment exp = new Experiment(i);
            exp.work();
            double est = exp.estimate();
            System.out.printf("%d %.2f %.2f\n",i,est,Math.abs(est-i)/i);
        }
    }


}

真实的HyperLogLog原理与之类似，但是比之复杂精确。有兴趣可以看看上面贴的参考内容的相关部分。
以下内容也摘录自上面的文章。
Redis中和HyperLogLog相关的命令有三个：

PFADD hll ele： 将ele添加进hll的基数计算中。流程：
先对ele求hash（使用的是一种叫做MurMurHash的算法）
将hash的低14位(因为总共有2的14次方个桶)作为桶的编号，选桶，记桶中当前的值为count
从的hash的第15位开始数0，假设从第15位开始有n个连续的0（即前导0）
如果n大于count，则把选中的桶的值置为n，否则不变
PFCOUNT hll： 计算hll的基数。就是使用上面给出的DV公式根据桶中的数值，计算基数
PFMERGE hll3 hll1 hll2： 将hll1和hll2合并成hll3。用的就是上面说的合并算法。
Redis的所有HyperLogLog结构都是固定的16384个桶（2的14次方），并且有两种存储格式：
稀疏格式： HyperLogLog算法在刚开始的时候，大多数桶其实都是0，稀疏格式通过存储连续的0的数目，而不是每个0存一遍，大大减小了HyperLogLog刚开始时需要占用的内存
紧凑格式： 用6个bit表示一个桶，需要占用12KB内存