【51CTO.com原创稿件】2016年11月25日，由51CTO.com主办的WOT2016大数据技术峰会在北京粤财JW万豪酒店召开，50多位来自阿里、腾讯、百度、京东、小米等知名企业的大数据领域资深技术专家齐聚大会现场，将在两天的时间里与逾千名一线IT技术人员直面交流，分享经验。
在WOT2016大数据技术峰会的主会场，Hortonworks 高级技术成员、 HBase核心贡献者 Ted Yu带来了主题为《Tiny LFU ,a highly efficient cache admission policy》的演讲。以下是他的演讲实录：
数据的分布随着时间的演变也是会变的，比如一个用户走了，下周就不怎么热了。所以考虑的问题是这样两个问题，当Cache满的时候，就要去除出去。很多对于Cache的管理方案，基本上忽略了Admission。Efficient Policy和新的数据进行比较，看谁更适合在这上面。如果新的数据有更大的贡献，再把它放回Cache里面。
如果最近它更被频繁访问，就希望把它放在Cache里面，增加Cache的尺寸，能不能达到类似的效果呢？它的横轴单位是条目，就是Cache能放多少条目。越往后Cache越大，Y轴是看看有百分之多少能够从Cache找到。大家发现当Cache达到3700条的时候，它的***率才相当于最下头两个紫色和蓝色的。所以看出来Cache的大小不是Cache的决定因素。
我们今天讨论的主要是基于访问频度的，上面这几条线，TLFU和WLFU，对于一个条目，希望它的源数据占的空间越少越好。看一下比较单纯的这个Window LFU。看一下这个滑动窗口，这是基于活动窗口的访问频度，来了一个紫色的框，代表着一个条目，如果它比这个WindowLFU更频繁的的话，就把它放在Cache。
能不能把这个滑动窗口去掉？滑动窗口在这里面它的期值是10，这里面第4个就是黄的那个，是多的一个。如果这个窗口没有大10的时候，继续把这条目继续在Cache里面放。这时候来了不同的条目，好了，窗口这个实时条目已经满了。如果去找它的窗口的话，把对于每一个条目的Coueters除以，它3除以2变成1了，这就要丢失一些精度。
去掉滑动窗口是***个，第二个就是这些统计值不用精确值，而是用近似值来表示。下面呈现结果大家会看到，效果还是非常不错的。在条目之中，这个Counter也可以共享，在下一列讲到大家就会知道这个共享是什么意思。这样的话，对源数据耗用的空间就非常少，代价就是损失了一部分精度。简单来讲，这个精度它每次都不停的做除以2除以2，但是***损失是1。
讲最简单的，怎么判断有一个值，把它转换成数值以后，看它是不是在一个集合里面。有一个选择就是哈希，哈希以后就会得到一个值。所以为了减少Collisions，把这个表增大，可能和我们现在讨论的减少源数据的占用空间是相反的。
所以Bloom fiters更抽象化，来看一下这个例子。假设我们这个数据有11位，然后有K，就是说H到K，从0到1的区间里面去进行运算。算Bloom fiters的时候，要联系到Y，联系到K，都去算一遍。 这个Bloom fiters它的功能还是比较有限的，因此就要引入一个Counting Bloom，这样每一个上有不光是0和1了，可以更高。做增量的时候，把这些位相应的都去做分面，这是一个增量操作。第二个，操作是做减量，比如第7位和第5位，相应把它做一个增量。第三个，做一个相应的估计值，因为每个位置上可以打一位。这个里面是4，因为4最小。
主要技巧之一，就是Counting Bloom。做增量的时候，不是把每一位***位和第五位都去做增1，因为3最小，所以把它做增1。但是这个时候不能做减量，因为只有一位，不知道给谁做增量。第二改进，是把这个Counter变得更小一点。假设给定一个W的话，我们大致要用到的LogW，这么多位的信息表示它，可不可以做得更好呢？如果一个条目要在Counter里面待下去的话，整个对于Counter出现了一个W/C。所以每一个Counter，出现13位就可以了，而不需要14位。
这个Counter还可以变得更小，还是回到基本假设，分布是非常不均衡的。看优酷或者土豆的视频，有的没有什么人看，比如是看了很少次，零次或者一次，有的很热。所以呢，对于这些只出现一次的，就要先设一个，这里面写的是SBF，这个和Counting Bloom是一样的。先设一位的Counting Bloom，对于这些不太热的数据，希望把它的增量限制在这里。
如果在做增量的时候，每一个位置上所对应的都是1，到第二级的SBF里面怎么样？所以这就是两级的这样一个结构。还是看一个例子，这是根据经验值推出来的，假设有一千个条目，Window LFU是九千个，阿尔法是0.9这样一个访问频率。实际上7239项都是出现在***项里面，只有416项能够进入到第二级的SBF。所以从整体上平均考量的话，每一个条目只需要1.22位，这只需要非常少的空间来表示源数据就可以了。 当然实际上每个条目最需要布置一个Counter，所以源数据要更多一点。
刚才讲了四点，主要是去除滑动窗口，用Counting Bloom做一个近似。
这张图刚才出现过，我再稍微多讲一句。WLFU不用近似的。大家可以看到，这个紫色的线和大蓝色的线它的***率是***的，***个是阿尔法等于0.9的时候，第二个阿尔法等于0.7的时候。这是维基百科的，因为它的稀疏可能不一样，但是表示出来的含义是一样的。所以我就快速过一下。
IBM的作品，这个T1是近期访问的数据，绿色的区域T2就是更经常访问的，访问两次以上的条目所在的区域。所以T1+T2的大小是一定的，但是有一个指针在这个T2和T1之间滑动，它是要动态的在RU和RFU之间进行调整。
规则是这样的，首先在T1和T2中都没有找到，然后就去B1，换了小的幽灵的样子，就是要去B1或者B2里面去找一下。如果在B1里找到了，所以就要对这个RLU部分有一个倾斜，所以就往右移，如果在B2找到了，那么就往左移。
另外一个竞争的，叫做Low inter-reference Recency Set ，它有一个阈值。第二个For freguent items是近期访问的。下面会看到一系列的曲线，红色带一个三角的，就是最上面的这个，就是理想值。大家可以看到它接近60%，横轴还是以条目计的大。在红线的相对听的这条线是Lifs，大家看到这两者是不相上下的。最上面一条***解，下面第二个就是Window Cache hit rate，这个都是不同的数据级。
这个图表里看到绿线三角的是ARC，它是比Window LFU***率要差一些。这个图要讲一下，大家看到这个红色代带网子的是采样，采样就是我在这里和另一边是挂钩的。***个图窗口宽度是一万七千项，第二个是九千项。绿色在***张图里面误差基本上看不太出来了，绿色的是决断误差，决断误差是因为刚才提到1.5变成1了，所以这有一个决断误差。这误差是相对来讲比稳定，用了绿色空间来表示的。还有待蓝色斜线是代表近似误差，实际上是一个近似，这个近似本身就有一个误差。这图看不太出来，但是当每一个条目用1.25位的时候，会出现近似误差。所以大家看到蓝的部分是在1.25的地方出现，如果用比1.25更多的数据表示的话，不会有这个数据。
所以就是告诉大家，当每一个条目采用1.25字节的时候，综合考虑第二个采样误差、决断误差和近似误差的话，这个效果是非常理想的。好，看一下和HBase什么关系？LruBlockCache，它的访问量是4766387，它的***率是85.67%。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
