[论文笔记] SIGKDD HeavyGuardian: Separate and Guard Hot Items in Data Streams

先附上论文代码

读了一遍这篇文章之后有如下几个疑问，待进一步学习与思考：
1、概率化好神奇（需要数学去支撑）
2、heavy部分存储ID是因为heavy部分值得去关注吗？ （正解）
3、按照所说的cold items有很多，后面直接hash的方式不会占用很大内存吗？light part不会用完吗？（所以light part设置的计数器的bit数会更小）
4、一个hot被踢出来了不会再进入light。来一个新的item会试图把它往heavy里面塞，light里面的cold数据实际上是会小于实际次数的（正解）
5、要是用这种算法的，感觉也很容易攻击
6、复习一下二项分布和泊松分布叭
Generally, these tasks are measured within fixed-size time windows.
除了五个提到的，还有这些stream processing tasks
Super-Spreader
DDoS victims
top-k frequent items
hierarchical heavy hitters
更关注hot items，实践中，大多数都是cold items，准确记录大量的cold items占用太多内存，内存紧张的时候还会对hot items的估计带来不可忽略的错误。但是又不能不记录啊，因为cold和hot是转换的过程。
这个人也写了阅读笔记，但是和我完全不是一个画风，我就是瞎逼逼，然后看到他给了算法流程我就不想写了，我是什么猫饼？等做报告前再补上去叭？？？做报告的时候还要看论文说明这个总结一点也不OK。下次一定一定不要犯懒！

为了实现高效性和有效性，一种巧妙（elegant）的方法是use a compact data structure to
keep and guard the information (item ID and frequency) of hot items and efficiently record the frequencies of cold items. 问题的关键在于如何实时判断来的item是hot还是cold，很难在小内存中以高准确度记录items

已有的数据结构采用record-all-evict-cold的策略，核心思想是一开始记录所有items的频次，然后剔除cold items。两个经典（notable）的算法是Space-Saving和Augmented sketch。

Space-Saving用一个有序列表Stream-Summary来维护每个到达的item，该数据结构可以在O（1）实现插入、删除、查找coldest item。来了一个e,如果在列表里，频次+1，否则，它替换掉coldest item，设它的频次是${\hat{f}}_{min}$，那么e的频次记做${\hat{f}}_{min}+1$ ？？凭啥哟，不是很有可能cold频次增长超过hot从来挤掉hot吗。许多hot items被存在Stream-Summary中，cold items被剔除。但是该算法有两个局限性：不能记录cold items的频次；一些后来的cold items会被“高估”，从而留在列表里，（我就说嘛）。因此要记录前k大，就必须存储m个，m远大于k

Augmented sketch是二层节后，以底层是一个小数组存$\delta$和hot items，第二个是一个经典的sketch（CM sketch）存所有item的frequency，后来的hot items启初被插入第二个sketch，然后被交换到第一个stage。
Augment Sketch的问题在于，对于每一个来的item，filter中的查找是挨个查的，因此比较慢，作者建议存32个hot items。但是在流任务中，需要报告上千个hot items，会导致filter和sketch频繁地互换，first stage就像一个小的cache。

总的来说有两个缺点：

• 内存利用率不高。Space-Saving额外消耗m-k。Augment Sketch的sketch需要大量的计数器去存储所有items的频次。
• hot items的信息没有很好地保存。SS的频次比实际值要大很多，AS只能精确记录一开始的几个hot items

our proposed solution

将数据流问题简化成：给定数据流，如何用很少的cells来准确测量最热门的item的频次。
分离hot和cold，用大的计数器保存hot的频次信息，用小的计数器来记录cold items。
算法基于 King（频次最高的） guardian（除了King以外在heavy part的） rebel（和King与guardian不一样的）这么个思想做了一些改进。 （这个思想直接看算法如何实现的）

• 将数据流分成多个子流，每个子流选择一个King和guardian（实际上就是用函数选择一个bucket，bucket里分为heavy part和light part，即保皇党和反叛党）
• 用小计数器去存储rebels的频次
  这个小故事讲的真的很花里胡哨。我一点也不想记录。
  
  比最前沿的Space Saving误差小了$6.24\ast 10^4\sim 4.02\ast 10^6$倍，每个不同的item只用了0.005bit（这一点我并没有从figure 10(a)中看出来）？

main contributions

• intelligently separate and guard the information of hot items and approximately record the frequencies of cold items in a data stream
• derive the formula of the error bound 推导了误差界限的公式
• deploy HeavyGuardian on five typical tasks ； much higher accuracy and higher processing speed than the state-of-the-art at the same time. 将HG用在五种典型的任务中

Background

实时频次分布可以支持以下强大的功能：
IP services provider可以根据估计的频次分布来推断the usage of the network，可以用来调整服务策略。实时的可以让服务提供商立即调整，给用户带来更好的体验。
熵的变化可以检测出流中的异常行为，可以用来做异常检测。

Frequency Estimation

Sketch用小小的误差就可以实现高速、内存利用高效，因此常用。
Typical sketches include Count sketches [22], Count-min (CM) sketches [23], CU sketches [15], Augmented sketch framework [12], Pyramid sketch framework [13], and more [21, 24].

Count，CM，CU使用equal-Sized计数器去记录频次，但是hot items需要足够大的counter，而cold items数量多，counters记录值小，造成了很多bit的浪费。
Augmented sketch framework 用过滤器来准确记录32个hot items。提高有限。
Pyramid sketch framework，是最前沿的算法，可以根据来的item自动增大计数器的大小，也被证明有更高的准确度和速度。
但是hot items需要不少memory accesses，PS的插入速度在最坏情况是很慢的。

heavy hitter detection

sketch based algorithms：使用sketch去记录所有items的频次，最小堆去找前K大，需要很多内存去记录所有频次（主要是cold 太多了，用的counter还和hot的一样大）。当memory space比较小的时候，accuracy会迅速下降
counter based algorithms：Space-Saving，Frequent [29], and Lossy counting，Space Saving最常用，这三个算法类似。

heavy change detection

k-ary sketch基于CM sketch，在memory space很大的时候有很高的准确度。但是需要知道所有item的ID。
reversible sketch基于k-ary sketch，解决了上述问题，以一定复杂度对item ID进行解码？

Real-time Frequency Distribution & Real-time Entropy

frequency distribution常用算法是MRAC，FlowRadar。但是他们不能实时估计。
在流中熵被定义为${\sum }_e\frac{f_e}{N}{\log }_2\frac{f_e}{N}$，其中$f_e$是e的频次，n是所有items的总数。The most notable algorithm is proposed by Lall et al.[43], which uses sampling and simple mathematical derivation to estimate the entropy.具有很高的准确度、内存利用、处理速度。
本文是第一个支持实时估计的。

算法实现

先把东西都尝试往heavy part塞。如果已经在heavy part里，直接加1，如果不在，有空位置就放入空位置，没用空位置就以一定的概率去把weakest guardian -1，如果减到0了就自己进去，置为1，否则插入light part，直接在hash得到的位置+1。


概率性减一，如果减为0 了踢掉，这里如果踢掉了信息就会丢失的，被踢者不会进入light part。
在heavy part和light part的hash函数是一样的，来一个item只需要做一次hash。
查询的时候，先hash得到heavy part的桶，遍历cell寻找，如果找不到，再根据hash值直接找light part，找不到就是没有。

由于hot items被踢出的概率很小，因此他们的频次很接近准确值
the heavy part of each bucket in HeavyGuardian seldom records cold items, but records and guards the frequencies ofhot items.

关于处理速度：

• 处理hot item只需要在heavy part里遍历cells，this is fast because these cells can fit into a cache line
• 处理cold item 只需要再多访问一次light part
  因此时间复杂度是O（1）

optimization

当item ID比较大的时候，用指纹来代替ID。这时HG的内存使用与item ID无关。但是哈希函数选的合适指纹碰撞的概率是很低的

数学分析

Proof of no Over-estimation Error

纯文字，很好想

The Error Bound of the Heavy Part of HeavyGuardian

纯数学

heavyguardian deployment

frequency estimation

heavy部分记录hot，light部分记录cold

Heavy Hitter Detection and Heavy Change Detection

用HeavyGuardian在heavy part存储hot items，在备用列表里记录hot items的ID。在这两种应用场景下，不需要记录code item，因此${\lambda }_l=0$

Heavy Hitter Detection：

插入：对于来的item e，先把它插入HeavyGuardian，之后得到e的估计频次${\hat{f}}_e$，如果${\hat{f}}_e=\mathcal{T}$,就把e插入备用列表B
注意：条件是${\hat{f}}_e=\mathcal{T}$，而不是大于。HG记录了每个hot items的指纹和频次，当不考虑指纹碰撞的时候，频次是一点一点加上去的，我们在B中只存储列表一次，在最坏的情况下，一个cold item和a heavy hitter指纹碰撞被映射搭配同一个bucket中，当且仅当cold item到达时，存的频次是$\mathcal{T}$