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枚硬币的代码,如果某个值介于2k~2k+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的2k 近似相等。
n介于2k~2k+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内存