论文阅读笔记：Sliding Sketches- A Framework using Time Zones for Data Stream Processing in Sliding Windows

论文阅读笔记：Sliding Sketches: A Framework using Time Zones for Data Stream Processing in Sliding Windows

​ 这是杨仝老师课题组发表在SIGKDD2020的一篇论文，以往的sketch技术没有注意时间的尺度，无法区分一些过时的元素和刚刚新到来的最近元素，因此这篇论文提出一种滑动窗口的sketch机制以达到保留最近新到来元素的的目的，同时也是一种通用框架。这种滑动窗口机制可以与其他的sketch技术相结合，提出了SL-BF、SL-CM、SL-CU、SL-Count、SL-HK等结合技术，更新策略和查询策略还是使用的原有sketch的策略，新增一个扫描策略发生了变化。

Abstract

​ 由于大数据时代的到来，数据流处理(Data stream processing) 在近年来已经成为一个热点话题。存在3种基本的流处理任务：存在性查询(membership query)、频率查询(frequency query)、高频项查询(heavy hitter query) 。虽然大多数现有的解决方案都是在固定窗口(fixed windows)中处理这些查询，但本文关注的是一个更具挑战性的任务:在滑动窗口(sliding windows)中回答这些查询。虽然大多数现有的解决方案通过使用不同的算法来处理不同类型的查询，但本文关注的是一个通用框架(generic framework) 。方案：在本文中，我们提出了一个通用框架，即滑动草图(Sliding sketch) ，它可以应用于上述三种查询的许多现有解决方案，并使它们能够支持滑动窗口中的查询。效果：我们将框架应用于上述三种查询的五个最先进的sketch。理论分析和广泛的实验结果表明，在使用我们的框架后，现有的不支持滑动窗口的sketch的精度大大高于相应的最佳现有技术。

1. 引言

1.1 背景和动机

​ 应用场景：数据流处理是许多应用中出现的一个重要问题，如入侵检测系统、金融数据跟踪器(trackers)、传感器网络等。数据流是由高速到达的无界项目序列(unbounded sequence of items)组成的。与传统的静态数据集相反，数据流需要实时处理，即一次处理(one pass)，更新时间为$O(1)$ 。存在问题：由于大容量(large volume)和高速度，存储整个数据流是困难的，而且往往是不必要的。此外，大规模数据流处理应用通常是分布式的(distributed)。观测本地流的多台主机之间需要进行信息交换(information exchange)。传输完整的数据流需要大量带宽，而且通信效率不高(communication efficient)。引出Sketch: 相反，一个有效的选择是维护数据流的一个小摘要(a small summary of the data stream)。

​ Sketch优势：sketch是一种概率数据结构(probabilistic data structures)，它以引入小错误为代价来提高内存效率(memory efficiency)，已被广泛用于数据流的汇总。Sketch只需要很小的内存使用。可以将它们存储在快速存储器中(fast memory)，例如CPU和GPU芯片中的L2缓存，以及FPGA中的Block RAM。典型的Sketch: 包括Bloom filter，CM sketch，CU sketch等。缺陷：然而，这些sketch不能删除过时的项目(out-dated items)。

​ 在数据流的应用中，人们通常关注最近的项目(recent items) ，这些项目反映了当前的情况和未来的趋势。例如，在金融分析中，人们关注的是当前的金融趋势，而在入侵检测系统中，人们主要关注的是最近的入侵事件。因此，通常有必要降低旧项目(old items)的重要性，并在适当的时候丢弃它们。后果：否则，它们会带来内存的浪费，也会给最近项目(recent items)的分析带来噪声。开发一种能够自动“忘记”旧数据项并关注最近数据项(automatically “forget” old items and focus on recent items)的概率数据结构是一个重要的话题。

​ 最流行的记录近期项目的模型是滑动窗口模型(sliding window model) 。它使用滑动窗口去只包含最近的项目，而以外的项目被遗忘forgotten(删除)。在滑动窗口模型中可以实现各种查询。讨论了三种基本查询:成员查询(membership query)、频率查询(frequency query)和heavy hitter查询。成员查询用于检查项目e是否在滑动窗口中。频率查询是指报告某项目的出现频率。heavy hitter查询是指查找出现频率超过阈值的所有项目。

​ 存在挑战：1） 为滑动窗口模型设计一个概率数据结构是一个具有挑战性的问题。每当窗口滑动时，需要删除最旧的项(oldest item)。2） 然而，找到最旧的项目是具有挑战性的，特别是当对内存和速度的要求很高的时候。我们必须在O(1)时间内实现删除，以赶上数据流的速度。3） 此外，我们不能在滑动窗口中存储所有项目的ID，因为滑动窗口可能非常大，并且存储它们会消耗内存。

1.2 现有技术及其局限性

​ 关于滑动窗口中的近似查询(approximate queries in sliding windows)，已经有相当多的算法。这些算法根据支持的查询可分为三类。第一类支持成员查询: 如：the double buffering Bloom filter、the forgetful Bloom filter。第二类支持频率查询，如：the ECM sketch、the splitter windowed count-min sketch等。第三类支持heavy hitter查询：如：the window compact space saving(WCSS)等。

​ 现有算法存在限制：首先，这些算法通常需要大量内存来实现细粒度的删除(fine-grained deletions)。当空间限制较紧(space limitation is tight)时，这些算法的精度较差。其次，大多数现有算法只处理滑动窗口中的一个特定查询(specific query)。然而，在应用程序中，通常需要各种查询，这使得通用框架(general framework)更受欢迎。

1.3 我们提出的解决方案

​ 在本文中，我们提出了一个框架，即滑动草图(sliding sketch)。它可以应用于大多数现有的sketch，并使它们适应滑动窗口模型(the sliding window model)。我们应用我们的框架到Bloom filter、the CM sketch、the CU sketch、the Count sketch和the HeavyKeeper进行实验评价。

​ 首先介绍常见的sketch模型：一个典型的sketch使用一个长度为m的数组，由计数器(counters)、位(bits)或其他数据结构等元素组成。我们一般称数组中的每个元素为bucket。这个数组被分成k个大小相等的段(segments)。每个段与一个哈希函数相关联。当一个项目e到达时，sketch使用k个哈希函数将其映射到k个桶(buckets)中，每个段一个(one in each segment)，并记录e的信息，如在这些桶中的频率或存在(presence)。我们称这k个桶为k个映射的桶(the k mapped buckets) 。这k个映射的桶通常存储项目e的k个所需信息的副本。由于哈希冲突，它们具有不同的精度。哈希冲突意味着多个项目被映射到相同的桶中，它们的信息被存储到一起，导致了错误。

​ 在查询中，我们报告k个映射桶中最准确的一个。例如，在CM sketch中，每个桶是一个计数器，并存储映射到其中的所有项目的频率摘要(the summary of the frequencies)。每个项目被映射到k个桶，这些桶都包含大于或等于其频率的计数器，我们报告这k个计数器中最小的一个作为查询中的频率。

​ 大多数现有算法都保持了sketch的基本结构，并引入了不同的改进以将其应用于滑动窗口(sliding windows)。现存算法存在挑战：在sketch中很难准确地存储当前滑动窗口中的信息，因为很难删除所有过时的信息(outdated inforamtion)。因此，大多数现有算法选择存储最近的周期，$\omega$ ，它近似于滑动窗口(approximate to the sliding window)。回想一下，在通用sketch模型中，每个项目有k个映射的桶和k个其信息的副本(copies)。在之前的工作中，这k个映射桶是同步工作的(work synchronously)。换句话说，这些映射的桶存储同一时间段$\omega$ 的信息。此时间段与实际滑动窗口之间的差异在不同的查询时间有所不同，并且在某些时间点可能很大。我们注意到，在查询中，我们报告这k个映射桶中最准确的一个。新思想：这k个映射的桶可以异步工作(work asynchronously)，这意味着它们存储不同的周期(periods)。通过这种方式，我们可以实现，每当我们查询时，都有一个映射桶(a mapped bucket)，该桶记录的时间段非常接近滑动窗口。 我们设计了一种称为扫描操作(scanning operation) 的算法来实现这一点。因此，与现有技术相比，我们的算法的误差要小得多。

​ 大量的实验和理论分析表明，滑动草图(Sliding sketch)具有精度高、内存占用少的特点。实验结果表明，使用我们的框架后，现有的不支持滑动窗口的sketch比支持滑动窗口的算法精度要高得多。在成员查询中，滑动sketch的错误率比目前最先进的滑动窗口算法低10 ~ 50倍。在频率查询方面，滑动草图(Sliding sketch)的ARE比目前最先进的滑动窗口算法低40 ~ 50倍。在heavy hitter查询中，滑动草图的查准率(precision)和查全率(recall)接近100%，优于最先进的方法，滑动草图中heavy hitter查询频率的ARE比最先进的滑动窗口算法低3 ~ 5.6倍。

1.4 关键贡献

1. 我们提出了一个通用的框架，称为滑动草图(Sliding sketch) ，它可以应用于大多数现有的sketch，并使它们适应滑动窗口模型(sliding window model)。
2. 我们将框架应用于滑动窗口中的三种典型查询:成员查询(Bloom filters)、频率查询(CM sketch、CU sketch和Count sketch)和heavy hitter查询(HeavyKeeper) 。数学分析和实验表明，该滑动草图的精度比目前的方法要高得多。

2. 相关工作

2.1 不同种类的sketches

​ Sketch是一种用于数据流总结(data stream summarization)的概率数据结构。经典的sketch支持整个数据流或固定时间段(fixed period)的查询，但不支持滑动窗口模型。根据它们支持的查询，我们在本文中举例说明了三种sketches:成员查询草图(sketches for memory queries)、频率查询草图(sketches for frequency queries)和heavy hitter查询草图。

2.1.1 进行成员查询的Sketches(Sketches for Membership Queries)

​ 成员查询是检查一个项目是否在集合中。最著名的成员查询sketch是Bloom filter。它由一个m位数组组成。当插入项目e时，Bloom filter用k个哈希函数将其映射到k位，并将这些位设置为1。当查询一个项目e时，Bloom filter检查k个映射位，只有当它们都为1时才报告为真。Bloom filter具有单侧误差(one-side error)的特性:它只有假阳性，没有假阴性。换句话说，如果一个项目e在集合s中，它肯定会报告为真，但如果e不在集合中，由于哈希冲突，它仍然有概率报告为真。近年来，为了满足不同应用的需求，人们提出了许多Bloom filter的变体，如Bloomier filter、Dynamic count filter、COMB、shifting Bloom filter等。

2.1.2 进行频率查询的Sketches(Sketches for Frequency Queries)

​ 频率查询是报告一个项目出现的频率。有几个众所周知的频率查询sketches，如CM sketch、CU sketch和Count sketch。

​ CM sketch由一个具有k个等长片段(k equal-sized segments)的计数器数组组成。当插入一个项目e时，CM sketch用k个哈希函数将它映射到k个计数器，每个段一个(one in each segment)，并将这些计数器增加1。当查询一个项目e时，它利用k个哈希哈数找到k个映射的计数器，并报告其中的最小值。CM sketch只有高估误差(over-estimation error)，这意味着报告的频率不低于真实值。CU sketch和Count sketch具有与CM sketch相同的结构，但是更新和查询策略不同。它们的准确率更高，但存在不同的问题。CU sketch不支持删除，Count sketch有双向错误(two-side error)，这意味着查询结果可能比真实值大或小。

​ 进行频率查询复杂一些的sketch算法有：Pyramid sketch、Augmented sketch等。

2.1.3 进行Heavy Hitter查询的Sketches(Sketches for Heavy Hitter Queries)

​ Heavy Hitter查询是查找数据流中频率超过阈值的所有项目。数据流中最先进的Heavy Hitter查询方法是HeavyKeeper。它使用一种称为指数衰减计数(count-with-exponential-decay)的策略，通过衰减主动删除频率较小的项目，并最大限度地减少对heavy hitters的影响。它在heavy hitter查询和top - k查询中达到非常高的准确性。其他用于heavy hitter查询的算法包括Frequency、有损计数(Lossy counting)、Space-Saving、unbiased space saving等。

2.2 滑动窗口的概率数据结构(Probabilistic Data Structures for Sliding Windows)

​ 我们根据所支持的查询将滑动窗口的概率数据结构的现有技术分为三种。第一类支持成员查询(membership queries)，如the double buffering Bloom filter、the Forgetful Bloom filter。第二类是为频率查询设计的，如ECM sketch，the splitter windowed count-min sketch。第三种支持heavy hitter查询。这类包括the window compact space saving(WCSS) 。不幸的是，这些算法在有限的内存下都没有很高的准确性(high accuracy wiht limited memory)。此外，它们中的大多数都特定于有限类型的查询。

3. 问题定义(Problem Definition)

3.1 数据流定义(Definitions of Data Streams)

​ Data Stream: 一个数据流是项目集合 S = { e 1 t 1 , e 2 t 2 , e 3 t 3 ⋯ e i t i ⋯   } S=\{e_1^{t_1},e_2^{t_2},e_3^{t_3} \cdots e_i^{t_i} \cdots\} S={e1t1​​,e2t2​​,e3t3​​⋯eiti​​⋯} 组成的无限序列。每个项目$e_i$ 有一个时间戳$t_i$ ，表明项目的到达时间。在一个数据流中，相同的项目可能出现不止一次。

3.2 滑动窗口定义(Definitions of Sliding Windows)

​ 存在两种类型的滑动窗口：基于时间的滑动窗口(the time=based sliding windows) 和基于计数的滑动窗口(the count-based sliding windows)。定义如下：

​ Time-based sliding window: 给定一个数据流S，一个长度为N的基于时间的滑动窗口表示在最后N个时间单位到达的数据项的并集(the union of data items which arrive in the last N time units)。

​ Count-based sliding window: 给定一个数据流S，一个长度为N的基于计数的滑动窗口，意味着最后N个项目的并集(the union of the last N items)。

3.3 流处理任务的定义(Definitions of Stream Processsing Tasks)

​ Membership query: 给定一个滑动窗口W，我们想知道项目e是否在其中。

​ Frequency query: 给定一个滑动窗口W，我们想要找出项目e在W中出现了多少次，并返回这个数字。我们称这个数字为项目e的频率。

​ Heavy Hitter query: 给定一个滑动窗口W，我们想找出频率超过阈值的项目。

4. 滑动Sketches: 基本版本(Sliding Sketches: Basic Version)

​ 我们为滑动窗口中的典型数据流处理任务(typical data stream processing tasks)提出了一个通用框架。首先，我们介绍了许多sketches使用的模型。其次，基于这个通用模型，我们给出了框架的基本版本。

4.1 通用Sketch模型(A Common Sketch Model)

​ 本文主要研究了三个流处理任务:成员查询、频率查询、heavy hitter查询。这些任务的最先进的sketch使用一个共同的模型，即k -hash模型(k-hash model) 。这个模型的细节如下：

​ 数据结构：k -hash模型的数据结构是一个数组，这个数组由简单而小的数据结构组成，如计数器(counters)、位(bits)或键值对(key-value pairs)。我们一般称数组中的每个元素为bucket。数组被分成k个大小相等的段(k equal-sized segments)，每个段与一个哈希函数相关联。

​ 更新：为了插入一个项目e，它利用k个哈希函数将项目e映射到k个桶，每个段一个(one in each segment)。我们称它们为k个映射的桶(k mapped buckets)。它使用更新策略Stu更新k个映射的桶，该策略根据特定的sketch而变化。

​ 查询：为了查询一个项目e，它计算k个哈希函数并得到k个映射的桶。报告的结果是从使用查询策略Stq的k个映射桶中的值计算出来的。查询策略也会根据特定的sketch而变化。

​ 使用CM sketches作为一个例子：不同的sketch使用不同的更新和查询策略。以CM sketch为例。CM sketch中的每个bucket都是一个计数器。它的更新策略Stu将所有k个映射计数器增加1，而它的查询策略Stq报告k个映射计数器中的最小值。

4.2 滑动sketch模型(The Sliding Sketch Model)

​ 在本文中，我们提出了一个名为滑动草图(Sliding Sketch)的框架，它可以应用于所有符合k -hash模型的sketch，并使它们适应于滑动窗口模型(sliding window model)。

​ 数据结构：在滑动草图(Sliding sketch)中，我们构建了一个包含m个桶(buckets)的数组A，这些桶被分成k个大小相等的段。在基本版本中，每个桶B都有两个字段(fields):$B^{new}$ 字段和$B^{old}$ 字段。每个字段是一个计数器(counter)或一个位(bit)，或一个键值对(key-value pair)，这取决于我们选择的具体sketch。$B^{new}$ 字段存储在最近一小段时刻(the most recent small period)映射到桶B的信息，我们叫做Day, or Today。$B^{old}$ 字段存储以前天的信息，被叫做Yesterday 。每一天(each Day)的长度等于滑动窗口的长度。换句话说，如果滑动窗口的长度为N，则一天(a Day)是N个时间单位(对于基于时间的滑动窗口)或N个新项目到达(对于基于计数的滑动窗口)。我们使用这两天(these 2 Days)的信息来估计滑动窗口。在第5.2节中，我们将扩展滑动草图(sliding sketch)，并在每个bucket中使用d个较小的字段而不是2个字段。

​ 在滑动草图(Sliding sketch)中，我们有以下3个操作:更新操作(update operation)、扫描操作(scanning operation)和查询操作(query operation) 。

​ Update Operation : 当一个项目e到达时，我们使用k个哈希函数将该项目映射到k个桶 { B i ∣ 1 ≤ i ≤ k } \{B_i|1 \leq i \leq k\} {Bi​∣1≤i≤k} 中，每个段一个(one in each segment)。我们使用特定sketch的更新策略Stu更新这k个映射桶中的$B_i^{new}$ 域(field)。

​ Scanning Operation: 我们使用一个扫描操作来删除过时信息(out-dated information)。我们使用一个扫描指针(scanning pointer)一个桶一个桶地重复遍历数组A。每次到达数组末尾时，它都会返回到开始处并开始新的扫描。扫描速度由滑动窗口的长度决定。具体来说，对于宽度为N的基于计数的滑动窗口，每当有新项目到达时，扫描指针就会经过$\frac{m}{N}$ 个桶。换句话说，扫描指针的周期等于数据流中N个项目到达的周期。在基于时间的滑动窗口中也是如此，扫描指针以恒定速度以N个时间单位为周期扫描数组。(如果m < N，每$\frac{N}{m}$ 个项目到达或时间单位指针就会经过1个桶)。每次扫描指针到达桶B时，都是该桶的零时间(zero time) 。在桶的零时间，我们删除$B^{old}$ 中的值。然后我们将$B^{new}$ 中的值复制到$B^{old}$ ，并将$B^{new}$ 设为0。换句话说，新的一天开始了(a new Day starts)。今天变成了昨天(Today becomes Yesterday)。昨天的信息已过期，并且被删除。扫描操作使不同的桶具有异步时间(asynchronous time)，就像不同的时区**(time zones)** 一样。

​ 示例1 ：在这个图中，我们将扫描指针显示为一个环，以便于理解。在这个例子中，A是一个长度为12和有4段的数组。A中的每个桶包含2个字段(fields)，每个字段是一个计数器(counter)。扫描指针经过所有12个桶进行循环。在此图中，它到达$A[5]$ 桶，我们删除$A[5{]}^{old}$ 中的值，即5。然后我们将$A[5{]}^{new}$ 中的值8移动到$A[5{]}^{old}$ ，并将$A[5{]}^{new}$ 设置为0。 这是因为当指针扫描到这个位置时我们可以认为$B^{old}$ 数据已经是过时的数据，而$B^{new}$ 部分的数据再经历过一次循环(就是当这个指针再次到达此位置时)它也要被清除了，所以我们会将$B^{new}$ 部分数据移到$B^{old}$ 部分。

​ Query Operation : 当查询滑动草图中的一个项目时，我们利用k个哈希函数找到k个映射的桶 { B i ∣ 1 ≤ i ≤ k } \{B_i|1 \leq i \leq k\} {Bi​∣1≤i≤k} 。然后我们得到k个值对(k value pairs) : $\{(B_i^{new},B_i^{old})|1\le i\le k\}$。最后，根据应用的需要和具体的sketch制定相应的查询策略，得到查询结果。例如，我们可以使用以下策略。

​ The Sum Strategy : 我们计算k个和 { S u m ( B i ) = B i n e w + B i ∣ 1 ≤ i ≤ k } \{Sum(B_i)=B_i^{new}+B_i| 1 \leq i \leq k\} {Sum(Bi​)=Binew​+Bi​∣1≤i≤k}，并使用特定sketch的查询策略Stq从这k个和(k sums)中得到结果。例如，如果特定的sketch是CM sketch，我们报告k个和中的最小值，如果特定的sketch是Bloom filter，如果这些k个和中的任何一个为0，我们返回false，否则返回true。以CM sketch为例：

​ 该策略同时返回昨天(Yesterday)和今天(Today)的信息，这是一个不小于滑动窗口的时间段。因此，它可以应用于只有高估误差(over-estimation error)的sketch，如布隆过滤器、CM sketch和CU sketch。这种组合将保持单侧误差的特性(one side error property)。

4.3 滑动Sketch模型的分析(The Analysis of the Sliding Sketch Model)

​ 滑动草图的关键技术是扫描操作。它控制数组的老化过程(aging procedure)。

​ 首先，我们分析我们在滑动草图中记录的周期(period)。 在每个桶B中，我们将映射到桶B的项目信息存储在活动的Day中，或$B^{new}$ 字段中的Today中，以及$B^{old}$ 字段中的前一天(the previous Day)或昨天(Yesterday)中。在基本版本中，每个Day等于滑动窗口的长度。在查询时间T，只有Today的$\delta (0<\delta \le 1)$ 已经过去。因此，滑动窗口包括Today的$\delta$ 和Yesterday的最后$1-\delta$ 。$B^{old}$ 字段和$B^{new}$ 字段都与滑动窗口相关。注意，由于时差(time difference)的关系，不同的桶有不同的$\delta$ 。

​ 其次，我们用一个例子来解释Days和滑动窗口之间的关系。

​ 示例2： 在此例中，查询时间T为桶B中的第$3_{rd}$ 天。在查询时间，Today已经过了$\frac{1}{3}$ 天。滑动窗口的长度等于one Day，因此$Da{y}_3$ 只占滑动窗口的$\frac{1}{3}$个，另外$\frac{2}{3}$ 个在Yesterday $Da{y}_2$ 中。我们同时记录Yesterday和Today的信息来估计滑动窗口。注意，不同的桶是异步的(asynchronous)，$\delta =\frac{1}{3}$ 只在桶B中。

​ 接下来，我们分析时差(the jet lag) $\delta$ 的影响和$\delta$ 在一个项目的k个映射桶中的取值范围(value ranges) 。 显然，$\delta$ 会对我们估计的准确性产生很大影响。$\delta$ 越小，$B^{old}+B^{new}$ 越准确，因为它的高估误差更小(smaller over-estimation error)，更接近真实答案。另一方面，$\delta$ 越大，$B^{new}$ 越准确，因为它的低估误差越小(smaller under-estimation error) 。

5. Sliding Sketch优化

5.1 更多查询策略(More Query Strategies)

​ 如上所述，有许多策略可以获得具有k个值对$\{(B_i^{new},B_i^{old})|1\le i\le k\}$ 的项目e的查询结果。下面是一些例子:

​ 低估策略(Under-estimation Strategy) : 我们只能在k个映射桶中使用Today中的信息来获得对结果的低估。在此策略中，我们找到k个映射桶 { B i ∣ 1 ≤ i ≤ k } \{B_i|1 \leq i \leq k\} {Bi​∣1≤i≤k} ，并得到k个值 { B i n e w ∣ 1 ≤ i ≤ k } \{B_i^{new}|1 \leq i \leq k\} {Binew​∣1≤i≤k} 。然后我们使用特定sketch的查询策略Stq从这些k值中获得一个结果。由于Today仅是滑动窗口的$\delta$ 部分且$0<\delta \le 1$ ，因此通常会给出低估。这种策略适用于有低估误差(unde-estimation error)或者双边误差(two-side error)的sketch，像是Count sketch和 HeavyKeeper。

​ 修正的结果(Corrected Result) : 在每个映射的桶中，我们可以计算其中的时差(jet lag) 。因此，我们知道今天(Today)和昨天(Yesterday)的长度对滑动窗口的近似比例(approximate ratio)。我们可以将求和策略(the sum strategy)或低估策略(the under-estimation strategy)的查询结果除以相应的比例来修正结果。当流具有近乎稳定的吞吐量时，可以使用此策略。

5.2 使用更多的域(Using More Fields)

​ 在基本版本中，我们在每个桶中设置2个域(fields)，当内存是足够的，我们能够在每个桶B中使用d个域 { B j ∣ 1 ≤ j ≤ d } \{B^j|1 \leq j \leq d\} {Bj∣1≤j≤d} ，这些d个域记录最近d天(d Days)的信息。如果我们假设Today is $Da{y}_t$ ，$B^j$ 记录$Da{y}_{t-j+1}$ 的信息。在这种情况下，每一天应该是滑动窗口的$\frac{1}{d-1}$ ，d个域版本的基本操作是如下所示：

​ Update Operation : 当一个项目e到达时，我们使用k个哈希函数去映射这个项目到k个桶中 { B i ∣ 1 ≤ i ≤ k } \{B^i|1 \leq i \leq k\} {Bi∣1≤i≤k} ，每个段一个。我们用特定sketch的策略Stu更新这k个映射桶中的$B_i^1$ 字段。

​ Scanning Operation : 每次有项目到达或时钟增加，扫描指针扫描$\frac{(d-1)\times m}{N}$ 个桶。当扫描指针到达桶B时，我们设$B^j=B^{j-1}(2\le j\le d)$ ，并且$B^1=0$ ，因为新的一天(a new Day)开始了，所有存储的信息都变老一天(one Day older)。

​ Query Operation : 当查询一个项目e时，我们用k个哈希函数为查询的项目e找到k个映射桶 { B i ∣ 1 ≤ i ≤ k } \{B^i|1 \leq i \leq k\} {Bi∣1≤i≤k} 。然后我们得到k组值: { B i j ∣ 1 ≤ j ≤ d , 1 ≤ i ≤ k } \{B_i^j|1 \leq j \leq d, 1 \leq i \leq k\} {Bij​∣1≤j≤d,1≤i≤k} 。最后，我们根据这k组值，通过一个策略得到查询结果。该策略取决于应用程序的需要和特定的sketch。

​ 当我们使用多个字段(fields)时，精度可能会更高。时差$\delta$ 仍然与基本版本相同。当每个桶的天数变为滑动窗口的$\frac{1}{d-1}$ 时，滑动窗口的近似(approximation)带来的误差也变为$\frac{1}{d-1}$ 。字段数d、数组长度m和段数k之间的权衡取决于具体的sketch，建议在应用程序中进行实验尝试。

6. 性能评价(Performance Evaluation)

​ 我们应用Sliding sketch到五种sketches中：the Bloom filter、the CM sketch、the CU sketch、the Count sketch、the HeavyKeeper。 我们分别叫这些具体的方案为:the Sliding Bloom filter、the Sliding CM sketch、the Sliding CU sketch、the Sliding Count sketch、the Sliding HeavyKeeper。

6.1 实验建立(Experimental Setup)

​ 数据集：1) IP Trace Dataset 2) Web Page Dataset 3) Network Dataset 4) Synthenic Dataset。

​ 评价指标：

1. Error Rate in Membership Estimation: 错误上报的实例数与查询的所有实例数的比值。我们使用这个错误率是因为FBF和SW-BF都有双边误差(two-side error)。我们使用的查询集合包括在现在滑动窗口的n个不同项目和不在滑动窗口的n个项目。
2. Average Relative Error(ARE) in Frequency Estimation: $\frac{1}{\psi }{\sum }_{e_i\in \psi }\frac{|f_i-\widehat{f_i}|}{f_i}$ ，$f_i$ 是项目$e_i$ 的真实频率，$\widehat{f_i}$ 是它的估计频率。$\psi$ 是查询集合(the query set)。我们通过在滑动窗口中查询每个不同的项目来查询数据集。
3. Precision Rate in finding Heavy Hitter: 正确报告的实例数与报告的实例数的比率。
4. Recall Rate in finding Heavy Hitter: 正确报告的实例数与正确实例数的比率。
5. Average Relative Error(ARE) in finding Heavy Hitter: $\frac{1}{\psi }{\sum }_{e_i\in \psi }\frac{|f_i-\widehat{f_i}|}{f_i}$ ，$f_i$ 是项目$e_i$ 的真实频率，$\widehat{f_i}$ 是它的估计频率。$\psi$ 是在现在的滑动窗口中真实的heavy hitter集合。
6. Speed: 每秒百万次操作(插入)(Million operations(insertions) per second (Mops))。速度实验重复100次，以保证有统计学意义。

6.2 成员查询评价(Evaluation on Membership Query)

​ 成员评价查询比较了3种方法：Sl-BF，FBF，the SWBF。

​ 频率查询评价比较了5种方法：Sl-CM，Sl-CU，Sl-Count，ECM，SWCM。

​ Heavy Hitter查询比较了3种方法：Sl-HK，$\lambda -sampling$ ，WCSS。

7. 总结

​ 滑动窗口中的数据流处理(Data stream processing in sliding windows)是一个重要的和挑战性的工作。我们在这篇论文中提出一个通用的框架(generic framework)，叫做Sliding sketch，可以被应用到大多数现存的sketch中，并且能够相应滑动窗口中各种类型的查询。我们使用我们的框架去解决滑动窗口中3类基本的查询：成员查询(Bloom filter)、频率查询(CM sketch、CU sketch、Count sketch)、Heavy Hitter查询(HeavyKeeper)。理论分析和实验结果展示我们的算法比现有技术有更高的准确性。我们相信我们的框架适用于所有使用通用 sketch模型(common sketch model) 的sketches。

8. 可继续学习的参考文献

[1] Sang Hyun Oh, Jin Suk Kang, Yung Cheol Byun, Taikyeong T Jeong, and Won Suk Lee. Anomaly intrusion detection based on clustering a data stream. In Acis International Conference on Software Engineering Research, Management and Applications, pages 220–227, 2006.

[2] F. Chang, Wu Chang Feng, and Kang Li. Approximate caches for packet classification. In Joint Conference of the IEEE Computer and Communications Societies, pages 2196–2207 vol.4, 2004. (the double buffering Bloom filter)

[3] Rajath Subramanyam, Indranil Gupta, Luke M. Leslie, and Wenting Wang. Idempotent distributed counters using a forgetful bloom filter. Cluster Computing, 19(2):879–892, 2016. (the forgetful bloom filter)

[4] Yoon. Aging bloom filter with two active buffers for dynamic sets. IEEE Transactions on Knowledge Data Engineering, 22(1):134–138, 2009. (Aging Bloom filter)

[5] Odysseas Papapetrou, Minos Garofalakis, and Antonios Deligiannakis. Sketchbased querying of distributed sliding-window data streams. Proceedings of the VLDB Endowment, 5(10):992–1003, 2012. (ECM Sketch(Exponential Count-Min sketch) )

[6] Nicoló Rivetti, Yann Busnel, and Achour Mostefaoui. Efficiently Summarizing Distributed Data Streams over Sliding Windows. PhD thesis, LINA-University of Nantes; Centre de Recherche en Économie et Statistique; Inria Rennes Bretagne tlantique, 2015. (splitter windowed count-min sketch)

[7] Ho Leung Chan, Tak Wah Lam, Lap Kei Lee, and Hing Fung Ting. Continuous Monitoring of Distributed Data Streams over a Time-Based Sliding Window. 2009.(Sliding window)

[8] Graham Cormode and Ke Yi. Tracking distributed aggregates over time-based sliding windows. In ACM Sigact-Sigops Symposium on Principles of Distributed Computing, pages 213–214, 2011. (Sliding window)

[9] Ben Basat Ran, Gil Einziger, Roy Friedman, and Yaron Kassner. Heavy hitters in streams and sliding windows. In IEEE INFOCOM 2016 - the IEEE International Conference on Computer Communications, pages 1–9, 2016.(window compact space saving(WCSS) )

[10] Junzhi Gong, Tong Yang, Haowei Zhang, Hao Li, Steve Uhlig, Shigang Chen, Lorna Uden, and Xiaoming Li. Heavykeeper: An accurate algorithm for finding top-k elephant flows. In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 909–921, Boston, MA, 2018. USENIX Association. (Heavy Keeper)

[11] David Nelson. The bloomier filter: An efficient data structure for static support lookup tables. Proc Symposium on Discrete Algorithms, 2004. (Bloomier filter)

[12] J. Aguilar-Saborit, P. Trancoso, V. Muntes-Mulero, and J. L. Larriba-Pey. Dynamic count filters. Acm Sigmod Record, 35(1):26–32, 2006. (Dynamic count filter)

[13] Fang Hao, M Kodialam, T. V Lakshman, and Haoyu Song. Fast multiset membership testing using combinatorial bloom filters. In INFOCOM, pages 513–521, 2009. (COMB)

[14] Tong Yang, Alex X. Liu, Muhammad Shahzad, Yuankun Zhong, Qiaobin Fu, Zi Li, Gaogang Xie, and Xiaoming Li. A shifting bloom filter framework for set queries. Proceedings of the Vldb Endowment, 9(5):408–419, 2016. (Shifting Bloom filter)

[15] Jiecao Chen and Qin Zhang. Bias-aware sketches. Proceedings of the VLDB Endowment, 10(9):961–972, 2017. (Bias-aware sketches)

[16] Gurmeet Singh Manku and Rajeev Motwani. Approximate frequency counts over data streams. In VLDB’02: Proceedings of the 28th International Conference on Very Large Databases, pages 346–357. Elsevier, 2002. (Lossing Counting)

可供参考的博客：
数据窗口中的ole控件 pb_论文导读 | 用于滑动窗口模型中数据流摘要的算法框架-CSDN博客