数据压缩系统技术领域
本发明涉及一种数据压缩系统、数据压缩方法、数据压缩用相关
性提取设备和程序。
背景技术
在诸如可伸缩存储的分布式系统中，为了解决漏洞或者改善性能，
定期地收集各个软件组件的运行情况以及硬件资源的系统状态作为统
计信息。
统计信息由巨量的数据组成。例如，为了利用从客户端一侧获得
的统计信息来分析系统中的问题，可取的是尽可能多地收集统计信息。
同时，存在例如由于安全原因导致可下载的数据量有限的问题。因此，
需要压缩数据并且发送压缩的数据，以便在不增加分组的大小的情况
下，发送更大量的统计信息。
如上所述，为了实现诸如基于收集的数据执行分析的给定目的，
可存储或传送大量的数据。在这种情况下，为了解决如上所述的安全
问题，或者从成本的角度看，可取的是压缩数据。
作为一种数据压缩技术，例如已知有专利文献1。专利文献1公
开了一种技术，其基于项目信息中的一致性的分布，对压缩目标数据
组的数据进行分组，并且根据确定的信息精度对信息已经被重写的数
据进行压缩。
引用列表
专利文献
PTL1：JP2012-168671A
发明内容
技术问题
如上所述，在获得数据以用于调查等的情况下，可能关键的是获
得大量数据。然而，仅通过利用上述技术执行压缩不总能实现可取的
压缩比。
另外，当执行数据压缩连同诸如数据传送的处理以用于调查时，
有必要在维持高可靠性的同时压缩数据。然而，与简单地压缩数据相
比，在维持高可靠性的同时高效地压缩数据要困难很多。
如上所述，存在难以在维持高可靠性的同时高效地压缩数据的问
题。
鉴于上文，本发明的目的在于提供一种能够解决上述问题，即，
难以在维持高可靠性的同时高效地压缩数据的问题，的数据压缩系统。
问题的解决方案
为了实现上述问题，作为本发明的一方面的数据压缩系统包括
相关性提取装置，用于从收集的给定数据集合提取构成所述给定
数据集合的数据值之间的相关性的至少一个候选；
相关性验证装置，用于验证所述给定数据集合是否满足由所述相
关性提取装置提取的相关性；以及
数据压缩装置，用于基于所述相关性验证装置的验证结果，利用
所述相关性压缩所述给定数据集合。
另外，作为本发明的另一方面的数据压缩方法包括
从收集的给定数据集合提取构成所述给定数据集合的数据值之间
的相关性的至少一个候选；
验证所述给定数据集合是否满足所提取的相关性；以及
基于验证结果，利用所述相关性压缩所述给定数据集合。
另外，作为本发明的另一方面的数据压缩用相关性搜索设备，是
提取相关性以用于压缩给定数据的数据压缩用相关性提取设备，该设
备包括
相关性提取单元，从收集的给定数据集合提取构成所述给定数据
集合的数据值之间的相关性的至少一个候选；以及
相关性验证单元，验证所述给定数据集合是否满足由所述相关性
提取单元提取的相关性。
另外，作为本发明的另一方面的程序是使得信息处理设备实现以
下装置的程序
相关性提取装置，用于从收集的给定数据集合，提取构成所述给
定数据集合的数据值之间的相关性的至少一个候选；以及
相关性验证装置，用于验证所述给定数据集合是否满足由所述相
关性提取装置提取的相关性。
本发明的有益效果
由于本发明如上所述配置，所以本发明能够实现一种数据压缩系
统，其能够在维持高可靠性的同时高效地压缩数据。
附图说明
图1是示出根据本发明的第一示例性实施例的数据压缩系统的总
体配置的框图。
图2是示出图1所示的存储系统的示例性配置的框图。
图3是示出图1所示的统计数据挖掘设备的示例性配置的框图。
图4是示出存储在图3所示的统计数据挖掘设备中的示例性统计
数据的表。
图5是示出由图3所示的窗口生成装置生成的示例性窗口的表。
图6是示出由图3所示的相关性提取装置执行的相关性提取的示
例的示图。
图7是示出由图3所示的相关性提取装置执行的相关性提取的示
例的示图。
图8是示出由图3所示的相关性提取装置执行的相关性提取的示
例的示图。
图9是示出由图3所示的相关性验证装置执行的验证处理的示例
的示图。
图10是用于说明当相关性被存储在图3所示的规则文件中时的存
储方法的示图。
图11是示出图1所示的统计数据压缩设备的示例性配置的框图。
图12是示出图1所示的统计数据挖掘设备的示例性操作的流程
图。
图13是示出当在窗口中搜索相关性时、图1所示的统计数据挖掘
设备的示例性的操作的流程图。
图14是示出图1所示的统计数据压缩设备的示例性操作的流程
图。
图15示出本发明的第二示例性实施例中的示例性Zstat文件。
图16是示出本发明的第二示例性实施例的总体配置的示意图。
图17是用于说明StatsMiner中的挖掘操作的示图。
图18是用于说明StatsMiner中的验证操作的示图。
图19是示出由StatsMiner基于图15所示的Zstat文件生成的窗口
的示例性配置的示图。
图20是示出将StatsMiner所找到的规则存储为树的示例的示图。
图21是示出StatsMiner的示例性性能结果的表。
图22是示出不同类型的规则的最小显著性的百分比的示例的曲
线图。
图23是示出StatsCompressor的平均压缩比和StatsCompressor的
性能结果的示例的表。
图24是示出绝对压缩比的示例的表。
图25是示出外部压缩器的示例性性能的表。
图26是用于说明StatsCompressor中的压缩操作的示图。
图27是示出在禁止重新编号的情况下、利用在LRT_A中发现的
规则压缩LRT_A集合的示例性结果的表。
图28是示出在禁止抽象类的展平的情况下、利用在LRT_A中发
现的规则压缩LRT_A集合的示例性结果的表。
图29是示出仅执行常数的压缩的、StatsCompressor中的示例性实
验结果的表。
图30是示出使用变换格式作为仅有压缩方法、来压缩LRT_A集
合的StatsCompressor的示例性压缩比的表。
图31是示出具体地使用变换格式的次数的示例的表。
图32是示出在禁止偏差向量(仅允许严格相关性)的情况下、
StatsCompressor的示例性压缩比的表。
图33是示出在利用LRT_A集合上发现的规则压缩LRT_A集合
时、从规则文件加载的规则的使用的示例性统计数据的表。
图34是示出仅使用LRT_A集合中发现的同一性(identity)规则
来压缩LRT_A集合的StatsCompressor的示例性压缩比的表。
图35是示出当改变所使用的总和规则的百分比时、在压缩比之间
的示例性差异的表。
图36是示出在不使用StatsMiner所找到的任何规则的情况下、用
于压缩LRT_A的StatsCompressor的示例性压缩比的表。
图37是示出利用LRT_A集合上找到的规则来压缩LRT_B集合的
StatsCompressor的示例性压缩比的表。
图38是示出当改变具有给定的最小重要性的规则的百分比时、
StatsCompressor的平均压缩比的示例性差异的表。
图39是示出仅使用已经用于压缩LRT_A集合的规则来压缩
LRT_B集合的StatsCompressor的示例性压缩比的表。
图40是示出在客户端的站点上执行StatsMiner和StatsCompressor
二者的结果的表。
图41是示出当以不同的模型在CL_2集合上运行所设计的解决方
案时、StatsCompressor的示例性平均压缩比的表。
图42是示出当以不同的模型在CL_2集合上运行所设计的解决方
案时、结果的示例性标准偏差的表。
具体实施方式
第一示例性实施例
本发明的第一示例性实施例描述一种数据压缩系统1(数据压缩
系统)，其利用统计数据(数据、数据组)之间的相关性来压缩统计
数据，所述统计数据通过定期地收集存储系统2运行的各个软件单元
和硬件资源的操作状态来生成。
参照图1，本实施例中的数据压缩系统1包括存储系统2、统计数
据挖掘设备3(数据压缩用相关性提取设备)和统计数据压缩设备4。
存储系统2、统计数据挖掘设备3和统计数据压缩设备4经网络彼此能
够通信地连接。另外，存储系统2和统计数据压缩设备4彼此能够通
信地连接。
存储系统2被配置为使得多个服务器计算机彼此连接。参照图2，
存储系统2包括加速器节点21(21a、21b、...，下文中如果不需要区
别的话，它们中的每一个被表示为加速器节点21)和存储节点22(22a、
22b、...，下文中如果不需要区别的话，它们中的每个被表示为存储节
点22)。另外，所有的存储节点22经网络彼此连接。另一方面，尽管
加速器节点21与所有的存储节点22连接，但是加速器节点21之间不
存在连接。另外，加速器节点21与客户端服务器、统计数据挖掘设备
3和统计数据压缩设备4连接。
加速器节点21是控制自己的存储系统2的存储和读取操作的服务
器计算机。加速器节点21用作存储系统2的网关，并且具有提供数据
访问API的功能。
存储节点22是包括用于存储数据的存储设备的服务器计算机。存
储节点22保存经由加速器节点21获得的数据。
应该注意的是，代替加速器节点21，存储系统2可包括组合了加
速器节点21的特征和存储节点22的特征的混合节点。
另外，加速器节点21的数量和存储节点22的数量不限于图2中
所示那些。与图2所示那些相比，存储系统2可包括更多数量的或更
少数量的加速器节点21和存储节点22。
本实施例的存储系统2包括如上所述的加速器节点21和存储节点
22。将要在加速器节点21和存储节点22二者的服务器上执行的处理
收集各种统计数据。具体地讲，在各个服务器上运行的相应各个软件
单元收集统计数据。这里，例如，在类似本实施例的存储系统2的系
统中，存在相似的统计数据出现于多个单元中的情况，例如在各个单
元之间发送和接收信息的情况下。这意味着由于各个单元彼此协作地
操作，所以由一个单元收集的统计数据与由另一单元收集的统计数据
之间可存在相关性。本实施例的数据压缩系统1被配置为利用此相关
性来压缩统计数据。
应该注意的是，如上所述，加速器节点21的操作和存储节点22
的操作彼此不同。因此，由加速器节点21收集的统计数据和由存储节
点22收集的统计数据未必相同。因此，下面将描述压缩由存储节点22
收集的统计数据的情况。
在这种情况下，存储系统2经由加速器节点21将从各个存储节点
22收集的统计数据发送给统计数据挖掘设备3。
应该注意的是，数据压缩系统1的压缩目标不限于从存储节点22
收集的统计数据。数据压缩系统1可被配置为压缩从加速器节点21收
集的统计数据，或者可被配置为压缩从加速器节点21和存储节点22
二者收集的统计数据。
另外，本实施例的存储系统2被配置为从各个节点收集统计数据
并且将它们发送给统计数据挖掘设备3。这意味着包括将要发送给统计
数据挖掘设备3的统计数据的一个文件包括由一个存储节点22上的各
个单元收集的统计数据。然而，在实现本发明时，具有上述配置并非
必须。这意味着包括将要发送给统计数据挖掘设备3的统计数据的一
个文件可包括由多个节点上的各个单元收集的统计数据。
统计数据挖掘设备3是信息处理设备，其对从存储系统2发送来
的统计数据的集合执行挖掘，并且搜索给定相关性(数学相关性等)，
例如不同统计数据之间的相关性或者一个统计数据的内相关性。统计
数据挖掘设备3包括未示出的CPU(中央处理单元)和存储设备(存
储器和硬盘)。统计数据挖掘设备3被配置为通过执行安装在存储设
备中的程序的CPU来实现下述功能。
参照图3，统计数据挖掘设备3包括数据发送/接收装置31、统计
数据库32、窗口生成装置33(可以是相关性提取装置和相关性验证装
置的一部分)、相关性提取装置34、相关性验证装置35和规则文件
36。
数据发送/接收装置31具有与存储系统2和统计数据压缩设备4
发送和接收统计数据和规则(下面描述)的功能。例如，数据发送/接
收装置31从存储系统2接收(可经由统计数据压缩设备4)从存储系
统2上的各个存储节点22收集的统计数据(包括统计数据的文件)。
然后，数据发送/接收装置31将接收的统计数据存储在统计数据库32
中。另外，例如，数据发送/接收装置31将存储在规则文件36(下面
描述)中的规则(验证的规则)发送给统计数据压缩设备4。每当过去
预定周期时由数据发送/接收装置31执行规则的发送。
统计数据库32是诸如存储器或硬盘的存储设备。统计数据库32
存储由数据发送/接收装置31接收的统计数据。如此，统计数据库32
被配置为利用各个文件(利用各个节点)来存储不同类型的统计数据。
应该注意的是，统计数据库32可通过将多个文件组合成一个文件来存
储它们。
图4示出存储在统计数据库32中的示例性统计数据。参照图4，
例如，统计数据库32将由单元A收集的统计数据A、统计数据B、统
计数据C和统计数据D，以及由单元B收集的统计数据E、统计数据F
和统计数据G，存储在一个文件中。这样，统计数据库32将由多个单
元收集的统计数据存储在一个文件中。
另外，例如，统计数据库32存储10、20、10、15、12、13、14、
16、15和14，作为统计数据A的样本(数据值)。例如，统计数据库
32还存储6、16、11、12、13、14、15、15、15、10、10、12、14、
16、2、1和31，作为统计数据E的样本。这意味着统计数据库32存
储10个样本作为统计数据A(统计数据A是包括10个样本的数据组)，
而存储17个样本作为统计数据E(统计数据E是包括17个样本的数
据组)。这样，存储在统计数据库32中的各个统计数据的样本的数量
可彼此不同。
窗口生成装置33具有生成窗口(局部化搜索范围)的功能，所述
窗口是用于从存储在统计数据库32中的统计数据(包括统计数据的文
件)搜索相关性的范围。这里，窗口是所有可用统计数据的可比的、
长度相同的样本序列的集合。由此，窗口是使得各个统计数据包括相
同数量的样本(使得构成各个数据组的数据值的数量变得相同)的、
相关性的局部化搜索范围。因此，窗口的长度是在任何统计数据中均
相同的样本的数量(例如，10至20，预定数量)，窗口的宽度是统计
数据的类型的数量。应该注意的是，窗口可包括或者可不包括与收集
各个样本的时间有关的信息。
例如，窗口生成装置33利用图4所示的统计数据生成图5所示的
窗口。参照图5，窗口生成装置33利用图4所示的统计数据生成具有
长度10和宽度7的窗口。如此，窗口生成装置33生成7种类型的统
计数据各自包括10个样本的窗口。这样，窗口生成装置33能够将一
个文件分成多个窗口。然后，窗口生成装置33将生成的窗口发送给相
关性提取装置34和相关性验证装置35。
应该注意的是，窗口生成装置33通过按照得到它们的顺序获得给
定数量的统计数据来生成窗口。这意味着，窗口生成装置33按照它们
存储在统计数据库32中的顺序来获得各个统计数据的样本，并且生成
窗口，而不考虑各个统计数据的样本的时间戳。窗口生成装置33可通
过这种方法来生成窗口。同时，窗口生成装置33可在考虑时间戳的同
时生成窗口。这样，窗口生成装置33可通过各种方法利用存储在统计
数据库32中的统计数据生成窗口。
另外，窗口生成装置33可被配置为重用先前生成的窗口。这意味
着，窗口生成装置33可被配置为随机地从先前已经生成的多个窗口获
得统计数据(样本串)，并且利用获得的样本串来生成新窗口。另外，
窗口生成装置33可被配置为生成统计数据的类型的数量受限的窗口。
相关性提取装置34具有基于在由窗口生成装置33生成的窗口中
的各个统计数据之间的关系提取相关性的功能。另外，相关性提取装
置34可被配置为在从各个统计数据提取相关性时使用各种启发式方
法。
具体地讲，本实施例的相关性提取装置34从窗口中的各个统计数
据的样本提取常数相关性、同一性(identity)相关性以及总和相关性。
另外，相关性提取装置34在搜索常数相关性和同一性相关性时执行启
发式方法。
下文中，将利用图5所示的示例性窗口描述相关性提取装置34在
提取相关性时的示例性操作。
首先，相关性提取装置34提取常数相关性。参照图6，由于统计
数据G的所有样本为7，看起来统计数据G为常数。因此，相关性提
取装置34发现统计数据G中的常数相关性(发现存在统计数据G＝常
数的规则)。另外，作为启发式方法，相关性提取装置34从窗口去除
具有所发现的常数相关性的统计数据G。这意味着如果相关性提取装
置34发现作为预定类型的相关性的常数相关性，则相关性提取装置34
移除具有这种常数相关性的统计数据。由此，窗口中留下6个统计数
据(统计数据A至统计数据F)。
接下来，相关性提取装置34提取同一性相关性。具体地讲，相关
性提取装置34利用如图7所示的方法提取同一性相关性。参照图7，
相关性提取装置34将窗口中的各个统计数据的样本串的顺序改变为字
典顺序。这意味着相关性提取装置34改变样本串的顺序，使得当从位
于窗口左侧的样本中的数字顺序地看时，具有较小数字的统计数据上
移。然后，相关性提取装置34将统计数据的样本串与紧下面的另一统
计数据的样本串进行比较，并且寻找基于预定标准被确定为相同的一
对统计数据。这里，例如，用于确定统计数据相同的所述预定标准是
可以是构成统计数据的各个样本和构成另一统计数据的各个样本完全
相同的情况。另外，例如，用于确定统计数据相同的所述预定标准可
包括统计数据的样本串、与另一统计数据的样本串中的相邻样本之间
的有限差分相同的情况。例如，如图7所示，在统计数据A和统计数
据B中，所有样本值均相同。因此，相关性提取装置34确定统计数据
A与统计数据B之间存在同一性相关性(发现存在统计数据A＝统计数
据B的规则)。另外，如图7所示，统计数据B或统计数据A的各个
样本值、与作为统计数据C中的有限差分的dstatisticC的值相同。因
此，相关性提取装置34确定统计数据B或A与dstatisticC之间存在同
一性相关性(发现存在统计数据B＝dstatisticC以及统计数据
A＝dstatisticC的规则)。
通过上述处理，相关性提取装置34提取同一性相关性。然后，作
为启发式方法，相关性提取装置34执行处理以将抽象类的代表留在窗
口中。在图7所示的情况下，如上所述，统计数据A和统计数据B的
值相同。如此，相关性提取装置34删除统计数据A或统计数据B的样
本。由此，统计数据A或统计数据B的样本被留在窗口中。
然后，相关性提取装置34提取总和相关性。具体地讲，相关性提
取装置34将每两个统计数据的样本相加，并且检查结果是否等于统计
数据的现有样本(相关性提取装置34可被配置为检查三个或更多个总
和)。另外，当搜索总和相关性时，相关性提取装置34可使用各个统
计数据的样本的有限差分。例如，参照图8，发现统计数据D是统计
数据E与作为统计数据F的有限差分的dstatisticF之和。因此，相关
性提取装置34发现统计数据D与统计数据E和dstatisticF之间存在总
和相关性(发现存在统计数据D＝统计数据E+dstatisticF的规则)。
通过上述方法，相关性提取装置34从窗口生成装置33所生成的
各个统计数据的样本提取相关性。然后，相关性提取装置34将说明所
提取的相关性的规则(验证之前的规则)发送给相关性验证装置35。
例如，相关性提取装置34将验证之前的规则，例如，统计数据G＝常
数、统计数据A＝统计数据B、统计数据B＝dstatisticC、统计数据
A＝dstatisticC、以及统计数据D＝统计数据E+dstatisticF，发送给相关
性验证装置35。
应该注意的是，相关性提取装置34可被配置为将说明所提取的相
关性的规则(验证之前的规则)存储在规则文件36中，代替将它们发
送给相关性验证装置35。
另外，由相关性提取装置34提取相关性的方法不限于上述方法。
相关性提取装置34可被配置为通过寻找窗口中是否存在满足预定相关
性的样本来提取相关性。另外，由相关性提取装置34提取的相关性不
限于上述那些。相关性提取装置34可被配置为基于统计数据或回归之
间的线性组合来提取规则。
相关性验证装置35具有将从相关性提取装置34接收的、验证之
前的规则(或者存储在规则文件36中的规则)，应用于各个窗口，从
而验证在验证之前的规则是否可被应用于各个窗口的功能。
具体地讲，如图9的(A)和(B)所示，相关性验证装置35将从相关
性提取装置34接收的、验证之前的规则(或者存储在规则文件36中
的规则)，应用于由窗口生成装置33生成的各个窗口，从而验证规则
的显著性(significance)。例如，相关性验证装置35验证规则是否能
够适用于各个窗口，并且测量应用成功的窗口的数量。然后，基于应
用成功的窗口的数量，相关性验证装置35计算规则的显著性。例如，
相关性验证装置35通过将应用成功的窗口的数量除以所有目标窗口的
数量来计算显著性。
然后，相关性验证装置35将经验证的规则存储在规则文件36中。
应该注意的是，例如，在相关性验证装置35将经验证的规则存储
在规则文件36中，可使用如上所述计算的显著性。这意味着，相关性
验证装置35可被配置为仅将显著性超过预定存储阈值的经验证的规则
存储在规则文件36中。另外，例如，在数据发送/接收装置31将规则
发送给统计数据压缩设备4时可使用显著性。这意味着，数据发送/接
收装置31可被配置为仅将显著性超过预定发送阈值的规则发送给统计
数据压缩设备4。
规则文件36是诸如存储器或硬盘的存储设备。规则文件36被配
置为存储从相关性验证装置35发送来的经验证的规则。具体地讲，规
则文件36从相关性验证装置35接收经验证的规则。然后，规则文件
36存储所接收的经验证的规则。存储在规则文件36中的经验证的规则
将经由数据发送/接收装置31被发送给统计数据压缩设备4。应该注意
的是，规则文件36可被配置为还存储验证之前的规则(从相关性提取
装置34发送来的规则)。
图10示出将要存储在规则文件36中的、经验证的规则的示例性
存储方法。如图10(A)所示，例如，作为组合方法，规则文件36可被
配置为以百科全书的方式存储各个规则的组合(以百科全书的方式列
出满足相关性的数据)。另外，如图10(B)所示，例如，作为基于抽象
类的方法，规则文件36可被配置为将规则存储为抽象概念。另外，如
图10(C)所示，例如，规则文件36可被配置为通过树方法，该树方法
是表现出相关性的一般规则与其例外的组合，来存储规则。规则文件
36可被配置为利用上述三种方法以外的任何方法来存储规则。
统计数据压缩设备4是利用由统计数据挖掘设备3发现并验证的
规则来压缩统计数据的信息处理设备。统计数据压缩设备4包括未示
出的CPU(中央处理单元)和存储设备(存储器和硬盘)。统计数据
压缩设备4被配置为通过执行存储在存储设备中的程序的CPU来实现
下述功能。
参照图11，统计数据压缩设备4包括数据发送/接收装置41、统
计数据文件42、经验证规则文件43和统计数据压缩装置44。
数据发送/接收装置41具有与存储系统2和统计数据挖掘设备3
发送和接收统计数据和经验证的规则的功能。例如，数据发送/接收装
置41接收由存储系统2发送来的统计数据(包括统计数据的文件)。
然后，数据发送/接收装置41将接收的统计数据存储在统计数据文件
42中。另外，例如，数据发送/接收装置41接收由统计数据挖掘设备3
发送来的经验证的规则。然后，数据发送/接收装置41将接收的经验证
的规则存储在规则文件43中。
统计数据文件42是诸如存储器或硬盘的存储设备。统计数据文件
42存储从存储系统2发送(由数据发送/接收装置41接收)的统计数
据。如下所述，存储在统计数据文件42中的统计数据，将由统计数据
压缩装置44利用统计数据挖掘设备3所找到的规则来压缩。
经验证规则文件43是诸如存储器或硬盘的存储设备。经验证规则
文件43存储由数据发送/接收装置41接收的经验证的规则。如下所述，
存储在经验证规则文件43中的经验证的规则将在统计数据压缩装置44
压缩数据时使用。
统计数据压缩装置44具有利用存储在规则文件43中的经验证的
规则来压缩存储在统计数据文件42中的统计数据的功能。统计数据压
缩装置44从规则文件43获得规则。统计数据压缩装置44还从统计数
据文件42获得统计数据。统计数据压缩装置44利用从规则文件43获
得的规则，来压缩从统计数据文件42获得的统计数据。然后，例如，
统计数据压缩装置44将压缩后的统计数据存储在压缩的统计数据存储
单元(未示出)中。
应该注意的是，统计数据压缩装置44可被配置为在如上所述利用
经验证的规则压缩统计数据之后，利用外部一般压缩器再次执行压缩
处理。
另外，统计数据压缩装置44可被配置为自己寻找诸如常数相关性
的简单相关性。在这种情况下，统计数据压缩装置44可被配置为利用
自己找到的相关性来执行压缩。
另外，统计数据压缩装置44可被配置为依据预定标准选择将要用
于执行压缩的经验证的规则。统计数据压缩装置44可被配置为执行抽
象类的展平(flattening)或者执行重新编号以交换统计数据所使用的标
识符。
数据压缩系统1的配置如上所述。接下来，将描述数据压缩系统
1的操作。首先，将参照图12描述统计数据挖掘设备3的示例性操作。
参照图12，数据发送/接收装置31获得由存储系统2中的各个存
储节点22收集的统计数据(步骤S101)。然后，数据发送/接收装置
31将获得的统计数据存储在统计数据库32中。
接下来，窗口生成装置33利用存储在统计数据库32中的统计数
据生成窗口(步骤S102)。应该注意的是，窗口生成装置33可通过从
自己先前生成的窗口提取统计数据来生成新窗口。这样，窗口生成装
置33生成窗口。
然后，相关性提取装置34提取窗口中的相关性(步骤S103)。
由此，相关性提取装置34获得规则(验证之前的规则)。然后，相关
性提取装置34将验证之前的规则发送给相关性验证装置35。
然后，相关性验证装置35验证从相关性提取装置接收的、验证之
前的规则是否适用于由窗口生成装置33生成的各个窗口(步骤S104)。
例如，相关性验证装置35测量适用验证之前的规则的窗口的数量。然
后，基于测量的适用规则的窗口的数量，相关性验证装置35计算规则
的显著性。另外，相关性验证装置35将经验证的规则存储在规则文件
36中(步骤S105)。然后，例如，每当预定周期过去时，存储在规则
文件36中的经验证的规则将经由数据发送/接收装置31被发送给统计
数据压缩设备4。
统计数据挖掘设备3的示例性操作如上所述。接下来，将参照图
13详细描述由相关性提取装置34执行的相关性提取的示例。
参照图13，相关性提取装置34首先提取常数相关性(步骤S201)。
具体地讲，相关性提取装置34提取各个样本值为常数的统计数据，作
为具有常数相关性的统计数据。然后，相关性提取装置34将具有常数
相关性的统计数据从作为相关性提取目标的窗口移除(步骤S202)。
接下来，相关性提取装置34提取同一性相关性(步骤S203)。
具体地讲，相关性提取装置34在按照字典顺序改变窗口中的统计数据
的顺序之后，将相邻统计数据的相应样本进行比较，从而提取基于预
定标准被确定为相同的一对统计数据。然后，相关性提取装置34执行
处理以将各个抽象类的一个代表留在窗口中(步骤S204)。这意味着
如果提取相关性A＝B，则相关性提取装置34将A或B的样本值从窗
口移除。从而，仅A或B的样本留在窗口中。
然后，相关性提取装置34提取总和相关性(步骤S205)。具体
地讲，相关性提取装置34将每两个统计数据的样本相加，并且检查结
果是否等于统计数据的现有样本。在搜索总和相关性时，相关性提取
装置34使用各个统计数据的样本的有限差分。由此，相关性提取装置
34提取具有总和相关性的统计数据的组合。
相关性提取装置34的示例性操作如上所述。接下来，将参照图
14描述由统计数据压缩设备4执行的示例性压缩处理。
参照图14，统计数据压缩设备4的数据发送/接收装置41定期地
(或者当需要时)从存储系统2获得统计数据(步骤S301)。然后，
数据发送/接收装置41将获得的统计数据存储在统计数据文件42中。
另外，统计数据压缩设备4的数据发送/接收装置41例如从统计
数据挖掘设备3定期地获得经验证的规则(步骤S302)。然后，数据
发送/接收装置41将获得的经验证的规则存储在经验证规则文件43中。
通过这两个操作，统计数据被存储在统计数据文件42中，经验证
的规则被存储在经验证规则文件中。然后，统计数据压缩装置44利用
存储在经验证规则文件43中的经验证的规则，对存储在统计数据文件
42中的统计数据执行压缩处理(步骤S303)。
由统计数据压缩设备4执行的统计数据压缩处理的示例如上所
述。
如上所述，根据本实施例的数据压缩系统1包括设置有相关性提
取装置34的统计数据挖掘设备3，和统计数据压缩设备4。通过该配
置，数据压缩系统1能够基于由相关性提取装置34提取的相关性执行
统计数据压缩处理。通常，各个软件单元彼此协作地操作。因此，由
各个软件单元获得的统计数据之间常常存在相关性。因此，通过利用
那些相关性压缩统计数据，可在维持高可靠性地同时更有效地压缩统
计数据。
另外，本实施例的统计数据挖掘设备3包括窗口生成装置33。通
过该配置，可提取由窗口生成装置33生成的窗口中的相关性。通常，
从其提取相关性的各个统计数据的样本的数量未必相同。因此，在提
取相关性时，有必要在具有不同数量的样本的统计数据之间提取相关
性，由此算法变得复杂。另一方面，利用窗口，可在各个统计数据具
有相同数量的样本的状态下提取相关性。结果，提取相关性的算法可
简化。另外，在比较结果时可使用明确的标准。
另外，根据本实施例的统计数据挖掘设备3包括相关性提取装置
34和相关性验证装置35。通过该配置，由相关性提取装置34执行的
相关性提取工作以及由相关性验证装置35执行的验证工作可被分离。
结果，可更有效地执行并行计算。
另外，根据本实施例的相关性提取装置34被配置为使用一些启发
式方法。具体地讲，相关性提取装置34被配置为在提取常数相关性之
后，将具有此类常数相关性的统计数据从窗口移除。另外，相关性提
取装置34被配置为在提取同一性相关性之后，仅将各个抽象类的一个
代表留在窗口中。通过该配置，可在具有常数相关性的统计数据已被
移除的窗口中，执行同一性提取工作。还可在具有常数相关性的统计
数据已被移除并且各个抽象类的代表以外的统计数据已被移除的窗口
中，提取总和相关性。通常，与提取同一性相关性的工作相比，提取
常数相关性的工作是较轻松的工作。另外，与提取总和相关性的工作
相比，提取同一性相关性的工作是较轻松的工作。由此，利用如上所
述的启发式方法，轻松的相关性可隐藏繁重的相关性。
应该注意的是，在本实施例中，描述了压缩由存储系统2收集的
统计数据的情况。然而，本发明的适用还不受限于压缩由存储系统2
收集的统计数据的情况。例如，本发明可适用于压缩网格服务器之间
收集的统计数据的情况。
另外，将由数据压缩系统1压缩的对象未必限于统计数据。数据
压缩系统1可用于压缩具有相关性的各种类型的数据。
另外，尽管在本实施例中，统计数据挖掘设备3和统计数据压缩
设备4是不同的信息处理设备，但是本发明的实施例不限于上述情况。
本发明可通过包括统计数据挖掘处理器和统计数据压缩处理器的信息
处理设备来实现。另外，本发明可被实现于存储系统2上。
第二示例性实施例
下面将以论文的形式描述本发明的第二示例性实施例。
第1章介绍
分布式系统目前越来越流行。它们的复杂性使得难以在线检测它
们，因此正在开发收集系统状态以用于延迟调查的方法。获得足够大
量的数据可能是关键，因此正在改进压缩算法。本论文提出并评估一
种用于压缩由商业、二级存储、分布式系统—NECHYDRAstor生成的
统计数据的新方法。统计数据是内置于HYDRAstor中的数以千计的度
量的频繁探测的值，其旨在呈现系统的当前状态。
真实生活使用的情况下出现的改进统计数据的压缩的需求-客
户的数据中心中运行的HYDRAstor的问题的调查需要获得统计数据。
然而，由于安全原因，一些机构显著限制了可从其下载的数据的量。
自然，拥有的统计数据的样本的量少显著增加了分析系统的问题所花
费的时间和努力，因此需要在不增加传递的分组的大小的情况下，扩
大从客户获得的统计数据的样本的数量。另一方面，所提出的方案应
该是无损的，因为在解压缩之后样本的值的任何失真均可能导致从此
类统计数据的分析得出错误的结论。
本论文的目的是提出一种有效、无损地压缩统计数据的方法，其
被调节以与NECHYDRAstor系统紧密协作。所提出的解决方案已实
现，因此在所创建的软件上进行不同的实验以测量可实现的压缩比和
性能。本论文所提出的解决方案使得支持工程师能够从客户的设备接
收统计数据的更多样本，而无需下载更多数据。结果，由于HYDRAstor
的状态的调查更简单，HYDRAstor的服务质量提高。
本论文由六章组成。
2.“背景”包含对于在准备解决方案的同时理解所作决策而言重
要的NECHYDRAstor的简要介绍，。
3.“基于相关性的压缩的分布式模型”介绍了所提出的解决方案
的概念。
4.“相关性挖掘器”描述并评估了所实现的两种工具中的第一种，
即StatsMiner。在一些人造数据上以及在从客户接收的统计数据上均进
行了评价。
5.“压缩器”描述了所实现的工具中的第二种，即StatsCompressor。
此章还包含在一些人造数据上工具的评价，并且讨论了StatsMiner与
StatsCompressor的几个协作模型。
6.“对于从客户获得的真实统计数据的评价”评价了所实现的软
件及其在从客户接收的统计数据上的使用的不同模型。
7.“相关工作”总结了本论文所触及的领域中进行的其它研究。
基于此进行了对未来工作的一些建议。
第2章背景
本论文中尝试解决的问题出现在使用NECHYDRAstor系统的过
程中，因此所述解决方案应该解决HYDRAstor的特定要求。因此，需
要所提及的系统的简短描述，涉及它对所开发的解决方案的约束。
HYDRAstor的全面规范可见于[DGH+09]中。
此章包含三个章节。
2.1.“HYDRAstor的概述”包含HYDRAstor系统的描述。这里将
定义稍后将参考的许多重要术语。
2.2.“系统监测”讨论了日志收集和分析问题，包括HYDRAstor
视角。此章节还包含本论文中所描述的研究为何重要的扩展说明。
2.3.“在HYDRAstor中收集统计数据”介绍了在HYDRAstor系统
中收集统计数据的处理的一些技术细节以及用于存储统计数据的文件
的格式，因为所描述的解决方案必须适应框架。
2.1.HYDRAstor的概述
NEC公司所提供的HYDRAstor是代替磁带驱动器使用硬盘驱动
器的企业级、可伸缩、二级存储系统。它支持以高吞吐量和低延迟写
备份数据(这些是这种类型的软件的关键要求)。这非常重要，因为
备份操作可显著降低被备份系统的效率，所以备份窗口总是具有非常
有限的长度。这构成对本论文中所描述的解决方案的主要约束——与
HYDRAstor一起运行的软件均不能对写性能具有负面影响。
由于写是HYDRAstor中进行的主要操作，所以将更详细一点地描
述它。当进入系统时，备份数据的字节流被分成可变大小的、不可变
的组块流。如果一些组块已经存在于系统中，由于组块的内容散列化
的使用而将发现这一事实，此类组块将不被写两次。该处理被称为在
线去重(inlinededuplication)，此概念的使用对HYDRAstor的性能很
关键。如果组块应该被存储，则应该对将它放在哪里作出决策。
HYDRAstor事实上是容错分布式系统，由一组服务器组成。为了在服
务器或盘故障的情况下保持数据的一致性，各个组块通过对其应用里
德所罗门码来被擦除编码。使用编码的组块的SHA-1散列和分布式散
列表概念来确定存储组块的逻辑位置。最后，通过内部网络将数据传
送给与在先前步骤中选择的逻辑位置对应的物理节点。
自然，可从HYDRAstor读数据，但是此处理不像写那样常见，因
此不像写那样重要，因此针对写(而非读)来优化系统。读通常不频
繁。
最后，可从HYDRAstor删除数据。快速、低延迟写的代价是删除
处理变得相当复杂并且充当垃圾收集机制。存在三个明显不同的阶段，
每个阶段对系统具有不同的影响。首先，如果接收到从系统移除一些
数据的命令，则它仅影响内部元数据，真实数据仍存在于驱动器上。
为了评定应该擦除哪些物理存储的组块，应该运行称为删除的特殊处
理。其目的在于使得一些组块“待删除”。删除是复杂的分布式算法，
这里将不进行描述，但是完整描述可见于[SAHI+13]。然而，在开发统
计数据压缩时应该考虑关于删除的一些事实。首先，删除周期性地运
行，优选很少使用此工具。这意味着此处理的统计数据长时间段地保
持不变。其次，它在操作时消耗相当多的资源，因此当正在进行删除
时HYDRAstor的行为可不同。值得指出的是删除可与写同时运行。如
已经提及的，删除仅将一些物理组块标记为未用。为了检索盘空间，
应该运行空间回收处理。与删除处理相反，空间回收对HYDRAstor没
有太多影响，仅是作为所谓的后台任务不时地运行的许多处理中的一
个。
2.1.1.版本
HYDRAstor系统存在三种主要版本——H2、H3和H4。H2是最
早商用的一个，H3是在客户中最受欢迎的，H4是目前投入市场的一个。
这些数字代表硬件和软件二者，因为HYDRAstor是作为完整的解决方
案(安装有上述软件的特殊设计的服务器)而销售的。
自然，NEC发布了产品的补丁和更新。由于该系统大量用在大型
公司(是HYDRAstor的主要目标群)中，所以应用补丁可能是非常困
难和耗时的处理——应该有足够大的服务窗口以进行所有维护。因此，
消费者仅安装他们真的需要的这些补丁。结果，在HYDRAstor的每一
个版本内存在许多不同的子版本。不奇怪的是各个子版本的行为可略
有不同，因此所设计的统计数据压缩的解决方案应该适当灵活。此外，
HYDRAstor具有用于根据具体客户的需求来进行性能调整的许多配置
参数。
基于相关性的统计数据压缩将至少用在H4系统中，但是简单地
将它移植到先前版本的可能性确实会附加上。
2.1.2.物理架构
HYDRAstor的各个安装由专用于两个不同的任务的两种类型的服
务器组成。系统的心脏是保存数据的存储节点(SN)。所有存储节点
经由网络连接连接在一起。另一类型的服务器是加速节点(AN)，其
用作HYDRAstor的网关，提供数据存取API。各个AN与所有SN连
接，但是任何两个AN之间不存在链接。AN还连接到客户的服务器(SN
没有)。
AN与HN之间的区别对于统计数据压缩而言很重要，因为在两种
类型的服务器上运行的处理收集统计数据，但是这些统计数据不相同，
节点的行为不同。在AN和HN的H3版本处理中，各自具有约50000
个统计数据，然而，在AN节点上运行的处理的统计数据包含更多约束。
在H4版本中，代替AN，存在组合了旧AN和SN的特征的混合
节点(HN)。在此配置中，来自旧AN和SN的处理在相同机器上同
时运行。
决定对从SN或HN节点收集的统计数据进行本论文中所提出的所
有实验(在HN的情况下，仅考虑来自存储处理的统计数据)。这是因
为几个技术原因。此外，在此方法中，实验结果更一致。据信，由来
自AN的处理生成的统计数据的压缩比将甚至好于从SN收集的统计数
据的压缩比。
2.1.3.软件架构
单个节点的架构
HYDRAstor是对消息传递通信进行扩展使用的并行应用。
HYDRAstor的不同子系统(称为单元)由于OOSF框架(面向对象的
服务器框架)而彼此交换消息。此外，OOSF框架在自己的线程上调度
单元代码的执行(它实现了用户空间线程的构思)。如果存在针对特
定单元的消息，则该单元被放入队列并等待空闲调度器的线程执行它。
调度器不提供任何形式的先占，因此运行代码直至控制返回到调度器
或者运行线程发送消息。可容易地看出，调度器明确地不对运行一段
代码的时间周期提供任何约束。在将描述收集统计数据的处理时OOSF
框架的概念将很重要。
各个单元具有自己的特性以及它所生成的特定统计数据的集合。
这里将不单独地描述该统计数据，因为它们非常专业化并且存在太多。
另一方面，这里应该提到特定现象。首先，单元常常对它们所接收和
发送的消息的数量进行计数，因此看起来将有一些统计数据等于其它
统计数据之和。其次，例如，当仅在两个单元之间发送特定类型的消
息并且在这两个单元中对这些消息进行计数时，一些统计数据将为相
同的。另一相似情形发生在消息触发动作(被计数)或者待发送的另
一类型的消息时。从更高的视角看这两个示例会发现另一“社会学”
同一性来源——有时由于一些工程原因，同一事物可在几个地点被计
数。首先，在系统维护的情况下使同一事物在两个地点被计数(因此
也具有两个名称)可能更方便。HYDRAstor是性能关键软件，虽然维
护的容易甚至更重要。其次，不同单元的开发者有时不知道他们的同
事已经创建了记录同一事件的日志的一些代码，有时要早好几年。这
看起来是由于团队之间缺少交流或者仅仅是由于人们无法就每一条代
码交换过于细节的知识的简单事实而引起的。据此，可提出假设，在
足够大的各个系统中，将存在统计数据或日志的一些重复。看起来易
于通过准备能够基于一些规则生成一些丢失统计数据的工具来减少统
计数据的重复。唯一的问题是从哪里获得这些规则。准备基于专业知
识的规则常常花费过大，因为它涉及读取软件代码并且做出决策，两
个统计数据是否总是相同或者是否存在一些罕见例外。
分布式系统视角
如前所述，HYDRAstor是可伸缩、容错的分布式系统。各个物理
代码可容纳称为组件的多个逻辑服务器。在许多情况下，例如，如果
发现了故障盘或者系统由于其扩展而需要再平衡，组件可从一个节点
迁移到另一节点。而且，组件的数量可随时间而改变——如果数据量
增加，可能需要组件的分割以实现更好的性能。自然，组件分布的改
变不是非常常见，但是来自此类事件的统计数据时常被分析，因为它
们描绘了系统的极端情况的类型。存在与各个组件有联系的许多统计
数据，在组件实际上驻留的节点上收集它们。这意味着在物理节点之
间的组件转移的情况下，一些统计数据停止在旧的节点上被收集，而
开始在另一节点上被记录日志。
2.2.系统监测
2.2.1.动机
调查[OGX12]识别出收集日志的五个原因：
1.调试，
2.性能，
3.安全，
4.报告和剖析，
5.预测。
前两个——调试和性能——对于HYDRAstor而言最重要。如前所
述，所设计的解决方案应该在出现漏洞或者期望改进性能的情况下，
改进客户的站点处的HYDRAstor设备的维护质量。为了实现这一目标，
统计数据常常用作关于特定硬件和软件配置以及系统的当前状态的知
识来源。此用途一定程度上运用了上面所列的项目“报告和剖析”。
然而，[OGX12]的作者更进一步，描述了使用人工智能(例如，聚类工
具)来准备关于系统的半自动生成的报告。看起来合理的是考虑这种
类型的工具是否将不能用于HYDRAstor维护，特别是它将帮助问题区
域的初步可视化。当来到“预测”点时，HYDRAstor已经具有异常检
测工具。它利用(leverage)基于专业知识的规则，用于发现系统的异
常行为。还未提及的上面所列的最后一项是安全。看起来HYDRAstor
不会有安全问题(感知为入侵或违规)，因为该系统是“非常”后端
的解决方案，已经通过高层软件(特别是创建备份的软件)加强了安
全。
2.2.2.日志和统计数据
到目前为止可互换地使用了术语“日志”和“统计数据”，现在
是时候在它们之间进行清楚的区分，并且说明统计数据为何如此广泛
地用在HYDRAstor中。
传统上，“日志”由许多行组成，各行具有时间戳，描述系统中
的单个事件-例如，消息的接收。日志通常极其冗长，这既有有利的一
面也有不利的一面。由于单个日志消息(通常)映射至单个事件，所
以基于日志的调试更容易，因为可得到事件的所有细节。同时，从这
个意义上讲大系统收集巨量的日志，因此对性能带来可见的负面影响。
此外，得到与特定情形有联系的一组消息需要大量的过滤和变换。并
且，获得系统行为的完整图像更复杂，因为它涉及解析和聚合来自日
志的数据。
统计数据，当用在HYDRAstor中时，是周期性收集的样本序列。
例如，每20秒就将传递给各个盘的许多请求转存。请求的数量是已知
的，但是关于请求来源或其具体类型的所有知识丢失，这使得调试更
复杂。然而，如HYDRAstor的示例表明的，这对于有经验的维护者而
言看起来不是问题。另一方面，统计数据有利于得到系统的总体图像
的处理，因为从它们当中绘制涉及最小量的解析和变换。此方法的最
大优点在于它节约了盘空间，因此使得对性能的影响最小化。统计数
据可被当作高级日志——它们通过聚合数据以减少细节为代价给出了
全景。可将消息从日志转换为统计数据，但是反过来不行。统计数据
事实上是日志的一种有损压缩。
HYDRAstor收集日志和统计数据二者，但是统计数据更重要。经
典的日志覆盖最重要的情形，例如断言失败。一些传统代码仍记录某
些常见情形，但是因此它对性能有很强影响，所以此类代码被变换为
使用统计数据。HYDRAstor中的统计数据用于保存关于当前系统状态
的所有信息。如前所述，根据在设备中的角色和软件版本，各个机器
生成约50000条不同的统计数据。
2.3.在HYDRAstor中收集统计数据
2.3.1.收集统计数据的处理
在HYDRAstor中收集统计数据可分成多个阶段。
第一个阶段可称为单元本地：各个单元具有表示统计数据的计数
器的映射。适当的事件触发这些计数器上的动作。这里应该提及的是，
所描述的计数器不存储任何时间戳。
第二阶段称为节点本地：一个专用单元周期性地向其它单元发送
消息(MessageRequestStats)，以传递回它们的统计数据的当前值(计
数器的值)。接收到此消息有时导致重置一些统计数据，例如告知“最
近”改变的那些。应答消息被重定向至负责将数据存储在盘上的
StatsGather模块。StatsGather按照将在下一子章节中描述的格式之一转
存统计数据(参见段落2.3.2)。
节点本地阶段具有在设计本论文中所描述的解决方案时考虑了的
一些特殊特性。最重要的问题在于，调度器没有确保任何消息集合(特
别是发送的MessageRequestStats的任何子集)将被同步地传送给它们
的接收方。这意味着如果存在总是相同但是驻留于不同的单元中的两
个统计数据，则它们的值可能略微不同。所述变化大多数情况下非常
小，但是造成了寻找相关性更困难的问题。此外，它还影响压缩。此
问题将稍后解决。另一方面，此问题对源自同一单元的统计数据没有
影响。
与收集统计数据的节点本地阶段有联系的另一阻碍是这样的事
实，可按照不同的频率向不同的单元请求统计数据。目前，每20秒向
所有单元请求统计数据，然而，计划允许一些单元每5秒被询问一次。
结果，所设计的软件应该能够比较以不同频率收集的样本。
存储在盘上的统计数据等待直至用户请求它们(下载阶段)，或
者它们变得足够陈旧从而被删除以节约空间。如今，没有其它方式来
在HYDRAstor中使用统计数据。诚然存在异常检测工具，但是它是在
线工作的。
可注意到，来自不同节点的统计数据永远不会被合并成一个文件。
此类动作将涉及许多网络业务，看起来在下载阶段无法给予任何益处，
因为如果用户必须下载统计数据，则从一个节点下载数据或从几个节
点下载数据之间不存在差异，特别是存在使该处理自动化的脚本。相
反，单个文件包含从节点上运行的所有单元收集的统计数据。
2.3.2.在HYDRAstor中存储统计数据的文件的格式
HYDRAstor，可能作为存在延伸市场的任何商业软件，使用几种
类型的格式来存储统计数据，可在各种版本的系统上看到格式的演变。
自然，存在统计数据文件应该满足的一些期望。尽管统计数据大多数
情况下利用特殊工具(称为StatsViewer)来可视化，有时仍需要文件
的手动操纵。因此，好的格式应该允许容易地使用诸如grep、cut、sort
等的标准unix工具来操纵。另一方面，此类文件不应该使用过多空间，
并且生成它们不应该对工作系统有影响(不消耗CPU和内存)。
XML文件
XML文件是HYDRAstor中用来存储统计数据的最老文件。文件
由描述元数据的少许(约20个)标记组成，文件的剩余部分是标记，
每行一个，各个标记精确地告知一个统计数据——有名称、时间偏移、
收集频率和样本序列。这样的数据组织方式具有许多优点——人可读，
生成文件的处理不复杂，并且市场上有一些现有的XML解析器。另一
方面，XML文件使用许多盘空间。此问题通过利用gzip工具压缩文件
来缓解。然而，XML文件在H4版本中不再使用，因此所设计的解决
方案预计不会直接读取此格式的文件。
Zstat文件
Zstat文件格式由H3的更新之一引入，并且自此以后成为存储统
计数据的基础格式。引入它是统计数据收集模块的功能扩展的一部分。
此格式提供更好的空间利用，并且如今，收集样本的确切时间被保存。
然而，该格式是手工的，因此传送特殊的解析器。像XML文件的情况
中一样，Zstat文件利用外部压缩器来压缩。此问题将在本论文中稍后
讨论。
所设计的软件应该支持Zstat文件。其实际一面将稍后描述，但是
理论上此格式对所创建的解决方案施加所有实际约束。首先，从Zstat
文件的视角，所利用的压缩应该是无损压缩——压缩并解压缩的Zstat
文件应该与基础的那一个同形。其次，压缩文件将与基础Zstat文件进
行比较以确定压缩比。据此，由StatsCompressor创建的文件的格式将
被称为Zplus以突出这两个要求。
Zstat文件由两部分构成，各个部分具有相同的行数(参见图15)。
在第一部分中，各行包含一个统计数据的名称、它的一些元数据以及
文件唯一的数值标识符。在第二部分中，各行(除了是时间戳序列的
几行以外)包含统计数据的标识符及其样本序列。请注意，本论文中
将不详细描述时间戳，因为所设计的解决方案不使用它们，因此它们
被当作一种元数据并且仅仅被复制到Zplus文件。重要的是，文件中的
各个统计数据可具有不同数量的样本。Zstat文件利用gzip压缩器来压
缩。
Pack统计数据
Pack统计数据格式最初为试图解决在从限制下载的数据量的客户
下载它们的情况下、使Zstat文件大小最小化的问题而设计的。Pack统
计数据文件是在下载阶段通过特殊工具从常规Zstat文件创建的。还存
在将将Pack统计数据转换回Zstat文件的相似程序。
所描述的文件格式与Zstat文件格式相似，但是使用众多简单的技
巧来使文件更小。首先，此类文件仅包含所有统计数据的子集。用户
可手动地定义它，或者利用以由HYDRAstor的开发者手动定义的预定
义的切割方案之一。其次，与Zstat文件的情况下的gzip对比，Pack
统计数据文件利用bzip2工具来压缩。
Zstat文件由两个主要部分组成(参见段落2.3.2)：统计数据的名
称到数值标识符的映射，以及所提及的标识符到样本序列的值的映射。
可观察到，统计数据的真实名称具有长的公共前缀(例如，
METRIC::DataSynch::DiskRequestManager::RequestsCount::total::reques
tsInProgress::RecentMax和
METRIC::DataSynch::DiskRequestManager::RequestsCount::cannotExecu
teBecauseOfLimit::Current)。
在Pack统计数据文件中，名称到标识符映射以树的形式描述，其
具有内部节点中的茎干(METRIC、DataSynch、DiskRequestManager
等)以及叶中的标识符。此方法将空间消耗减少了约20-30％。
所设计的解决方案可在产品化阶段期间被合并到Pack统计数据工
具中。以上提出的所有构思可由所设计的StatsCompressor使用。压缩
名称-标识符映射的方式看起来非常有效，就此将不进行改进，特别是
本论文聚焦于样本压缩的问题。限制文件中的统计数据的数量的构思
只有用户确切知道实际上需要哪些统计数据时才有意义，在实践中在
开始漏洞调查时并非如此普遍。在这种情况下，下载预定义的任意定
义的“重要”统计数据的集合。由于缺少关注特定情形的许多统计数
据，所以使用这些文件很困难。据信，所设计的解决方案将使得如下
情形，即当有必要限制统计数据的文件内容时的情形，非常罕见。
数据库文件
到目前为止描述的所有格式用于在客户的站点处存储统计数据并
且将它传送给支持团队。作为用于从统计数据进行绘制的工具，
StatsViewer能够读取上述格式(除了需要被首先转换的Pack统计数据
以外)，但是它需要将所有数据加载到内存中。如果正在分析来自长
周期的统计数据，则打开它们需要较长时间。从该问题，唤起了对按
需统计数据加载的需要。解决方式是将统计数据的文件(不同格式)
转换为一个标准化的数据库格式。事实上，数据库文件是sqlite数据库，
其保存已经解析的数据，准备好由StatsViewer使用。应该提及的是，
仅在支持团队的机器上创建数据库——由于它们的大小和特定应用，
它们既不会在客户的站点处创建，也不会通过互联网来传送。
从搜索的解决方案的视角来看，数据库文件有兴趣作为所创建的
一些工具的输入，因为它允许程序仅以一种格式读取文件，因为存在
从任何版本的XML或Zstat文件形成数据库文件的转换器。
第3章基于相关性的压缩的分布式模型
本论文提出了一种使包含从客户下载的统计数据的文件的大小最
小化的新方法。该解决方案应该是无损的，并且对在客户的机器上运
行的HYDRAstor系统没有负面影响。如已经在段落2.1.3中提及的，
据信许多统计数据与其它统计数据相关，本论文介绍了一种尝试运用
这一事实的压缩方法。另一方面，所描述的解决方案被设计为与
HYDRAstor协作，因此它可使用关于压缩文件的格式和内容的一些领
域知识。
本论文的中心概念是相关性，它是多个统计数据的样本之间的关
系。例如，如果文件中存在具有相同样本值序列(f(0)＝5,f(1)＝3,f(2)＝8
和g(0)＝5,g(1)＝3,g(2)＝8)的两个统计数据(统计数据f和g)，则它
们相关——它们之间存在同一性(将被表示为f＝g)。此类相关性可在
文件的压缩(事实上，基于相关性的压缩)期间使用，因此足以转存
统计数据g的样本序列并且保存还存在统计数据f并且f＝g的信息。自
然，同一性仅仅是相关性的非常简单的示例——更复杂的是例如和(则
h＝j+k，其中h、j、k是统计数据)。
技术上，存在两种类型的相关性——严格相关性和弱相关性。前
面的段落介绍了严格相关性：f＝g。弱相关性的示例是以下同一性——
存在统计数据fw和gw，fw(0)＝5，fw(1)＝3，fw(2)＝8并且gw(0)＝5，gw(1)＝6，
gw(2)＝8，并且fw＝gw+d，其中d＝[0,3,0]并且被称为偏差向量。事实上，
任何统计数据集合之间总是存在弱相关性。自然，弱相关性越好，偏
差向量所包含的数字越小。偏差向量的概念在关于StatsCompressor的
章(第5章)中将是重要的。在本论文中，如果使用相关性的概念，
则它总是严格相关性(除非明确地提及弱相关性)。
基于相关性的方法已按照称为StatsCompressor的独立工具的形式
实现。该工具将在客户的机器上运行以压缩包含统计数据的Zstat格式
(参见段落2.3.2)的文件。该工具输出Zplus格式，其是Zstat格式的
扩展版本，的文件。StatsCompressor使用基于相关性的方法以及关于
Zstat文件的格式和内容的一些领域知识。
单个Zstat文件包含数以千计的统计数据，各个统计数据具有许多
样本，因此可存在统计数据之间的众多相关性。在客户的机器上发现
这些相关性可能对同时运行的HYDRAstor的性能有很强的负面影响，
因此决定准备单独的工具，称为StatsMiner，其将用于在支持站点机器
上运行的同时搜索相关性。该工具为了灵活读取数据库文件，并且生
成包含规则的文件。单个规则描述统计数据之间的单个相关性。利用
关于相关性的质量的一些元数据来丰富规则，例如，相关性被发现多
少次。StatsCompressor使用由StatsMiner创建的规则来进行基于相关
性的压缩。
StatsMiner和StatsCompressor形成图16中所呈现的分布式压缩模
型。该图示出为了从客户下载利用所设计的软件压缩的统计数据，而
应该进行的连续操作。
StatsMiner在支持团队的站点处运行，StatsCompressor在客户的站
点处运行。支持团队在示例文件集合上运行StatsMiner以创建规则文
件。目前实现的工具版本还没有实现全面计划的功能——本论文中提
出了一些算法，但是它们由于缺少时间还没有被实现。然而，目前，
由StatsMiner创建的规则的数量过大，从而难以将它们全部直接上传给
客户，因此必须对规则作出某种选择。这种规则的有限集合偶尔被传
送给客户，例如，利用包含一组补丁和更新的分组，然后被存储在客
户机器的硬盘驱动器上。
如果支持团队需要从客户下载统计数据，则利用StatsCompressor
压缩所选择的Zstat格式的文件。自然，所有Zstat文件可在创建时被
自动压缩，但是这看起来是一种资源浪费——研究的目的是在有限的
可用带宽的情况下增加技术支持所下载的样本的数量。决定
StatsCompressor将仅利用领域知识，而不在字节级别运行任何算法。
此假设的目的在于聚集于统计数据之间的高级别相关性，而不聚集于
较低的字节级别。据信，现有通用压缩器将更快速更好地实现这种类
型的压缩。此外，实现这种算法将非常易于出错。从客户下载就绪的
Zplus文件。
获得的Zplus文件应该被解压缩以重新创建原始Zstat文件(因此
所使用的压缩方法是无损的)。在研究过程中，由于缺少时间而没有
实现解压缩器，然而，可证明原始和解压缩的Zstat文件相同。已对所
实现的压缩算法进行了细致审核以证明压缩方法是无损的。还存在功
能测试，其检查StatsCompressor是否生成遵守规范的Zplus文件。
所呈现的StatsMiner与StatsCompressor协作的分布式模型是最一
般的一个。其它模型将稍后在段落5.10中讨论。
在后续章中，[GKP94]中定义的有限差分算子(以下Math1)的
概念将被扩展地使用：以下Math2。应该注意的是，在以下描述中，
使用“d”代替Math1，如以下Math3中所示。
[Math.1]
Δ
[Math.2]
Δf(x)＝f(x+1)-f(x)
[Math.3]
Δ＝d
第4章相关性挖掘器
此章包含StatsMiner的描述和评价，它是用于发现统计数据中的
相关性的工具。StatsCompressor稍后将使用描述所找到的相关性的规
则来压缩具有统计数据的文件。
此章包含以下章节：
4.1.“概述”介绍StatsMiner的概念——它应该解决的问题、高层
架构、主要假设以及所选择的技术。
4.2.“试验台”描述StatsMiner测试的方法以及此处理过程中所使
用的数据。
4.3.“窗口”定义StatsMiner中所使用的最重要的实体之一，窗口。
除了该定义之外，介绍用于准备窗口的不同算法。实现了它们中的一
个。
4.4.“存储所发现的规则”解决了在RAM中保存所发现的规则的
问题，因为发现这对工具的性能很关键。
4.5.“相关性的类型”介绍相关性的发现算法的划分。
4.6.-4.8.“全局互算法”、“局部互算法”、“内算法”描述分成
段落4.5中所介绍的类别的具体挖掘算法。需要注意，并非全部概念均
已被实现(特别是局部互算法全部没有实现)，尽管它们全部被讨论
以构建StatsMiner的可能特征的全景。
4.1.概述
相关性挖掘器，称为StatsMiner，是作为本论文中所描述的研究的
一部分而创建的数据挖掘工具，用于搜索统计数据之间的相关性。它
作为将要在开发者的机器上运行的工具而被创建，至少在整个项目的
实验阶段是如此。根据资源的消耗，其一部分或者整个应用可在产品
化期间(参见段落5.10.4)被合并到StatsCompressor中。StatsMiner
的代码按照允许快速产品化的方式来编写——它遵守编码标准和良好
实践，是面向对象的，等等。
该工具读取数据库文件(参见段落2.3.2)并输出包含规则的CSV
文件。
4.1.1.问题陈述
统计数据之间的任何相关性可利用方程来描述。据信，所分析的
统计数据之间的几乎所有关系均可利用线性方程来描述(但是允许统
计数据的有限差分)。此假设基于HYDRAstor开发者的专业知识，这
些开发者预计不会有其它类型的相关性(即，二次方程)出现。线性
代数给出了一些用于发现线性相关性的工具(例如，高斯消去法)，
但是它们有两个缺点——首先，它们要求所分析的统计数据的数量与
每一个统计数据的样本的数量相同。如果存在约50000个统计数据，
此外还包括它们的有限差分，则将意味着将需要各个统计数据的100
000个样本，由于通常每20秒收集一次统计数据，所以将需要花23天
收集的样本！此方法的第二个问题是高斯消去法具有O(n3)的复杂度，
因此在使用100000个统计数据的情况下，计算时间将不能接受的高。
另一约束来自于内存消耗——存储包含C++的双重(double)的大小为
100000*100000的矩阵将消耗75吉字节的内存！
由于无法挖掘线性相关性，所以对结果强加的一些要求应该被削
弱以使得问题更容易并因此可求解。首先，看起来非常明显的是，相
关性的系数将为整数——此观察来自于描述事件的离散空间的统计数
据的本质。遗憾的是，搜索具有整数系数的线性相关性是NP难题——
存在从子集-和问题的简单归约。由于所研究的问题无法被限制为约束
更多的一个，所以选择了另一方法。存在在输入数据上运行的大量简
单算法，它们中的每一个发现统计数据之间的另一类型的精确定义的
关系。此方法的结果将是从对线性相关性的真实搜索获得的结果的一
些子集，但是计算上述子集是可实现的。
4.1.2.阶段
StatsMiner的主要功能是发现统计数据中的相关性。该工具的前几
次运行已证明它可找到甚至数十亿的相关性，因此很快，关于相关性
的精确定量信息的需要变得明显。此外，由于待搜索的数据量非常大
(一次100000个统计数据)，所以加入了用于加速挖掘处理的一些启
发法。最重要的一个是，如果发现一些统计数据上的一种相关性，则
在搜索其它类型的相关性之前将它们从工作集移除。此问题将在涉及
具体算法时详细描述，但是该方法的效果之一是轻松的相关性可隐藏
繁重的相关性。
为了应对这些情况，工具的工作被分成两个阶段。第一阶段是挖
掘阶段(图17)，在这一阶段从头开始挖掘统计数据集合中的相关性。
自然，这是耗时的处理。例如，在100000个统计数据(各自具有20
个样本)上挖掘花费约300秒。自然，使用所有加速启发法。第二阶
段是验证(图18)。在这一阶段，工具搜索之前发现(或者从文件加
载)的相关性的出现，并且仅检查相关性是否适用于工作集。对于如
之前所介绍的同一数据集合，花费约30秒。
划分成阶段导致可更好地并行计算。映射-归约范式最适合于工具
的使用模式。在挖掘和验证阶段的情况下，待研究的数据库文件集合
可通过多个机器散布(映射步骤)，并且在归约步骤中，包含所生成
的规则的文件可被容易地合并成一个。
事实上，挖掘器和验证器可以是两个不同的程序。此方法可导致
二者性能更好(因为它们可更具体调整)，代价是开发和维护成本更
高。
4.1.3.编程语言的选择
程序可像整个HYDRAstor软件一样在Linux上运行，并且以C++
编写。语言的选择出于多个原因。务实的一个原因是HYDRAstor的开
发者使用C++和Python，因此选择这两个中的一个将由于使用现有代
码数据库并且向其他程序员寻求帮助的可能性而使得开发更容易。另
外，预计程序将消耗很多CPU和内存。尽管第一个要求可通过使用
Python来满足(C++当然更快，但是开发处理慢许多)，但是第二个要
求导致选择C++。这是很好的决策，因为假设被证明是对的。以标准
配置运行的StatsMiner使用几吉(giga)字节的RAM，如果软件以Python
来编写，则这将由于Python中的差的垃圾收集而使得应用不能用。
4.2.试验台
4.2.1.测试数据
StatsMiner的所有测试在以下数据集合上进行：
1.LRT_A-从H4(存在1个HN和4个SN)上的长期运行测试随
机选择的50个Zstat文件(从5327个可用文件)。此测试持续约两周，
其目的是模拟HYDRAstor的正常使用还有一些极端情况。上述文件已
被转换为数据库格式。各个文件由约50000个统计数据组成，各个统
计数据具有60至100个样本(但是一个文件中的所有统计数据具有约
相同数量的样本)。
2.CL-从接收自HYDRAstor的真实用户(客户)的文件当中随机
选择的30个XML文件。文件由安装有各种补丁和更新的各种版本的
HYDRAstor系统生成。仅同意大小为2MB至4MB并且由SN生成的
文件进行此测试。所选择的文件已被转换为数据库格式。它们包含约
50000个统计数据，各个统计数据具有140-240个样本(但是一个文件
中的所有统计数据具有约相同数量的样本)。
CL和LRT_A测试集包含不同数量的文件(30和50)，因为在
CL集合的情况下使用50个文件会由于所发现的大量规则而导致RAM
不足，实验无法成功的完成。
4.2.2.测量性能
所有测试在具有两个IntelXeon5645CPU以及48GB的RAM的
开发机器上运行。时间和内存利用以参数％U(在用户模式下进程所花
费的CPU总秒数)和％M(进程在其寿命期间的最大驻留集大小)运
行的时间程序来测量。校正内存消耗结果，使得它们不受熟知的时间
计数漏洞的影响[com13]。
4.3.窗口
窗口是StatsMiner中的中心概念，可被描述为所有可用统计数据
的可比的、长度相同的样本序列的集合。窗口的长度是各个序列中的
样本的数量。窗口的宽度是统计数据的数量。事实上，窗口是矩阵。
需要注意，窗口不包含关于它所包含的任何样本的收集时间的任何信
息——这是简化窗口的使用的假设。
图19呈现了长度为10宽度为7的示例窗口。单个文件可被切成
许多窗口(比较呈现示例Zstat文件的图15与示出从所述文件生成的
一个窗口的图19)。搜索相关性的各个算法要求窗口作为输入。由于
窗口性质(各个统计数据的样本的数量相同)，挖掘算法的实现被简
化。使用窗口的另一益处是结果比较的标准清楚——规则总是应用于
特定数量的、良好定义的窗口。另一方面，由工具分析的文件可包含
各个统计数据的不同数量的样本，因此与“在3个文件中发现规则”
的陈述相比，说“在3个窗口中发现规则”精确许多。在验证过程中
扩展地使用窗口的概念——具有描述相关性的规则和窗口，针对各个
规则检查两个事实，然后将其保存(参见图18)：相关性是否可应用
于窗口(所有预期的统计数据存在)以及样本是否确实满足该相关性。
作为挖掘算法的输入，窗口的内容对发现的相关性的数量和类型
具有显著影响。两个独立的问题是重要的——窗口的大小以及生成其
的算法(从加载自数据库文件的统计数据得到窗口)。
窗口生成看起来是琐碎的，但是在此处理的过程中需要面对一些
问题，使其非常复杂。如之前所提及的，在HYDRAstor中，可按照不
同的频率收集统计数据，在单元层面上讲收集处理是异步的，统计数
据可能在每一刻出现或消失，最终，样本被存储在长度变化的文件
(Zstat)中。在接下来的章节中将介绍用于生成窗口的两个算法。
窗口的大小对在给定数据库文件中发现的相关性的数量和质量具
有巨大影响。由于实验已证明太小的窗口会是误导性的，因为所找到
的相关性可仅仅是偶然的，但是在过长的窗口中，许多相关性可能被
遗漏，因为统计数据收集处理的异步本质打乱了样本，使得严格相关
性消失。严格相关性是令人关注的，因为与搜索弱相关性相比，找到
它们要容易许多(参见段落4.7.5)。
相关性的质量的度量是其显著性水平。对于相关性C，它被定义
为Math4。
[Math.4]
s i g n i f i c a n c e ( C ) = a p p l i e s ( C ) a p p e a r s ( C ) ]]>
其中
applies(C)＝相关性C严格应用于的窗口的数量
appears(C)＝相关性C所预期的所有统计数据出现的窗口的数量
不同相关性类型的显著性的绘制将在段落4.9中介绍。
如果未明确说明，本论文中所描述的所有规则均在具有10至20
个样本的长度的窗口上生成。
需要注意，各个窗口还包含其所有统计数据的有限差分——据信，
如果f和g为统计数据，则可存在类似df＝g的一些相关性。此假设基
于这样的事实：存在一些“最近”统计数据，其测量在最后几秒内一
些参数的改变。
4.3.1.窗口生成算法
窗口生成是为挖掘算法准备数据——从数据库加载的统计数据的
样本必须被分成窗口，因为搜索相关性的所有算法均在窗口上工作。
在此子章节中，将描述创建窗口的三个方法——两个可置换算法
(贪心算法和时间戳知晓算法)，一个窗口的更高级来源的构思(随
机窗口)。然而，仅贪心算法已被实现并详细描述。剩余两个在如果
贪心算法没有良好执行的情况下(尽管它良好执行了)作为可能扩展
来介绍。
贪心算法
用于窗口生成的贪心算法被第一个实现。该算法的构思通常非常
简单——对于各个统计数据，算法从数据库文件加载样本，并且将这
些数据放入不限制大小的内部样本队列中。各个统计数据具有其自己
的样本队列。如果所有统计数据的样本队列的大小(除了空的以外)
至少等于最小窗口长度(M)，则将各个统计数据的前M个样本从队
列移至新窗口。自然，窗口不能比期望的最大长度长。然而，如果队
列之一包含比最小窗口长度少的样本(N)，则从数据库加载更多样本。
如果数据库中不再有样本，则从所有缓冲放弃该数量的第一样本(N)。
该算法被称为“贪心”以描绘这样的事实：它不使用样本的时间
戳。它可导致如下易出错的情形：当创建窗口但是样本的时间戳存在
移位，因此它们理论上不再能按列比较(因此如果存在两个统计数据f
和g，并且分析第i样本，则f(i)无法与g(i)进行比较)。幸运的是，它
仅涉及单元间相关性，因为一个单元的统计数据的第i样本总是具有相
同的时间戳。自然，如果没有考虑样本的时间戳，则挖掘算法可发现
两个单元之间的一些不适当的相关性，但是此类相关性将在验证阶段
中得到低等级。如果存在许多同时出现或消失的统计数据，则此算法
的另一问题出现，因为可能无法创建任何窗口。
该算法的缺点由其优点，主要是速度，来平衡。如果n是将用于
计算的样本的总数，则算法的复杂度为O(n)。这样生成的相关性易于
使用是该算法的另一个有利的一面，因为如果StatsMiner不使用时间
戳，则StatsCompressor也不需要它们，从而使得该工具更快速更简
单——它可仅取几个样本序列并尝试对它们应用拟合相关性。最后，
此算法的实现非常快速并且它非常有用，因为找到的相关性的数量足
够大。
时间戳知晓算法
贪心算法的主要问题在于它没有考虑样本的时间戳。为了解决这
一问题，计划将要设计时间戳知晓算法。然而，同时，按照使得贪心
算法比之前更好地执行(创建更多窗口)的方式，改进了数据库格式
的文件的生成器。此外，StatsCompressor在利用在以贪心方式生成的
窗口中挖掘的规则工作时所实现的良好压缩比证明了，在生成窗口时
使用时间戳不像之前看起来那么关键。由于该时间戳知晓算法还未创
建，因此在本论文中不详细描述样本的时间戳，因此它们未被任何实
现的算法使用。
随机窗口
随机窗口是再用(或者说“重使用”)由上述算法生成的窗口的
构思。如提及的，StatsGather处理是异步的，因此即使来自两个单元
的统计数据之间的相关性客观存在，它仍有可能由于所比较的样本之
间的略微偏离而不被发现。这种现象不仅仅是理论上的——已经在真
实数据中观察到它(在搜索StatsMiner中的漏洞时)。窗口的大小被
设定为10至20个样本，两个明显相同的统计数据有10％的概率偏离。
不幸的是，在每个生成的窗口中存在至少一个偏离，因此根本不会找
到相关性。随机窗口解决这一问题。
构思是从随机取自以经典方式生成的窗口的几列样本创建窗口，
例如，第一窗口的第4、第6和第7样本以及第二窗口的第1、第6和
第8样本将被转变成新的随机窗口。此新的窗口将自然满足窗口定义
的所有预期，虽然样本将不再是连续的。
根据将从其取样本集合的窗口的总长度，随机窗口概念将有助于
对抗样本的偏离。自然，偏离的概率仍相同，但是可从一个数据库文
件生成比正常窗口多许多的随机窗口，生成的随机窗口越多，得到没
有偏离，因此包含之前被隐藏的严格相关性的随机窗口的概率越高。
此外，生成随机窗口的成本非常低，因为所有样本均已经存储在存储
器中(无需从数据库文件读取数据)并且可被编程而无需在旧窗口与
新的随机窗口之间复制样本。
该算法由于缺少时间还未被实现，但是它看起来是StatsMiner的
容易且有效的扩展。
4.3.2.总结
窗口是统计数据及其样本的方便容器，它使得挖掘算法的实现更
加容易。创建窗口的方式对StatsMiner所发现的规则有显著影响。一个
参数是窗口长度(因为其宽度取决于从数据库加载的数据)，另一个
参数是用于将样本插入窗口中的算法。贪心算法是此章节中所介绍的
概念当中唯一被实现的一个。实践中它很好地执行(因为在这样形成
的窗口中发现了许多规则)，虽然使用时间戳知晓算法可导致获得更
真实的相关性。另一方面，随机窗口是绕过巨量挖掘算法的限制-无法
发现弱相关性-的一种手段。
4.4.存储所发现的规则
StatsMiner发现统计数据之间的相关性并且创建规则以保存所获
得的知识。这些规则应该以某种方式被存储在存储器中，然后被存储
在硬盘驱动器上。有两种相反的方法来以简单的方式这样做(组合方
法和基于抽象类的方法)，还有一种复杂方法基于来自较简单的方法
的最佳构思(使用树)。在此章节中，f、g等表示不同的统计数据。
在存储规则的组合方法中，特定统计数据的各个相关性被分别存
储。例如，如果存在相关性f＝g，则存储描述f和g的同一性的规则。
然而，为了保存相关性f1＝g1＝h1，需要使用三个同一性规则，每一个描
述两个特定统计数据之间的关系。在抽象类方法中，需要使用一个规
则来存储相关性f＝g，还仅需要一个规则来存储相关性f1＝g1＝h1。
使用组合方法导致更高的内存消耗，例如，当应对简单总和p＝q+r
时，如果p＝p1并且q＝q1＝q2并且r＝r1＝r2＝r3，则将创建24个规则来存储
所有相关性！在抽象类方法中，仅创建4个规则——每一个抽象类一
个，简单总和一个。问题是，是否保存p＝q＝r并且在描述p、q和r的
抽象类的其它规则的情况下使用这些规则，或者保存总和作为
((p＝p1)＝(q＝q1＝q2)+(r＝r1＝r2＝r3))。总之，从内存消耗的角度，基于抽象
类的方法看起来肯定更好，但是当应对多个窗口时情况变得更复杂。
我们假设在窗口W1中，找到之前描述的相关性(总和)。然而，
在窗口W2中，相似但不是相同的相关性：p＝p1并且q＝q1＝q2并且r1＝r2＝r3
(以下Math5)。如果使用组合方法，则此改变将不涉及新规则的创
建——更新现有规则的使用计数器(用于计算显著性)就足够了。同
时，对抽象类方法没有好的解决方案。一个构思是增加新的规则来描
述类r1＝r2＝r3(或者(p＝p1)＝(q＝q1＝q2)+(r1＝r2＝r3))，但是规则p＝q＝r该
怎么办——应该增加规则p＝q＝r1？如果是，则在W1的情况下相同的
相关性将被表示两次(因此在验证阶段被计数两次)。此问题可通过
将规则(p＝p1)＝(q＝q1＝q2)+(r＝r1＝r2＝r3)分成两个规则：
(p＝p1)＝(q＝q1＝q2)+(r1＝r2＝r3)和(p＝p1)＝(q＝q1＝q2)+(r)来解决。这将解决使
用计数器的错误值的问题，但是规则的总数可呈指数激增，因为(p,p1)、
(q,q1,q2)、(r,r1,r2,r3)的子集的每一个组合均可出现。另选地，可使用
规则p＝q＝r，因为存在类r1＝r并且可运用传递闭包的概念。然而，在这
种情况下，每一个规则可稍后应用于每一个窗口，因为抽象类的数量
和大小将增长——结果，规则使用计数器将完全是误导性的。
[Math.5]
r≠r1
总而言之，基于抽象类的方法是内存消耗和使用计数器的准确性
之间的权衡。另外，在组合方法中，验证之前和之后的规则的数量相
同，但是在抽象类方法的情况下，如果选择了分割规则作为对计数器
问题的补救，则验证之后的规则的数量可急剧增加。
将这两个方法的优点结合得出将各个规则存储为树，因此所有规
则创建森林。本论文仅包含此方法的草案。树的根包含最一般形式的
相关性(例如，(p＝p1)＝(q＝q1＝q2)+(r＝r1＝r2＝r3)——参见图20)，内部节
点包含关于抽象类的分割的信息列表(例如，以下Math6和r)，叶
具有使用计数器。在从根走到叶的过程中，可确定通过从所访问的内
部节点到存在于根中的规则应用切割而创建的相关性集合的使用计数
器的值是多少。如果仅存在单抽象类，此表示使用至少与抽象类方法
相同的内存量(如果不存在内部节点的话)，不超过组合方法(对于
树实现的细节)的内存量。此数据结构的复杂度是其内存效果的代价。
这仅是该方法的草案，其还未实际测试。
[Math.6]
在所设计的解决方案中，选择组合方法，因为其实现更简单，动
作更快(抽象类的分割看起来成本很高)，充分准确并且具有可预测
(尽管较高)的内存消耗。此外，以组合方式存储的规则易于可视化
或合计——在计数器上进行一些操作就足够了。当规则被转存在硬盘
驱动器上时，它们以CSV格式来存储，因此易于利用类似LibreOffice、
MicrosoftExcel或者仅仅bash脚本的工具来操纵它们。
基于抽象类的方法可以是在客户站点处存储规则时减小规则的大
小的方式——所有挖掘可利用组合方法来进行，然后实际发送给客户
端的数据可被转换为抽象类形式(特别是如果当时不需要具有使用计
数器)。这可被认为是规则文件的一种无损压缩。
4.5.相关性的类型
相关性可被分成两种主要类别——互相关性和内相关性。最受关
注的是互相关性，其描绘两个不同统计数据之间的关系。此类型的基
本示例是同一性(f＝g，其中f和g是两个统计数据)。完全不同的是
内相关性，其仅影响一个统计数据并且描述其一些可重复的特性。内
相关性的最简单的示例是常数。
相关性的另一划分与挖掘算法的技术限制关联——在大的统计数
据集合中搜索相关性的能力。搜索大多数类型的简单相关性(类似同
一性)可在包含所有可用统计数据(在移除常数统计数据之后，70000
个)的集合中进行。此类相关性(以及因此，挖掘算法)被称为全局
相关性。另一方面，无法一次在许多统计数据(例如，一次不超过1000)
之间有效地找到更隐蔽的相关性，类似线性组合，——此类相关性(以
及算法)将被称为局部相关性。局部挖掘算法的使用需要首先选择将
运行此类算法的所有可用统计数据的子集——这构成全局与局部挖掘
算法之间的主要差异。
从压缩的角度，互相关性是最有价值的相关性。全局或局部之间
的区别没有不同，虽然希望全局相关性的数量大于局部相关性的数量。
相反，对全局相关性的挖掘看起来更简单并且成本更低，如果CPU和
内存消耗将保持在可接受的水平，则可在客户站点处进行这种类型的
分析。
请注意，在第3章中介绍了严格相关性与弱相关性之间的区别。
然而，通常，本论文中所讨论的所有相关性均为严格的。
4.6.全局互相关算法
如前所述，搜索常规的线性组合成本过高，但是可容易地找到一
些类的线性组合。互相关算法在窗口中寻找不同统计数据之间的这些
特殊类型的关系。在此章节和随后的章节中，n将是窗口中的统计数据
的数量(窗口的宽度)，k将是各个统计数据的样本的数量(窗口的长
度)。
需要注意的是，仅所介绍的算法中的一些被实现并在实践中评估：
用于同一性发现的排序算法以及用于简单总和发现的蛮力算法。其它
算法应该被当作如果性能不满意的情况下的可选方案。一些算法具有
所描述的一些可能扩展。这些扩展可增加找到的规则的数量。
4.6.1.同一性的挖掘
同一性是互相关性的最基本的示例。据信由于相同的事件常常在
系统的不同层中被独立地记录，所以同一性的数量将非常高，例如，
接收或发送的消息的数量。
搜索同一性的算法在窗口中发现样本向量的抽象类。为了减少后
续挖掘算法的运行时间(参见图17)，仅各个抽象类的一个代表被留
在窗口中，剩余成员被移除。平均而言，IdentityMiner得到包含20366
个统计数据的窗口作为输入，并且它输出包含12236个统计数据的窗
口(两个值均是针对LRT_A数据集计算的)。
用于同一性发现的排序算法
描述
此算法的构思非常简单——各个统计数据可被当作样本向量，因
此统计数据可利用样本值的词典比较物(lexicographicalcomparator)
来排序。当使用类似合并排序的标准算法时，算法的此步骤的复杂度
为O(knlogn)。复杂度的下界(以下Math7)来自决策树分析[Knu98]，
此复杂度通过[FG05]中描述的算法来实现。然而，由于在StatsMiner
中通过指针来访问样本向量，所以上述文章的作者建议经典快速排序
也可具有O(nk+nlogn)的复杂度。
[Math.7]
ω(nk+nlogn)
在对样本向量进行排序之后，花费O(nk)时间来检查后续向量是否
相同，因此可记录同一性相关性。总之，所实现的算法具有O(nklogn)
的复杂度，但是理论上可实现O(nk+nlogn)的最佳情况复杂度，但是
需要更多努力。
自然，如果在窗口中两个统计数据f和g相同，则它们的有限差
分也相同(df＝dg)。然而，不存在相反暗示(以下Math8)。StatsMiner
的目的是为StatsCompressor生成规则，因此保存规则f＝g就足够了。
由于实际执行的原因，规则df＝dg从未被创建——它是基于没有太多
(df＝dg以及以下Math9)的示例的假设的启发性构建。
[Math.8]
[Math.9]
f≠g
测试结果
该算法快速(尽管理论上不是最佳的)并且生成许多规则。在示
例窗口(图19)中，将创建以下规则：
1.stat_alpha＝stat_beta。
2.stat_beta＝dstat_gamma。
3.stat_alpha＝dstat_gamma。
在真实HYDRAstor的统计数据中找到的一些同一性(将不说明其
名称的含义，因为这将需要系统内部的精确描述)：
1.DISK::sdb8::readsMergedPerSec＝DISK::sdb8::readsPerSec
2.METRIC::Aio::aioCtx-shred::AioStat::numberReqsStarted＝
METRIC::Aio::aioCtx-shred::AioStat::numberReqsCompleted
3.METRIC::transaction::FP::05DM::tl::syncs::req::NumStarted＝
METRIC::transaction::FP::05DM::tl::creations::req::NumStarted
在客户的日志上运行该算法花费(总共)21秒，生成776814个
规则(平均每一分析的窗口57210个规则)。(需要注意，一个规则
可在许多窗口中被发现，因此它在各个窗口的情况下单独地影响“每
一分析的窗口的规则的平均数量”，但是在讨论所生成的规则的“总”
数时该规则仅被计数一次。)对LRT_A数据的分析导致在54秒的累
积时间内挖掘561560个规则(平均每一分析的窗口29026个规则)。
结果的讨论可见于段落4.9。所发现的规则的显著性将在段落4.9中讨
论。
用于同一性发现的散列(hashing)算法
描述
先前算法的主要问题在于，在最差情况下，应该比较各个向量中
的所有样本的值，以对向量集合作出次序。提高排序算法的速度的最
简单的方式之一是首先比较向量的散列-仅在散列相等的情况下才返回
到向量值的比较。先前算法的其余部分保持不变。可自由选择散列方
法。
该算法在最差情况下的复杂度仍为O(nklogn)，但是平均情况下
的复杂度为O(nk+nlogn)。重要的是，如果向量的散列已经被实现，
则从常规的排序算法升级到其散列版本应该非常简单。
由于用于同一性发现的排序算法很好地执行，所以散列版本还未
实现。
4.6.2.简单总和的挖掘
简单总和是在所有系数均等于一的情况下统计数据之和：
f＝g+h+...。这种类型的关系看起来在统计数据之间非常常见，因为常常
存在表示事件类的数量的计数器以及呈现子类事件的数量的一些其它
计数器。更具体地讲，来自HYDRAstor的示例是METRIC::
transaction::FI::State::opened::NumStarted＝METRIC::transaction::FI::
State::opened::NumOutstanding+METRIC::transaction::FI::State::opened::
NumFinished。
总和具有的元素越多，算法的复杂度越高。下面介绍的算法被设
计为搜索两个统计数据之和(f＝g+h)，因此否则的话其理论复杂度太
高。实际上，如果其性能是可接受的话，它们可用于挖掘更多元素之
和，因为它们的仅有已知替代是搜索全线性组合(参见段落4.7.4)，
其成本也较高，但是仅仅是局部方法。
挖掘简单总和的成本非常高，因此此时应该避免任何类型的无用
工作。如果挖掘总和与挖掘同一性一起进行，则在窗口中通过挖掘同
一性的算法发现的所有抽象类可被减少为仅一个代表——如果此代表
出现在任何总和中，则其抽象类的各个成员可出现在相同的地方。如
前所述，StatsMiner将规则以组合形式存储在存储器中。因此，寻找出
现抽象类之一的代表的规则，导致向数据库增加许多新规则。因此，
StatsMiner可使用巨量的内存(许多吉字节)，此外，观察到执行减缓
(由于遍历数据结构)。自然，通常创建如此多的总和规则是很好的，
但是从压缩的角度，同一性规则优于总和规则，创建太多总和规则只
是资源的浪费，因此它们实际上是无用的。为了略微降低内存消耗，
决定不寻找仅由有限差分组成的总和(它们被找到但放弃)。据信，
这种类型的关系在现实中不常见，但是偶尔可能经常出现。此决策被
证明非常幸运，因为StatsMiner的性能得到显著改善——可利用约
30GB的内存结束LRT_A集合中的挖掘，而之前，开发者机器快速地
用光内存。
平均而言，此章节中所描述的任何类别的算法得到包含12236个
统计数据的窗口作为输入(对于LRT_A集合)。
用于简单求和发现的蛮力算法
描述
蛮力算法不是太复杂——每两个统计数据的样本被求和，然后检
查结果是否等于任何现有统计数据。该算法的成本为(kn2+kn2log
n)＝O(kn2logn)，因为存在一定数量的成对统计数据将被求和，如以下
Math10所示，对一对求和与k成线性关系，检查结果是否等于现有统
计数据意指在统计数据的有序集合中的二分查找，复杂度为O(klogn)。
[Math.10]
n ( n - 1 ) 2 ]]>
上面介绍的总和模型假设加法是可交换的。对于浮点数，如果它
们的表示使用不同的指数，则在对超过两个元素的序列求和的情况下
并非如此。此外，即使仅搜索两个元素的和，结果的舍入(数值误差)
在实现此算法的过程中也是实际问题。作为解决方案，使用longdouble
型来对样本进行排序(代替常规的double型)。
测试结果
该算法为客户日志创建了(总共)25803555个规则，花费了6137
秒(平均每一分析的窗口4601590个规则)。LRT中的挖掘导致在20
402秒(340分钟)内发现(总共)13738732个规则，平均每一分析
的窗口生成431324个规则。由于使用组合形式来存储规则，所以由更
新规则的数据库而导致运行该算法的较长时间。结果的讨论可见于段
落4.9。所找到的规则的显著性在段落4.9中讨论。
该算法将在示例窗口(图19)中找到以下规则：stat_delta
＝stat_epsilon+dstat_zeta。
在真实HYDRAstor的统计数据中找到的一些求和规则(将不说明
其名称的含义，因为这将需要系统内部的精确描述)：
1.METRIC::dci::NumFinisedGetReqs＝METRIC::dci::HintVector
WI::NumNegHintHits(finitedifference)+METRIC::dci::NumHashArrayGet
Reqs(finitedifference)
2.DISK::sdl2::totalBandwidth＝DISK::sdl::writeBandwidth+
DISK::sdl::readBandwidth
3.DISK::sdb6::writesMergedPerSec＝DISK::sdb12::readsMerged
PerSec+METRIC::ackCollector::dataLocs::dataLocCacheSize::RecentAvg
可能扩展
此朴素算法的成本非常高，挖掘三个元素之和看起来根本不是好
的构思。另一方面，可实现简单启发以使它合理。在发现一些统计数
据(被称为lhss——先导)等于一些其它统计数据总和之后，可尝试对
lhss求和并且检查结果是否不与任何其它现有统计数据相同。此构思基
于这样的认识：常常存在计数器的层次结构——存在一些零级计数器
告知一些事件的数量，存在一些一级计数器是零级计数器之和，等等。
用于简单总和发现的散列算法
加法散列
作为减小StatsMiner的CPU消耗的方法，已经在讨论用于同一性
发现的散列算法(参见段落4.6.1)时建议了散列法。发现总和的处理
也可利用此方法的优点，虽然可使用特殊的散列函数——加法散列函
数。
加法散列函数应该具有以下性质：
以下Math11
这里，
以下Math12、13
[Math.11]
H ( f → + g → ) = H ( f → ) + H ( g → ) ]]>
[Math.12]
统计数据的样本向量
[Math.13]
H：散列函数Qn→N
事实上，从线性代数的角度，这种函数是一种“弱化的”线性函
数(仅需要可加性——而非完全线性)。
好的散列函数应该具有两个性质(根据[Knu98])：
1.散列值的计算应该快速，
2.冲突的数量应该最小化。
以下函数满足此章节中所提及的所有标准(它是“好的散列函数”
并且它也是线性的)：
以下Math14
这里
以下Math15、16
b：大自然数
[Math.14]
H ( f → ) = ( Σ i f [ i ] · c [ i ] ) mod b ]]>
[Math.15]
统计数据的样本向量
[Math.16]
不太小的质数的向量
如上所述的函数H是加法的，因为它是所使用的所有操作均为加
法的。它可快速计算，特别是可使用SIMD指令来增加计算速度(易
于通过使得编译器能够自动将它向量化的方式来实现此函数)。存在
此函数的原型实现，它证明了如果b尽可能大(优选质数，但是在64
位机上264更加实际)并且c包含足够大的质数，则冲突数量在可接
受的水平，因此针对(以下Math18)的大多数值建立以下Math17。
另一方面，H表示一种模块散列函数，据信此类函数具有良好的性质
(根据[Knu98])。
[Math.17]
f[i]·c[i]＞f[i]·c[i]modb
[Math.18]
已试验性地实现了所描述的函数(作为整个算法)，虽然由于在
对IEEE-754浮点进行工作时无法以这种方式将浮点值散列化(舍入使
得整个构思不可用)，所以进一步工作(和实验)已停止。使用定点
运算将解决该问题，但是它还未最终实现。因此，该算法仅对整数值
适用。
描述
散列算法类似于蛮力算法，但是它使用改进的求和及比较方法。
由于加法散列，可从朴素算法的复杂度移除k因子，因此散列算法将
具有O(kn+n2+n2logn)＝O(kn+n2logn)的平均时间复杂度。蛮力算法的
复杂度中的k因子来自于样本的比较和求和，而当使用所描述的散列
方法时，两个操作均可在(O(1))时间中进行。自然，应该首先计算所有
统计数据的散列，此步骤具有(O(kn))的复杂度，但是另一方面，将数
据加载到内存具有相同的复杂度，因此实际上，此成本可被忽略。
测试结果
对此算法没有进行性能实验，因为它仅被部分地实现，还没有充
分调整，并且如已经提及的，它无法适当地用于浮点样本。
可能扩展
自然，在介绍蛮力算法时描述的启发法也可用于散列算法。值得
一提的是，预计计数器的层次结构现象将仅随整数值计数器出现，因
此这里，即使弱散列方法(不支持小数值)也将足够了。据此，混合
方法是可行的——蛮力算法可用于找出一级计数器，更高级计数器可
利用散列算法来寻找。就计数器的层次结构可出现在整数值统计数据
上的认识，是基于这样的假设：小数值的统计数据通常用于描述时间
周期，它们不会如此频繁地被一起求和。另外，如果存在小数值的更
高级计数器，则它们可能已经被一些源自浮点数的本质的数值误差所
污染，因此寻找此类总和会极其困难。
4.6.3.总结
全局互算法是StatsMiner的规则的最重要的来源。在所介绍的构
思当中，用于同一性发现的排序算法和用于简单求和发现的蛮力算法
已被完全实现，(功能上)进行了测试和评估。结果是它们可发现数
量巨大的相关性，规则的存储方式是它们的主要问题。
4.7.局部互算法
此章节中所描述的算法由于其特性或复杂度而无法在整个窗口上
运行。不幸的是，这里所介绍的构思由于对项目的时间限制均没有在
所描述的软件中实现，因此它们应该被当作未来工作的草案。
4.7.1.限制窗口宽度
随机选择
限制窗口的宽度的最简单方法(此类窗口将被称为缩小窗口)是
随机地选择期望数量的统计数据。倘若挖掘算法将能够很好地用于足
够大的集合，则这会是很好的想法。例如，在对LRT_A集合挖掘的情
况下，当计划运行局部互算法时，窗口中一次存在约15000个统计数
据(参见图17)。如果局部互算法接受减小至1000个统计数据的大小
的窗口，则随机地选择这些窗口内容看起来是非常好的想法，虽然应
该在实际中进行测试。另一方面，如果算法可能用于仅包含30个统计
数据的窗口(这是很可能的)，应该考虑基于一些知识来选择统计数
据的方法，因此窗口中的统计数据将在较高概率上有关系。
4.7.2.基于一些知识选择
在数据挖掘中，将相似对象分成一组的经典方法是聚类。对这一
领域有很多研究，因此提出了各种聚类方法。[Sch07]总结了当前的最
先进技术。在介绍选择最佳算法的一些建议之前，选择可能相关的统
计数据的问题应该被转变成聚类的语言。
统计数据的图形
聚类算法需要加权图形作为输入。在统计数据聚类的情况下，顶
点将表示统计数据，边缘的权重将描述其末端处的统计数据的相似性。
在这一点上很难讲图形是否应该是有向图形。有向图形包含比无向图
形多两倍的边缘，因此聚类变得更慢，但是它也可存储更多信息。问
题在于，在聚类中找到的一定数量的真实相关性方面看来，有向图形
的上述性质是否可有效地使用。看起来这应该通过实验来检查。评价
统计数据的相似性的所有启发法可应用于这两个版本的图形。
确定边缘的权重
边缘的权重应该表示它所连接的顶点(表示统计数据)的相似性。
用于评价相似性的各个启发法，其将简短介绍，应该返回范围[0；1]内
的浮点值。问题是，如果一些启发法返回不同的值，则边缘的权重应
该是多少。有两个主要方法，在某种程度上可被组合：
1.启发法所返回的值的加权平均，
2.选择启发法所返回的值当中的最小值或最大值。
如何确定边缘的权重的决策应该基于一些实验结果进行。
4.7.3.相似性的启发法
此章中所提出的启发法应该以两个统计数据为输入评估它们的相
似性。性能是关键要求，因为准备用于分析的统计数据集合应该不会
花费比分析本身更多的时间。这里将仅介绍启发法的概念。
启发法可被分成两个敌对的类别——静态和动态。与动态启发法
相反，静态启发法不使用所评估的统计数据的真实样本值。它们主要
分析统计数据的名称，尝试恢复开发者留在它们当中的一些知识。此
方法基于这样的认识：人总是按照有组织的方式来命名事物，命名相
似的实体仅有几种方式。另一方面，动态启发法基于统计数据的值，
尝试发现存在于当前窗口中的相似性。
应该使用两种类型的启发法来得到窗口中的统计数据之间的相似
性的全面图像，因为每一类型的启发法具有一些缺点，而另一类型的
方法(在一定程度上)减轻这些缺点。静态启发法聚集一些一般知识，
这些知识事实上无法应用于具体情况，而动态启发法向结果中增加一
些局部视角。另一方面，动态统计数据由于没有共同之处的、统计数
据的意外相似而发生很大偏差，但是此第二个事实只有通过静态启发
法才能发现。
静态启发法
相同前缀
HYDRAstor中的统计数据的名称由按照一般到具体的顺序出现的
一列项组成。事实上，统计数据的名称形成树(参见段落2.3.2)。名
称树统计数据中的路径越短(它们的共同前缀越长)，它们越相似。
非常相似的统计数据的示例是
METRIC::DataSynch::SynchronizerTask::SCC_RECONSTRUCTION::
numTasksStarted和METRIC::DataSynch::SynchronizerTask::
SCC_RECONSTRUCTION::numTasksFinished。
相同词干
如已经陈述的，统计数据的名称由一列项组成。此外，这些项中
的每一个由按照骆驼拼写法(CamelCase)拼写的词(称为词干)构建
而成，因此可容易地从长的名称提取单个词干。自然语言在进行命名
时看起来非常灵活，但是存在可用来对相似事物进行命名的有限一组
词，例如，METRIC::DataSynch::SccCache::SccChunksCount和
METRIC::memory::PerClass::DataSynch::SingleSccCache::SUM具有略
微不同的名称，但是实际上它们表示相同的事物，此外，它们的名称
共享许多相似的词干。这一观察可用于构建智能启发法以用于发现相
似统计数据——相似的统计数据在其名称中具有许多共同的词干。
相同发送者
Zstat文件包含关于从其收集了统计数据的单元(统计数据的发送
者)的信息。它可以是以下启发法的基础：来自相同单元的统计数据
比来自不同单元的那些统计数据更相似。此方法来自于这样的观察：
单元具有精确定义的、窄范围的功能，因此两个统计数据测量相关的
事件的机会更高。另一方面，来自不同单元的统计数据之间的关系看
起来更受关注(从理论的角度，因为它们可揭示HYDRAstor中的一些
非预期的依赖性)，但是通过此启发法评估它们欠佳。
相同类型
Zstat文件包含关于统计数据的类型(浮点、百分比、计数器等)
的信息。通常，相关性可更愿意出现在相同类型的统计数据之间，但
是已知一些例外情况(特别是当提到测量每秒的事件数量的定时器时，
例如，METRIC::flowControl::node::SlotsComputer::
Bandwidth::duplicateWriteCountPerSec)。
动态启发法
相关性
已经在窗口中相关的统计数据应该被当作非常相似。在同一性的
情况下，顶点甚至可被合并，但是将存在将所合并的顶点与其它顶点
链接的边缘的不同权重的问题。因此，具有表示“完全相似”的权重
的边缘应该是优选的。另一方面，相关性中涉及的统计数据越多，它
们之间的相似性越小(例如，如果存在相关性f0＝f1+f2和g0＝g1+g2+g3，
则与g0、g1、g2、g3相比，f0、f1、f2彼此更相似)。
相同的值改变次数
并非所有统计数据在每次它们被采样时改变它们的值。假设统计
数据之一是几个其它统计数据之和(f＝g+h+k)，则f改变其值的次数
至多与g、h、k一起改变的次数相同。自然，f可从不改变其值(如果
存在g＝-h且k＝常数)，但是据信这种情况极少发生。
所描述的启发法可通过以下假设来扩展：f可仅按照与g、h或k
的样本改变的次数相同的次数来改变其一些样本的值。不幸的是，由
于统计数据是异步地收集的，所以可存在一些时间偏移，使得整个概
念实际上不可用。然而，应该在实验中检查此陈述。
聚类算法
调查[Sch07]包含对可用的通用聚类算法的全面讨论。所选择的算
法应该具有以下性质：
1.应该可控制聚类的最大尺寸。
2.单个顶点可出现在许多聚类中(聚类重叠)。
3.算法应该快速并且不消耗过多内存。
看起来预期(3)是关键，因为如果聚类算法过慢，则将使得限制窗
口大小的处理无用。因此，算法的选择应该基于一些性能实验，使得
构建图形和选择聚类的处理足够快。适用于所描述的要求的最简单的
可能算法是创建与此时剩余的统计数据的数量一样多的缩小窗口——
精确地每一统计数据一个缩小窗口。针对统计数据f创建的这种窗口将
包含顶点f的限定数量的最近邻居。
4.7.4.线性组合
线性组合是统计数据之间搜索的最一般、因此最受关注的一种关
系。通过窗口，利用线性代数的方法来计算线性相关的统计数据。按
照此理论的语言，窗口可被表示成以下面的Math19表达的矩阵，其中
m是窗口的长度(样本的数量)，n是窗口的长度(统计数据的数量)——
需要注意的是，窗口这里被转置。预计m＝n，否则将存在至少|m-n|个
相关向量，此外，将出现结果的解释问题。上述要求是不在整个窗口
上运行线性组合的挖掘的最重要的原因，因为可能由于需要大量的样
本而无法满足此预期。
[Math.19]
W∈Qm×n
确定来自的W哪些向量线性相关的经典方法是高斯消去法。所描
述的问题可按照下面的Math20的形式来表达，因此求解线性方程的任
何算法可应用于它。非平凡x表示一些向量(统计数据)线性相关，
但是从x得到系数可能令人困惑，需要缩小列阶梯形式。
[Math.20]
A · x → = 0 → ]]>
手动编码的高斯消去法可能效率低(从高速缓存使用等的角度)
并且由于数值误差而发生偏差，因此这里优选使用线性代数库。事实
上，此类软件提供使用例如LU分解的计算，代替纯高斯消去法。
不管选择高斯消去法还是任何其它流行的分解方法，在给定窗口
中寻找统计数据之间的线性组合的复杂度均为(O(n3))。
4.7.5.回归
线性组合是StatsMiner所寻找的最强大的一种关系。然而，
StatsCompressor足够灵活以使用弱相关性。此特征被介绍用于缓解统
计数据的异步收集问题，它允许StatsCompressor甚至在挖掘阶段使用
无法完全应用的规则。此类规则可利用多维回归分析(在[SE02]中简要
介绍)来寻找。事实上，在此领域已进行了许多研究，因此选择挖掘
回归规则的最佳方法将需要进一步的调查。此刻，已经知道的是，这
种类型的任何算法由于其高复杂度((O(n3)或更差)而应该在缩小窗口
上运行。
4.7.6.总结
此章节中所介绍的构思由于缺少时间均没有被实现——详尽阐述
现有算法看起来比介绍一些新的、测试不好的算法更重要，特别是对
聚类的许多工作应该首先进行。另一方面，发现统计数据之间的线性
组合(严格线性组合和基于回归的弱线性组合二者)的能力可很大地
提高StatsCompressor所实现的压缩比。它对于异常检测也是重要的。
4.8.内算法
内算法搜索统计数据的可重复性质。由于无需在不同统计数据之
间比较样本，所以这种类型的算法可在统计数据的所有样本上运
行——将样本分成窗口可能是多余的。内算法的这种特性使得它们是
成为用于减小互算法的搜索空间的启发法的知识来源的完美候选。
4.8.1.发现常数
常数函数是内相关性(还有任何其它相关性)的最简单示例。意
外的是，许多HYDRAstor统计数据长时间保持恒定——平均来讲，来
自LRT的Zstat文件(具有约83个样本)包含约48940个统计数据，
11860个根本不改变其值(约25％)。
发现常数是简单的过程——检查给定统计数据的所有样本是否具
有相同的数值就足够了。在各个窗口中针对统计数据单独地进行该搜
索——它是来自以下假设的例外：寻找内算法仅对未被分成窗口的样
本才合理。事实上，由StatsMiner发现常数，但是StatsCompressor不
从规则文件加载这些规则——StatsCompressor自己发现常数(参见段
落5.8.1)。
发现常数统计数据之间的相关性(例如，求和)是比统计数据改
变值的情况简单许多的任务，但是此类互相关性从压缩的角度来看相
当无用。此外，将存在描述常数统计数据之间的相关性的数量巨大的
规则。因此，StatsMiner在生成窗口之后直接发现常数统计数据，这些
统计数据不用于此窗口上的进一步挖掘。
在示例窗口(图19)中，将找到一个常数：stat_eta。
该算法为客户日志创建了(总共)154023个规则，花费了8秒(平
均每一分析的窗口33152个规则)。LRT中的挖掘导致在38秒内发现
(总共)117310个规则，平均每一分析的窗口生成36633个规则。结
果的讨论可见于段落4.9。所找到的规则的显著性在段落4.9中讨论。
4.8.2.发现共同子序列
在一些统计数据中，样本的相同子序列可有规律地出现，它们是
压缩的很好候选。另一方面，这种类型的分析已经由每一个通用压缩
器，例如，gzip、bzip2或xz，进行，因此从压缩的角度，在StatsMiner
中挖掘这种类型的关系没有意义。另一方面，如果规则将用于压缩以
外的其它装置，则搜索共同子序列可能是有价值的。它可如所提及的
压缩器,(LZ77、LZMA算法)利用字典来进行。
4.8.3.总结
与互相关算法不同，本论文中没有过多讨论内相关算法。然而，
发现常数对于搜索互相关性的算法的快速和有效工作很关键。
4.9.总结
图21收集StatsMiner的挖掘和性能结果。
请注意，在分析CL集合时，可生成约249个窗口，但是那样的
话所发现的规则将使用所有可用内容。这是仅使用30个数据库(而非
所计划的50)的原因——在分析第33个数据库时，机器的内存(48GB)
交换，StatsMiner被停止。
针对CL集合创建的规则的数量比LRT_A集合大2倍，虽然所分
析的窗口的数量小5倍。此行为的原因看起来复杂。首先，LRT_A集
合是在应该模拟正常HYDRAstor运行的测试期间创建的统计数据上构
建的。然而，CL集合包括来自客户的真实数据，它们的系统行为可不
同。此外，各个客户具有自己的HYDRAstor使用模式，因此即使存在
两个相似的设备，仍可存在一大组独特的相关性。然而，CL集合包含
由安装了各种补丁的、不同版本的HYDRAstor收集的统计数据。从这
一角度，，LRT_A集合的结果表明StatsMiner在分析来自特定版本的
HYDRAstor的统计数据时如何运行，而CL集合上的实验对应于发现
不同版本的系统上的相关性。
有趣的是，在CL集合中每窗口创建的同一性规则的数量是LRT_A
的情况下的两倍。此外，如果在两个集合中所分析的窗口的数量相同，
则在CL集合中发现同一性将花费约100秒，因此比LRT_A集合多两
倍。很难讲为何在CL集合中找到如此多的同一性。可能使用
HYDRAstor的真实方式仅仅是长期运行测试所模拟的行为的较小子
集？幸运的是，大量的同一性肯定是正面的，因为同一性的压缩最有
效(参见段落5.9.3)。
求和规则的数量远大于其它相关性合起来。然而这是一种错
觉——使用保存规则的组合形式的结果。在窗口中找到的同一性越多，
创建的求和规则越多。此结论可在CL集合中清楚地看到。
为了使得所发现的规则的分析完整，应该描述图22。该图表示出
了不同类型的规则的最小显著性——X轴表示最小显著性(定义参见
段落4.3)，Y轴表示具有给定最小显著性的规则的百分比。该图表应
该以以下方式理解：如果存在具有0.3的最小显著性和40％的规则的
点，则意指40％所发现的规则具有以下Math21的关系。如果仅具有最
高显著性的规则可被传送至客户站点(参见1)，则这种信息非常有用。
[Math.21]
显著性∈[0.3，1]
通常，图22证明了本论文中所研究的方法是合理的，因为显著性
缓慢地下降，因此在HYDRAstor系统的统计数据之间确实存在许多相
关性，它们不是偶然的。常数规则的显著性下降最慢，这并不令人意
外——许多统计数据只是偶尔改变其值(例如，在罕见的删除过程中)。
来自LRT_A集合的规则的较差结果(在常数还有其它类型的情况下)
与这样的事实关联：LRT是强化测试，其检查HYDRAstor的不同使用
情景。在该图表中找到的最乐观的结果在于，来自CL集合的同一性与
求和规则的显著性非常相似，此外，它们具有较高的值。这非常幸运，
因为接收自客户的文件中发现的规则将(可能)具有高质量。请注意，
CL集合包含由不同版本的HYDRAstor生成的文件，这对获得这种好
结果没有帮助。不幸的是，在LRT_A集合中发现的同一性与求和规则
的显著性不具有与CL集合中发现的同一性所具有的相同性质，因此从
压缩的角度，它们看起来不是那么有用。
最后，当涉及到StatsMiner的性能时，验证总是比挖掘快——这
是可喜的进步，因为此阶段的介绍基于这样的假设。LRT_A集合的挖
掘时间与验证时间之比高于CL集合，因为验证以规则的完整数据库开
始，而挖掘不是。另一方面，对于CL集合，每窗口的挖掘时间和验证
时间均较小，虽然最终保存的规则的数量远大于LRT_A集合。这可通
过这样的事实来说明：与来自LRT_A集合的文件当中相比，在CL集
合的数据库当中存在更多独特的统计数据(从其名称的意义上讲)(由
于不同版本的HYDRAstor等)。此结论可在验证阶段期间通过每文件
的平均适用相关性数量来证明——适用意指相关性所预期的所有统计
数据均存在于文件中。LRT_A集合的值为8599140，CL的值仅为6774
390(少21％)。
StatsMiner(整体)的性能目前低于预期(当涉及到CPU和内存
使用时均如此)，但是该软件还没有被概况分析(profile)或者甚至充
分调整。主要瓶颈是规则保存的方式——使用组合方法意味着在存储
器中存储数十亿的规则。遗憾的是，内部数据结构证明不够高效。
StatsMiner是作为半原型软件而准备的，因此其问题不应出人意料的。
总之，StatsMiner达到了预期。尽管仅实现了所设计的挖掘算法的
较小子集，规则的数量和显著性证明该工具的构思是正确的。有趣的
是，内存是StatsMiner的瓶颈。目前，为了避免碰到这些限制，应该在
由一个版本的HYDRAstor收集的统计数据上进行分析。此外，分别地
挖掘各个客户的统计数据之间的相关性可能提供最佳结果，但是它自
然需要许多资源，因此是不现实的。也可通过引入更好的存储规则的
方法来降低内存消耗——看起来应该在扩展工具的功能之前，通过使
其能够发现其它新类型的相关性或者引入随机窗口的概念，来解决此
问题。
第5章压缩器
此章包含StatsCompressor的描述和评价，它是利用基于相关性的
方法和领域知识来压缩包含HYDRAstor系统所生成的统计数据的文件
的工具。
此章由以下章节组成。
5.1.“概述”介绍StatsCompressor的一般概念和假设。
5.2.“试验台”描述此章中所使用的测试数据和测试方法。这很
重要，因为将呈现许多实验结果。
5.3.“StatsCompressor的基础结果”介绍在测试数据上使用
StatsCompressor可实现的最佳结果。它们将是基础结果，其它实验结
果将与其进行比较。
5.4.“外部压缩器”简要讨论了可用于StatsCompressor所生成的
文件的进一步压缩的工具，因为该工具自己仅进行基于相关性的压缩。
5.5.-5.9.这些章节包含StatsCompressor所使用的压缩方法的描述
和评估。
5.10.“基于相关性的压缩的其它使用模型”简要介绍StatsMiner
和StatsCompressor的协作方式。其目的是允许使用一个规则集合来压
缩由不同版本的HYDRAstor收集的统计数据。它讨论了可用在第3章
中所涉及的模型中的策略并且介绍了某些新方法。
5.1.概述
所设计和实现的压缩器，称为StatsCompressor，是用于无损地压
缩作为所描述的研究的一部分创建的Zstat文件(参见段落2.3.2)的工
具。它得到常规的Zstat文件作为输入，并且生成Zplus文件作为输出。
Zplus文件与Zstat文件非常相似，这使得它们是可比的。通过该工具
进行的压缩是高级别的-不使用字节级方法-并且基于一些领域知识(主
要关于统计数据之间的相关性)以及压缩文件的几个简单文本变换。
所创建的Zplus文件应该利用一些通用外部压缩器进一步压缩。
该工具以C++编写，并且可在Linux操作系统下运行。使用C++
源自高性能预期，因为压缩器将在正常操作的客户机器(在Linux操作
系统下操作)上运行。实际上，它可在将备份数据写入系统中的过程
中运行，因此其CPU和内存消耗应该被最小化。另一方面，在研究期
间很难准备高度有效的软件，因此代码从一开始就被当作原型，它应
该在产品化阶段被重写(几乎从头开始)。此方法-以C++准备原型-
使得可在最大资源使用的情况下测量最大可实现压缩比。所有呈现的
实验结果应该从这一假设的角度来评估。
5.2.试验台
5.2.1.测试数据
StatsCompressor的所有性能测试在以下数据集合上进行(类似于
StatsMiner的情况)。
1.LRT_A-50从H4版本上的长期运行测试随机选择的Zstat文件。
2.LRT_B-50从H4版本上的长期运行测试随机选择的Zstat文件。
[Math.22]
存在
LRT是长期运行测试的缩写，它持续约2周，模拟HYDRAstor
的正常和极端使用。系统为H4版本，由1个HN和4个SN组成。选
择此数据来源，是因为还没有来自使用H4版本的客户的统计数据，此
外，这些Zstat文件可被当作HYDRAstor的型号版本的快照。从使用
先前版本的HYDRAstor的客户获得的、随机选择的统计数据文件的结
果在第6章中说明。
5.2.2.性能测量
在与StatsMiner的测试(参见段落4.2.2)相同的机器上按照相同
的方式进行StatsCompressor的测试。
5.3.StatsCompressor的基础结果
图23包含StatsCompressor可实现的最佳、平均压缩比(下面定
义)以及StatsCompressor的性能结果。所述结果是通过利用之前针对
整个LRT_A集合生成的规则、压缩来自LRT_A集合的各个Zstat文件
而收集的。StatsCompressor适用于启用的所有算法，因此这里呈现的
结果是可实现的最佳结果。
在本论文中，StatsCompressor的压缩比(ScCR)和支持节省空间
按照以下方式计算。
[Math.23]
S c C R ( C o m p r e s s o r , Z s t a t ) = s i z e o f c o m p r e s s o r ( Z p l u s ) s i z e o f c o m p r e s s o r ( Z s t a t ) · 100 % ]]>
Spacesaving(Compressor,Zstat)＝1-ScCR(Compressor,Zstat)
这里，
sizeofCompressor(Zplus)＝由StatsCompressor压缩，然后由
Compressor压缩的Zstat文件的大小。
sizeofCompressor(Zstat)＝仅由Compressor压缩的Zstat文件的大
小(正常HYDRAstor实践)
StatsCompressor的压缩比提供关于StatsCompressor的压缩质量的
信息。它不仅仅是人为度量，因为它可用于确定当使用所提出的工具
来最终获得与不使用StatsCompressor的情况下相同大小的压缩文件时
Zstat文件可大了多少。实际上，它表示如果StatsCompressor被产品化，
对于从客户下载的统计数据来说收集周期可长了多少。
压缩器“noComp”代表不使用外部压缩器——这表明
StatsCompressor自己执行得如何。“仅主体”部分示出仅包含具有样
本的行的Zstat文件的压缩结果。如段落2.3.2中描述的，各个Zstat文
件行的一半包含现有统计数据的名称和元数据。所设计的解决方案仅
聚集于样本的压缩，因为元数据的有效表示的问题已经解决(参见段
落2.3.2)。“仅主体”部分提供关于StatsCompressor的事实性能的信
息(但是应该牢记，即使StatsCompressor没有明确地压缩元数据，但
是它可按照略微不同的顺序转存它，并且可进行统计数据的标识符的
一些改变(参见段落5.7.1)。
针对-9参数-运行的bzip2压缩器实现StatsCompressor的最佳压缩
比——其平均对于完整Zstat文件为47.78％(节省空间量到52.22％)，
对于仅主体为42.72％(节省空间量到57.28％)。最佳结果对于完整文
件为43.8％(节省空间量到56.2％)，对于仅主体为33.4％(节省空间
到66.6％)。这些结果超过所有预期，因为在项目初始化时，预期节省
空间20％-30％。
然而，当使用bzip2作为外部压缩器时实现StatsCompressor的最
佳压缩比，通过StatsMiner和xz压缩器的组合输出最小文件。
另一方面，CPU和内存使用目前太大，以致难以在客户站点处实
际运行StatsCompressor。改进性能的方式将在此章中稍后讨论。
在不使用外部压缩器时的压缩比(“noComp”行)非常有趣。在
完整文件的情况下，平均压缩比为64.44％(节省空间量到35.56％)——
此结果看起来非常好，特别是StatsCompressor不提供比特级的任何压
缩，Zstat和Zplus文件格式均使用冗长文本表示。此效果对于仅主体
的压缩甚至更强——平均压缩比为30.61％(节省空间量到69.39％)。
对于完整文件的结果，发生平均压缩比的以下现象：
bzip2<gzip<noComp<xz
它可被解释为StatsCompressor以对于gzip或bzip2不可实现的方
式压缩Zstat文件的部分的暗示，因为在利用bzip2或gzip压缩Zplus
文件之后节省空间更高。另一方面，在xz的情况下，怀疑xz可独立地
进行StatsCompressor所进行的一些变换。然而，如图24所指示的，在
Zplus文件上使用xz可能给出最小压缩的Zplus文件，虽然xz与bzip2
之间的差异在统计上不显著。当在仅主体压缩的情况下分析相同的关
系时，不等式具有以下形式：
noComp<bzip2<gzip<<xz
这意味着事实上，StatsCompressor重复所有其它外部压缩器所进
行的一些步骤，但是元数据的压缩(仅存在于完整文件中)使bzip2和
gzip的能力极大地变差。
在压缩完整文件和仅主体的情况下StatsCompressor的压缩比的标
准偏差均非常小。这是非常好的事，因为这意味着所开发的软件的行
为是可预测的。这在完整文件的情况下特别重要，因为如果在客户站
点处使用该解决方案，则可精确地选择输入Zstat文件的大小以具有期
望大小的Zplus文件。
所描述的结果将在以下章节中被引用(作为模型、基础或者“全
LRT_A/LRT_A”)以将它们与在禁用嵌入StatsCompressor中的一些算
法之后收集的结果进行比较——这将表明特定算法有多重要(从
StatsCompressor的压缩比的意义上讲)。
5.4.外部压缩器
决定StatsCompressor将由外部压缩器支持，以将工具的开发仅聚
焦于相关性的使用。数据压缩、算法的混合以及信息理论已被研究了
很多年，如今提供了大量的数据压缩方法。在流行的工具中实现了最
实际的方法。在Linux中，它们是gzip和bzip2，然而，存在各种其它
工具，如[Vei13]和[Jr13]所指示的。决定测试xz压缩器，它是7za工具
的改进版本并且在Linux群体中日渐普及。检查了在HYDRAstor环境
中xz会表现如何——迄今为止，gzip和bzip2已成功使用。
5.4.1.比较
图24呈现了绝对压缩比(示出于下面的Math24中)。行
StatsCompressor中的值仅证明外部压缩器的使用是必要的。图25示出
在压缩来自LRT_A集合的原始Zstat文件时所考虑的外部压缩器的压
缩比和性能——如果不使用StatsCompressor，则这些是正常结果。
[Math.24]
图25表示外部压缩器的性能。首先，xz工具提供最佳压缩比并且
其优势巨大。然而，这是利用极其高的内容消耗来实现的，这会是在
HYDRAstor中使用它的主要障碍，因为内存是宝贵资源。另一方面，
gzip是最差的工具(虽然其使用成本低)。在此实验中，由gzip和bzip2
实现的压缩比之间存在不显著的差异，但是当压缩Zplus文件时这些差
异大许多(与图24相比)。从这一角度看，外部压缩器的最佳选择看
起来是bzip2，因为xz成本过高，而gzip提供的压缩比不令人满意。
注意到有趣的事实是，平均来讲，bzip2-9比bzip2-6差，虽然标志-9
指示bzip2使用它所具有的最佳压缩方法。
5.5.StatsCompressor的图解
图26呈现了StatsCompressor的示图。软件的各个部分将在以下
章节中全面地描述，此图示出了在单个Zstat文件上执行的动作序列。
组件的使用可通过程序变元或者限制规则文件(例如，仅使用同一性
相关性)来控制。
所描述的图包含成本的概念。在此章中，成本是指利用特定方法、
将特定信息保存在还未被外部压缩器压缩的Zplus文件中所需的字节
数。例如，如果样本具有值“12345”并且没有选择压缩方法，则此样
本的成本为5(因为样本将按照人可读形式被转存为“12345”)。这
种计算成本的方法具有一个普遍缺点——它没有考虑到将利用外部通
用压缩器来压缩Zplus文件的事实。不幸的是，在StatsCompressor中
无法确定转存任何信息的最终(外部压缩之后的)成本，因为由外部
压缩器针对特定数据实现的压缩比总是由上下文数据来确定。总之，
StatsCompressor基于这样的假设构建：外部压缩器很少将数据的较大
表示(例如，“1_2_3_4_5”)压缩成比它针对较小表示(“12345”)
所压缩成的更少数量的比特(假设外部压缩器的算法是单调的)。
压缩处理由三个阶段组成。
1.尝试各种压缩统计数据的方法(参见段落5.8和5.9)。
2.选择压缩统计数据的最佳方法(参见段落5.6)。
3.对编码进行优化(参见段落5.7)。
5.6.基于相关性的压缩
StatsCompressor的最重要的部分是其选择将要用于压缩的规则的
算法。得到两种类型的规则——从包含所发现的规则的文件加载的这
些规则(参见段落5.9)以及由StatsCompressor自己发现的那些规则(参
见段落5.8)。所实现的算法是最简单的算法之一，并且由两个步骤组
成：对规则进行评分，然后选择得分的规则中的哪一个将用于压缩。
5.6.1.对规则进行评分
对规则进行评分的最开始的步骤是选择将要应用于各个统计数据
的最佳所谓变换格式(transformat)。变换格式事实上是由
StatsCompressor自己发现的内相关性(参见段落5.8.2)。为了前后一
致，明确地写统计数据的样本-不使用任何方法来压缩它们-将被称为0-
变换格式。仅一个变换格式-有最小成本的这个-可应用于Zplus文件中
的统计数据。
下一步骤是计算各个互相关性的成本并且给予它们得分。所述得
分是用于在所拥有的所有规则当中引入线性顺序的数值。自然，使用
任何互相关性来压缩给定统计数据，只有在此相关性的成本小于最佳
变换格式的成本时才自然合理。如果满足此条件，则规则应该得分。
有两种可能的方法，一会儿将介绍。为了使得描述更清楚，我们假设
存在两个规则r1和r2，各个规则压缩不同的统计数据，并且
10＝cost(r1)，cost(t1)＝15，cost(r1)<cost(t1)
12＝cost(r2)，cost(t2)＝30，cost(r2)<cost(t2)
其中，t1和t2是应用于与对应r1和r2相同的统计数据的变换格式。
对规则进行评分的绝对成本方法
规则的得分为
score(ri)＝cost(ri)
在上面定义的示例的情况下，将为score(r1)＝10和score(r2)＝12。
这些得分引入以下顺序：
[Math.25]
r1＞r2
对规则进行评分的相对成本方法
规则的得分如Math26中所示。
[Math.26]
s c o r e ( r i ) = cos t ( r i ) cos t ( t i ) ]]>
其中，ti是ri尝试压缩的相同统计数据的变换格式。在上面定义的
示例的情况下，将为score(r1)＝0.625和score(r2)＝0.4。这些得分引入以
下顺序：
[Math.27]
r1＞r2
如实验所证明的，相对成本方法执行得略微更好，根据所使用的
外部压缩器提供高0.3％-0.6％点的StatsCompressor的平均压缩比。
对规则进行评分平均花费593秒(在模型LRT_A/LRT_A实验中)。
处理的长度是由于大量应该被评分的规则导致的——每Zstat平均检查
27095900个规则(参见图33)。需要注意的是，相关性f＝g+h以三种
形式出现(作为三个不同的有向规则)：f＝g+h、g＝h-f和h＝g-f。在所
有检查的有向规则当中，4523420(每Zstat平均)具有比对应变换格
式的成本低的成本(因此许多规则充分得分)。这意味着可应用的规
则(因为所有预期的统计数据出现在Zstat文件中)中的仅约17％可用
于压缩。更多结果可见于图33中，其在段落5.9.2中讨论。使
StatsCompressor的资源使用最小化的方式将在段落5.9.4和段落5.10
中进一步研究。
5.6.2.选择将要使用的得分规则
乍一看，此步骤看起来非常简单——如果存在一组得分的规则，
则对于各个统计数据，应该取得分最低的规则。如果没有规则应用于
特定统计数据，则应该使用变换格式-至少0-变换格式。然而，此方法
中存在陷阱：如果选择f＝g、g＝h和h＝f的话怎么办？在这种情况下，
所有统计数据的样本的值将消失(由于f＝g等，f的样本不保存)——
仅关于相关性的信息保留。
StatsCompressor使用以上介绍的方法的更微妙的版本。它从具有
最小得分的规则开始检查所有规则(因为存在得分的线性顺序，所以
这是可能的)。将要使用的规则必须满足以下标准。
1.有向规则的先导(可使用此特定规则压缩的统计数据)还未通
过另一规则(具有较小得分)来压缩。
2.规则的使用将不会向所应用的规则的有向图形中引入环。图形
的顶点是统计数据，边缘表示统计数据之间的依赖性，例如，如果使
用规则f＝g，则图形中将存在以Math28表示的边缘。因此，求和规则
p＝q+r的使用引入以Math29和Math30表示的边缘。该图形被保存在
存储器中，并利用深度优选搜索算法来检测环的存在。
[Math.28]
f←g
[Math.29]
p←q
[Math.30]
p←r
所描述的算法是贪心算法。如实验所证明的，它提供可接受水平
的压缩，但是构造其表现不佳的示例非常容易。未来的一些进一步工
作应该花在发现用于此目的的更好的算法(或者给现有的算法增加一
些启发法)上。据怀疑，该问题可能是NP完全的，虽然没有构建出证
据，因为以图论语言表示这些问题足够困难。一个考验是：存在加权
多重图G。从G移除一些边缘(根据给定概率列表)，因此Gt将是非
环的，没有多个边缘，被连接，并且边缘的权重之和最小。需要注意
的是，一些边缘无法被分别地移除(因为求和相关性应该整体使用，
意味着存在至少2个边缘)。图形G将具有一个人为顶点，因此从它
到所有其它顶点的边缘将具有这样的权重，该权重等于目标顶点(自
然表示统计数据)的变换格式的成本。
所实现的贪心算法的执行平均每Zstat文件花费18秒，因此这一
步骤比规则的评价快许多。
5.7.所选择的相关性的后处理
5.7.1.重新编号
重新编号是在Zplus文件内部交换由统计数据所使用的标识符以
改进压缩比的处理。根据图26，它是压缩的最后阶段，虽然它将在触
及展平抽象类的问题之前描述，因为展平被引入以改进重新编号。
Zstat文件(以及还有Zplus)中的各个统计数据具有其独特标识
符——自然数。在Zstat文件中，各个标识符被准确地使用两次(以将
统计数据的名称映射至其样本)。在Zplus文件中，在保存相关性时使
用标识符，因此它们中的一些将更频繁地出现。重新编号的目的是给
予频繁出现的统计数据更短的标识符(因此，具有更低的成本)。在
LRT_A的情况下，最常见的统计数据标识符被转存(平均)25678次。
没有测量重新编号的时间，但是它对性能的影响可忽略，因为此步骤
的复杂度为O(nlog(n))，其中n是统计数据的数量。
图27示出在禁止重新编号的情况下、利用在LRT_A上挖掘的规
则来压缩LRT_A集合的结果。据此，重新编号是非常重要的步骤，因
为缺少它导致StatsCompressor的压缩比的显著下降(至少11％点)。一
如既往，xz受此问题的影响最小。在仅主体压缩的情况下，由于不存
在具有统计数据名称的行，该问题被掩盖。令人惊讶的是，当重新编
号被禁止时平均CPU利用率略大——这很难解释。
事实上，此步骤是在解压缩过程中不可逆的两个步骤之一，因为
Zplus文件不包含旧标识符向新标识符的映射的字典(不需要它)。另
一方面，为了使得Zstat与Zplus可比，从已经用在Zstat文件中的旧标
识符当中选择新标识符。有趣的是，所有Zstat文件中的最小标识符至
多为568。在StatsCompressor的产品版本中，新标识符应该从1开始。
5.7.2.抽象类的展平
抽象类的展平的目的的描述需要引入新的概念。使f、g、...表示
不同的统计数据。id(f)＝x将表示，在Zplus文件中统计数据f将得到标
识符x。
选择得分的规则的算法(参见段落5.6.2)的工作方式暗示了，例
如抽象类A＝f0,f1,f2,f3的压缩，可选择以下规则：f1＝f0，f2＝f1，f3＝f2。
然而，这不是最佳的，因为应该使用至少三个不同的标识符——x、y、
z并且x＝id(f0)、y＝id(f1)、z＝id(f2)＝id(f3)。最佳方法是如下对整个抽象
类进行编码：f1＝f0，f2＝f0，f3＝f0，因为将仅使用一个标识符t＝id(f0)。
将存在t＝id(f0)＝id(f1)＝id(f2)＝id(f3)。请注意，在这种情况下，无法得到
统计数据f1、f2和f3的原始标识符。然而，这不是必要的。
抽象类的表示的优化处理被称为展平，因为其目的是降低用于对
抽象类进行编码的规则树的高度。最佳树高度为1，因此各个抽象类只
有一个代表。使用并查集(Find-Union)算法来进行它。在开始，各个
统计数据形成单元集。如果统计数据之间存在严格同一性，则适当的
集合(表示此统计数据的抽象类)被合并。最后，每个集合仅有一个
代表被使用(在来自先前段落的示例中，f0)。实际上，使用Boost不
相交集库。复杂度为O(以下Math31)，其中以下Math32是逆阿克曼
函数，n是统计数据的数量，m＝O(1)并且取决于待分析的规则集合。
在利用全LRT_A/LRT_A的实验中，此步骤平均花费0.7秒。
[Math.31]
mα(n，m·n)
[Math.32]
α
图28示出在禁止抽象类的展平的情况下利用LRT_A上发现的规
则来压缩LRT_A集合的结果。节省空间非常少——平均为2-3％点。
有趣的是对于xz压缩器而言允许展平非常重要。抽象类的展平使用约
14MB的RAM，因为必须构建用于并查集算法的数据结构。
5.8.基于内部知识的算法
StatsCompressor自己搜素一些类型的相关性——它执行足够快速
的对性能没有负面影响(这对此软件很关键)的挖掘。
5.8.1.压缩常数
所有Zstat文件中的约24％的统计数据为常数。这种类型的(内)
相关性没有被放入规则文件中，因此StatsCompressor应该自己寻找它
们。该处理类似于段落4.8.1中描述的处理。
当所有常数统计数据均被识别时，它们被分组为抽象类(基于它
们的值)——例如，存在类f＝g＝h。每个类具有一个代表，它是具有最
少样本的统计数据(例如，f)。对于抽象类的各个成员，创建同一性
规则(与从规则文件加载的同一性的情况下相同)，其描述统计数据
与抽象类的代表之间的关系(在示例中，为f＝g和f＝h)。请注意，非
代表统计数据之间不存在规则(不存在规则g＝h)。此方法用于使在此
步骤中创建的规则的数量最小化(抽象类会非常大，因此使用存储规
则的真实组合方法将导致生成上千的规则，但是仅它们中的一小百分
比将被使用)。
常数的发现平均仅花费0.61秒，但是它对StatsCompressor的压缩
比有显著影响——图29呈现了使用仅打开了常数的压缩(不使用其它
压缩方法，但是后处理激活)的StatsCompressor的实验结果。根据
所使用的外部压缩器，节省空间在压缩完整文件的情况下从9.61％变化
为12.69％，在压缩仅主体的情况下从6.48％变化为8.67％。看起来由
于使用统计数据的重新编号作为后处理，对于完整文件节省空间较大，
因此从Zplus文件的第一部分的名称至标识符映射包含较少熵——不
同标识符的数量较小。
5.8.2.变换格式
如已经提及的，利用内相关性压缩统计数据的样本的方法被称为
变换格式。此类相关性目前由StatsCompressor自己发现。各个统计数
据可利用不超过一个变换格式来压缩——这在没有其它压缩手段可用
时进行-更多细节参见段落5.6.1。StatsCompressor总是针对各个统计数
据计算所有变换格式，以确定最佳变换格式。这些计算经证明极其快
速。
在描述变换格式时将使用以下记号：
s-统计数据的样本序列
si–序列s的第i样本
Ti(s)-将变换格式t应用于序列s的第i样本的结果
0-变换格式
仅为了清晰而引入0-变换格式，以使得以下陈述总成立：“如果
统计数据的样本应该被(明确地)转存在Zplus文件中，则使用变换格
式。”0-变换格式不以任何方式变换样本——其值仅仅按照与其存在于
Zstat文件中的相同方式被“原样”保存。
Ti(s)＝si
差分变换格式
差分变换格式基于这样的假设：统计数据的值逐渐改变，因此保
存当前样本与前一样本之差可比明确地保存两个样本的值成本更
低——所述差常常是较小的数，具有较低成本。此外，相同的值可频
繁地作为差而出现，因此它们将被外部压缩器有效地压缩。为了能够
计算差，假设统计数据的第一样本之前的样本的值为0。在
StatsCompressor中针对有限差分上的所有计算运用此方法，从而允许
例如，当已经知道统计数据g的样本时，利用规则df＝g压缩的统计数
据f的解压缩。
T0(s)＝s0-0＝s0
Ti(s)＝si-si-1i>0
优势变换格式
发明优势变换格式是因为观察到一些统计数据很少改变它们的
值，因此保存这些统计数据的优势值以及偏差向量就足够了。由于使
用稀疏偏差向量(参见附录A)的编码，后者可有效地进行。优势变
换格式的计算需要读取统计数据的样本两次——在第一次，寻找优势
(最常见的值)，在第二次，确定偏差。然而，如性能结果所证明的，
扫描序列两次对StatsCompressor的性能没有可见的影响。
c–序列的优势——样本序列s中的最常见的值
Ti(s)＝si-1-c
变换格式的评价
图30包含利用变换格式作为仅有压缩方法来压缩LRT_A集合的
StatsCompressor的压缩比。节省空间令人印象深刻：在完整文件的情
况下18.06％-30.89(取决于所使用的外部压缩器)，对于仅主体
21.91％-36.28％。本论文中所提出的优势变换格式和差分变换格式是非
常简单的方法，令人惊讶的是没有外部压缩器以这样有效的方式使用
相同机制。自然，上述工具被调整以用于字节文件，而非文本文件，
但是看起来应该以某种方式改进它们，因为潜在的节省空间巨大，并
且如今包含纯文本的文件变得越来越流行(例如，JSON格式)。
差分变换格式比优势变换格式更常使用，这已经预测到——参见
图31。然而，令人惊讶的是优势变换格式常常是最佳的变换格式，虽
然理论上它可在与差分变换格式非常相似的条件下使用——它们运行
得越好，偏差数量越少。另一有趣事实是，0-变换格式几乎从不使用——
这意味着仅仅存在几个具有巨大波动的统计数据。
差分变换格式和优势变换格式均以相同的方式构建——存在用于
预测样本的值的函数，并且必须保存真实值与预测值之间的偏差。自
然，许多其它族的函数也可用于预测——确定应该使用哪一族函数(多
项式、指数函数等)可由StatsMiner来检查，而StatsCompressor可利
用一些数值方法计算这些函数的系数。事实上，将函数拟合到真实样
本值的整个构思并不是新的——它已经用于声音压缩，例如在自由无
损音频编解码(FLAC)[CF13]中。
5.9.外部知识的使用
规则文件是外部知识的来源——StatsMiner所寻找的相关性。此章
节包含这些规则的使用的分析——它如何影响StatsCompressor的性能
以及未来必须解决哪些问题。
5.9.1.偏差向量
StatsCompressor的最重要的特征之一是其使用相关性的能力，即
使它们没有数值拟合，因此在样本的真实值与使用相关性所预测的值
之间存在一些偏差。这意味着StatsCompressor可使用弱相关性，虽然
StatsMiner仅发现严格相关性(特别是在所实现的版本中)。对此偏差
进行编码的方式在附录A中描述。图32呈现了当禁止使用偏差向量，
因此仅允许严格相关性时StatsCompressor的压缩比。事实上，这还意
味着变换格式被关闭(自然，除了0-变换格式以外)，因为它们需要
偏差向量来正确地运行。可以看出，偏差向量的使用对于
StatsCompressor实现良好的压缩比而言很关键，特别是当使用外部压
缩器时。另一方面，此结果也证明了基于相关性的压缩的构思(如本
论文中所描述的)是合理的，因为即使使用最佳外部压缩器(xz-9)，
节省空间也非零——对于完整文件，节省空间为14.9％，对于主体为
12.68％。事实上，第二个结果更重要，因为它应用于最受
StatsCompressor关注的仅包含样本序列的Zstat文件的部分。
使用偏差向量不太影响CPU消耗。相反，内存的使用看起来受到
影响，但是这依赖于实现方式，可以减小——在当前版本的
StatsCompressor中，在对规则进行评分时计算的偏差向量被保存在存
储器中，不管它们是否还能再使用。
5.9.2.外部知识规则的使用性能
StatsMiner可容易地生成数百万的规则(参见段落4.9)，因此关
注的是StatsCompressor能够多好地使用这种知识。图33呈现了在利用
在LRT_A集合上发现的规则压缩LRT_A集合时从规则文件加载的规
则的使用率的统计数据。
请注意，针对同一性的结果包括在StatsCompressor内部生成的、
用于常数的压缩的规则。这是因为StatsCompressor没有针对常数统计
数据创建同一性规则，即使它可以这样做。据此，不包括这种类型的
规则可导致创建StatsCompressor的假象，因为一些统计数据(为压缩
的文件中的常数)可能由于缺少上述同一性规则而被极为无效地压缩。
例如，如果建立以下Math33、34，则代替对f＝g进行编码，可能使用
规则f＝g+dg。在StatsCompressor中创建的用于对常数进行编码的规则
的数量相对较少，此类规则不超过统计数据的数量——因此它们将不
会太过干扰外部知识规则的评价，然而缺少它们将使得这些结果完全
不真实。
[Math.33]
f≡2
[Math.34]
g≡2
图33的描述
在评论结果之前，应该描述图33中所使用的类别：
所有统计数据-所分析的Zstat文件中的统计数据的平均数量
非常数统计数据-所分析的Zstat文件中非常数的统计数据的平
均数量
加载的规则-每Zstat文件的从规则文件加载的规则的平均数量，
它们可用于压缩。如果Zstat文件包含一规则所使用的所有统计数据，
则此规则可用于压缩。
尝试应用-得分的规则的数量(参见段落5.6.1)。存在尝试应
用>加载的规则，因为包括生成的用于常数压缩的同一性规则，但是首
先，由于改变它们的先导而从现有的规则创建新的规则(例如，如果
存在规则f＝g+h，则创建以下规则：f＝g+h，g＝h-f和h＝g-f)。此类规
则被称为有向规则。各个有向规则可正好压缩相应一个统计数据(是
其先导)。
具有好成本-每Zstat的如下有向规则的平均数量，其可实际压
缩统计数据，因此使用上述规则对统计数据进行编码的成本小于使用
最佳变换格式(参见段落5.6.1)压缩统计数据的成本。
不被应用，循环-每Zstat的如下有向规则的平均数量，其使用
将在统计数据的图形中引入环，因此将无法恢复统计数据的样本的真
实值(将仅知道统计数据之间的关系)。参见段落5.6.2。
不被应用，描述lhs-每Zstat文件的如下有向规则的平均数量，
其由于先前选择另一规则来压缩统计数据而没有使用。参见段落5.6.2。
被应用-每Zstat的用于压缩的有向规则的平均数量。同一性规
则列中的圆括号中的数字指示实际从规则文件加载(不是为了常数的
压缩而由StatsCompressor自己生成)的同一性规则的平均应用次数。
评价时间-每Zstat文件对有向规则进行评分的平均时间(以秒
计)(参见段落5.6.1)。
选择规则-每Zstat文件选择将用于压缩的有向规则的平均时间
(以秒计)(参见段落5.6.2)。
请注意，有向规则之间保持以下关系。
[Math.35]
“尝试应用”≥“具有好成本”
“具有好成本”＝“被应用”+“不被应用”
基于外部知识的规则的使用的性能分析
首先，非常令人鼓舞的是如此多规则，如此多规则已经从规则文
件加载并且可应用于(平均)Zstat文件。然而，有向求和规则的数量
变得极其庞大，它看起来是StatsCompressor的主要性能问题，因为求
和的评价时间比针对同一性规则的相同操作的时间长80倍。令人惊讶
的是，选择将要用于压缩的规则远快于求和规则的评价，尽管此步骤
看起来比评价更复杂。据信可改进评价阶段的代码——通过使用更好
的CPU高速缓存、SIMD指令运用等。
具有好成本(因此值得应用)的规则的数量也是令人印象深刻的，
证明了基于相关性的压缩具有很大潜能。自然，仅有44％的同一性规
则和16％的求和规则，因此看起来可减小规则文件的大小而不会过多
降低压缩比。此问题将在段落5.9.4中讨论。(有向)规则无法应用的
主要原因是这样的事实，即目标统计数据已经被另一规则压缩。这种
情形具有一些重要的含义。首先，改进选择规则的算法(参见段落5.6.2)
可增加压缩比。另一方面，它还可表示，统计数据当中存在大的抽象
类，因为常常有许多方式来压缩相同的统计数据(它与许多其它统计
数据相关)。由于出现环而引起的相对少量的规则应用失败可被解释
为关于少量抽象类的信息，但是实际上，只有规则的先导还未被压缩
才针对此条件检查该规则，因此难以解释此值。然而，不管此结果的
值有多大，意味着没有此检查的话，将存在无法被正确解压缩的许多
统计数据。
乍一看，被应用的规则(即，实际用于压缩的规则)的数量巨大——
包含平均48940个统计数据的每一Zstat文件平均42010个(因此，
86％的统计数据可利用相关性来压缩)。另一方面，平均41008个规
则压缩常数统计数据并且由StatsCompressor自己生成。然而，这是相
当好的消息，因为这证明了在StatsMiner中放弃常数(参见段落4.8.1
和段落5.8.1)是好的决策——否则的话，规则文件将巨大，且
StatsCompressor将比现在慢许多。因此，从文件加载的规则的应用次
数(总共6598)应该与非常数的统计数据的数量(14528)进行比较，
因此45％的统计数据利用这些相关性来压缩。当然，此结果可在通过
搜索更多类型的相关性(参见段落4.7)或者通过实现所提出的理论上
更好的窗口生成算法(参见段落4.3.1)来扩展StatsMiner之后得以改
善。那么被应用的规则的数量应该增加，但是很难预测增加多少，因
为目前，求和被应用于7％的统计数据。这种类型的求和(仅由3个统
计数据组成)不是非常复杂，据信存在更多统计数据的求和。另一方
面，相关性的公式越复杂，这种规则的应用成本越高，因为规则也应
该被存储在Zplus文件中。
总结
外部知识规则(从文件加载的这些规则)对于StatsCompressor而
言很重要——它们常常用于压缩。在StatsMiner中发现更多类型的相关
性(或者仅仅改进现有算法)将确实改进StatsCompressor所实现的压
缩比，因为存在现在还未压缩的一组统计数据。然而，StatsCompressor
目前具有性能问题，因为有太多规则将要评估(特别是求和规则)，
看起来可更有效地使用它们。使用较少量的求和规则的可能性将在段
落5.9.4中讨论，一些新的系统方法将在段落5.10中介绍。
StatsCompressor的有问题(从性能的角度)的内部算法在段落5.6中有
所描述。
5.9.3.同一性和求和规则的重要性
在前一章节中建议减少所使用的求和规则的数量以改进
StatsCompressor的性能。图34呈现了StatsCompressor仅利用在LRT_A
集合上发现的同一性规则来压缩LRT_A集合的压缩比。括号中的值示
出所实现的值与当使用所有规则时(在全LRT_A/LRT_A实验中，参
见图23)所发现的那些值之间的差异，因此它们告知用于压缩的求和
规则的重要性。
图34中所呈现的StatsCompressor的压缩比告知了，求和规则对
工具所实现的压缩比的影响非常小(对于完整文件约1.8％，对于仅主
体2.37％)，但是不使用它们极大地改进了性能(CPU和内存使用此
刻变得可接受，尽管这仅仅是原型版本的压缩器！)。此外，由于性
能结果的标准偏差显著下降，所以更容易预测StatsCompressor的要求。
有趣的是，在仅压缩主体的情况下，除了别的以外，求和的使用对xz
压缩器最重要。然而，这并不令人意外，因为这种类型的相关性无法
被任何外部压缩器自己发现——它们将最好不要假设一些数据可求
和。如果将不会使用求和，则StatsCompressor使用一些其它方法来压
缩受影响的统计数据，xz看起来能够自己做一些此类工作。
由于不使用求和，StatsCompressor代之以应用同一性规则。平均
来讲，它比平常多应用410个此类规则。这可被当作求和规则有多重
要的证据，因为它们(平均1002)并非全部都可被替代。另外，求和
规则仅应用于2％的统计数据，但是它们使StatsCompressor的压缩比也
提高了约2％——这是令人印象深刻的结果，其也暗示了所设计的软件
应该尝试使用其它相关性。自然，与求和规则的使用关联的性能下降
目前是不可接受的，应该被改进。
5.9.4.求和规则的数量的随机减少
在仍使用求和规则的同时降低StatsMiner的时间和内存消耗的最
简单的构思是随机地删除特定量的此类规则。图35呈现了使用所有规
则与使用所有同一性和随机选择的数量的求和规则之间的、平均
StatsCompressor压缩比和性能结果之间的差异。
图35中所收集的结果暗示了，通过仅使用原始找到的求和规则的
较小百分比，可显著地改进StatsCompressor的性能，而StatsCompressor
的压缩比仅有微小的损失。看起来留下20％的求和规则是很好的权
衡——代价是损失了约45％的节省空间，这是由求和规则的使用造成
的，可减少CPU和内存消耗，因此它仅比根本不使用求和规则时高6％。
StatsCompressor的这种奇特行为，即被删除的规则的数量不与CPU和
内存消耗成线性关系，看起来是使用存储规则的组合形式的结果，因
为规则文件包含在各个求和规则中涉及的所有统计数据的抽象类的产
物。另一方面，这样好的结果可以是所实现的选择将要用于压缩的规
则的算法-尽管简单-非常有效的证明。
5.9.5.总结
图36示出了使用基于外部知识的规则的重要性。它包含
StatsCompressor在不从文件加载任何规则的情况下压缩LRT_A的压缩
比。括号中的数字是相似实验、但是允许加载在LRT_A中发现的所有
规则的结果之间的差异(“全LRT_A/LRT_A”)。从其它角度来看，
此表可被当作所描述的解决方案的不同使用模型的讨论的一部分(参
见5.10)——它回答了问题“如果根本没有StatsMiner怎么办？”
图36的结果指示，从文件加载的(即，由StatsMiner发现的)规
则的使用改进了StatsCompressor压缩比，对于完整文件平均
6.76％-12.22％点，取决于所使用的外部压缩器；在仅主体情况下8.65％
-14.33％点。有趣的是，所加载的文件的使用对bzip2压缩器比对gzip
重要得多，然而由xz生成的文件仍较小。
在此方法中，工具具有优异的性能，其可通过StatsCompressor的
谨慎实现来进一步改进。特别是，内存消耗可显著下降，因为许多数
据现在被保存在存储器中，尽管它可容易地按需计算。
总之，使用基于外部知识的规则增加了StatsCompressor的压缩比，
尽管节省空间不像工具的其它内置算法的情况下那么大。然而，可做
许多工作来改进StatsMiner，因此结果可好很多——据信10％点是可行
的。另外，已知的是StatsCompressor代码的一些地方需要优化，因此
性能还可增加。最后，目前的结果在此研究阶段看起来是令人满意的。
5.10.基于相关性的压缩的其它使用模型
第3章介绍了所设计的解决方案的最一般的分布式使用模型。有
两个地方应该采用策略——选择发送给客户的规则的方法以及所使用
的外部压缩器。外部压缩器已经在5.4中进行了讨论。章节5.10.2、5.10.3
和5.9.4讨论了用于准备规则文件的三种方法。然后章节5.17涉及完全
不同的方法——将StatsMiner与StatsCompressor合并，因此在客户站
点处就在压缩之前完成规则的发现。请注意，已经在段落5.9.5中讨论
了又一方法——根本不使用StatsCompressor的构思。
此章节仅简要介绍基于相关性的压缩的不同使用模型。
5.10.1.压缩的现实分布式模型
迄今为止，所有结果涉及使用(或者有时不使用)在LRT_A集合
上发现的规则来压缩LRT_A集合。此假设不太现实，因为真实Zstat
文件将利用并非在相同数据上发现的规则来压缩(尽管将在段落5.17
中讨论这种方法)，因此已经分析的结果可被视为“最佳目前可实现
的”。
图37包含StatsCompressor利用在LRT_A集合上发现的规则来压
缩LRT_B集合的压缩比。它模拟了所设计的解决方案的现实、但是也
是最乐观的使用情况——利用在训练集合(LRT_A集合)上发现的规
则来压缩客户站点处的数据(LRT_B集合)，这二者均由完全相同版
本的HYDRAstor生成。
图37中所呈现的结果非常好，因为在此现实模型中实现的
StatsCompressor的压缩比非常类似于在乐观模型中所分析的那些——
它们仅差了0.5％点。自然，标准偏差增加，但是这并不令人惊讶，因
为输入数据熵增加(不是相同的文件被挖掘然后被压缩)。看起来接
受偏差对得到此类好结果很关键。性能表现如预期——CPU使用增加
(因为存在更多偏差待分析)，但是内存消耗降低，因为在来自LRT_B
集合的Zstat文件中，出现在LRT_A集合中的一些统计数据可能不存
在。
这些结果对于所有先前实验的评估而言很关键，因为它是已经介
绍的乐观结果也可用于讨论StatsMiner和StatsCompressor的现实使用
模型的性能的证据。
5.10.2.显著规则的使用
StatsMiner首先搜索规则，然后它检查每个规则可应用于数据多少
次以及统计数据之间的给定关系多频率为真。此检查的结果被称为规
则的显著性(参见段落4.3)——此值指示相关性有多好，因此它多频
繁为真。由于由StatsMiner生成的规则的数量巨大，所以它们并非全部
可被发送给客户。此外，如已经提及的，利用太多规则对StatsMiner
的性能有负面影响。因此，看起来合理的是，仅将最佳规则-具有最高
显著性因子-传送给客户的机器。图38呈现了所使用的规则的显著性与
StatsCompressor的压缩比(与最佳可实现结果相比)的相关性以及工
具的性能。
根据图38的结果，使用给定显著性的规则对StatsMiner的性能有
很强影响，因为CPU和内存消耗二者均显著下降。不幸的是，
StatsCompressor的压缩比也下降，但是资源消耗的减少远快于压缩比
的减小。所述压缩比的值应该与图36的那些值进行比较，其包含关于
StatsMiner所发现的规则的使用的一般影响的信息。看起来对于限制规
则文件的大小的策略而言，使用具有80％及更高的显著性的规则是好
的选择。
需要注意的是，这样创建的规则文件可用于由不同版本的
HYDRAstor收集的统计数据的有效压缩，因为选择了最佳规则。
5.10.3.已经使用的规则的使用
StatsMiner生成数百万的规则，然而StatsCompressor实际上每单
个Zstat文件使用约63％的规则来压缩。根据规则显著性来限制规则文
件(在段落5.10.2中描述)基于来自StatsMiner的知识。图39呈现了
相似方法，但是基于StatsCompressor的使用经验——在支持站点处
StatsMiner在训练集合(LRT_A)中发现规则，然后在相同的集合上运
行StatsCompressor以确定实际使用所找到的规则中的哪些。只有这些
规则才将被传送给客户。此方法的质量通过压缩LRT_B集合来测量。
图39呈现了StatsCompressor仅利用之前也用于压缩LRT_A集合
的这些规则来压缩LRT_B集合的压缩比。括号中的值指示与最佳可实
现结果-来自LRT_A/LRT_A全实验的那些-相比，压缩比的损失，它们
可被评估为非常好，因为压缩比下降了约1％点，虽然性能显著提高。
其示出StatsCompressor使用类似的规则集合来压缩不同的Zstat文件，
自然，如果HYDRAstor版本相似的话。然而，标准偏差增加高达50％，
因此在使用此方法时更难预测Zplus文件的大小，但是它仍仅为
3％-4％。所描述的限制规则文件的大小的方法看起来非常有前途和实
际。
请注意这样好的结果可实现是因为允许偏差向量的存在——规则
被当作其描述了弱相关性。选择将要使用的规则的这一方法，据信在
StatsCompressor将压缩由相同版本的HYDRAstor(其也在支持站点处
生成用于实验的文件)生成的Zstat文件的情况下效果最好。另一方面，
StatsCompressor在使用此方法选择规则时比在使用具有最高显著性的
规则时(参见段落5.10.2)表现得好很多。
5.10.4.将StatsMiner与StatsCompressor合并
图16所示的StatsMiner与StatsCompressor的协作模型尽可能地一
般，它假设了StatsMiner需要大量CPU时间和内存。然而，算法已经
从StatsMiner移至StatsCompressor(常数的发现——参见段落5.8.1)，
这导致StatsCompressors的压缩比的增加，同时不会使其性能降低很
多。图40呈现了更为激进的方法——分别对于各个Zstat文件，
StatsMiner和StatsCompressor二者均在客户站点上运行。它模拟了(在
一定程度上)两个工具被合并的情形。
图40示出了将挖掘阶段和压缩阶段结合起来，使得每个文件在客
户站点上分别经历此过程的结果。在解释这些结果时，应该牢记，
StatsMiner和StatsCompressor没有被设计为在此模型中运行，因此性
能结果尽可能差。另一方面，在此方法中StatsCompressor的压缩比是
最佳可实现的压缩比，因为StatsMiner首先发现所有规则，并且
StatsMiner选择最适合的规则。如果工具被合并，则压缩和挖掘可交织，
因此将不在已经利用同一性规则完美压缩的统计数据当中、对求和规
则进行挖掘。然而，即使性能结果不像它们可以的那样好，但是在客
户站点处CPU和内存的使用下降了一半——这是将由StatsCompressor
使用的规则的数量应该以某种方式限制的又一证据。与最佳可实现压
缩比(来自LRT_A/LRT_A全实验)相比，StatsCompressor的压缩比
在此模型中下降了约1.5-2.5％点。有趣的是，这些结果比使用据证明已
经用于压缩的规则时(参见段落5.10.3)所实现的结果略差一些。这一
观察表明了使用弱规则的可能性对StatsCompressor有多重要，因为目
前，StatsMiner仅发现严格规则。结论是，在StatsMiner中实现随机窗
口(参见段落4.3.1)应该具有高优先级。当涉及标准偏差时，它仍非
常低，与LRT_A/LRT_A全实验相比没有多少改变——这是好现象，
因为它使得能够预测Zplus文件的大小。
5.10.5总结
在此章节中描述并评估了选择将要发送至客户站点(参见3.1)的
规则的众多策略。
1.使用最显著的规则(段落5.10.2)。
2.使用已经由StatsCompressor使用的规则(段落5.10.3)。
3.随机选择求和规则(段落5.9.4)。
所提及的策略可被混合在一起，以使规则文件具有期望的特性(对
于略微不同版本的HYDRAstor(1)表现不错，对于特定版本的
HYDRAstor(2)或者具有最小的HYDRAstor(3)表现最好)。
另一方面，研究了StatsMiner和StatsCompressor的完全不同的协
作模型。
1.基于相关性的压缩的分布式模型(段落5.10.1)。
2.根本不使用StatsMiner(段落5.9.5)。
3.将StatsMiner与StatsCompressor合并(段落5.17)。
每个模型迫使可实现压缩比与性能之间的不同权衡。选择最佳的
一个非常难，因为这取决于对所设计的解决方案的限制。此外，准备
的软件是实验性的，因此其性能没有很好地调整。
最后，已证明，LRT_A/LRT_A全实验的结果可用作与其它实验结
果进行比较的基础，因为真实使用情况的StatsCompressor压缩比和性
能与理想的那些(参见段落5.10.1)区别不大。
5.11.总结
StatsCompressor是用于压缩包含统计数据的文件的强大工具。它
利用从特定文件加载的(段落5.9)或者自己发现的(段落5.8)相关
性来压缩数据。该工具平均将Zstat文件的大小减小了一半(最好结果
是66.6％)。不幸的是，该处理的性能不是非常好——CPU和内存的
消耗非常高。自然，这可通过更谨慎的实现和优化、选择更有效的内
部算法(已经在段落5.9.5中总结)或者通过朝着StatsCompressor的使
用改变整个方法(段落5.10)来改进。
不管所实现的软件的特定特性，已证明使用相关性进行压缩是好
的构思，因为最流行的压缩器(gzip、bzip2、xz)自己没有利用这样的
可能性。可通过扩展StatsMiner(以及适当地，StatsCompressor)的功
能来增加节省空间。
第6章在从客户获得的真实统计数据上的评价
不仅在长期运行测试(LRT)期间所收集的人为统计数据上，而
且在从真实客户接收的统计数据(客户日志)上，测试基于相关性的
压缩。如已经提及的，当由于系统表现不像预期而需要检查系统性能
或者调查潜在漏洞时，偶尔地下载这些统计数据。因此，这些统计数
据常常是特定的。所设计的解决方案的确将主要在这种类型的情形下
使用，但是它也可能在任何条件下使用。出于这些原因，决定对长期
运行测试的结果进行详细实验，对客户日志仅进行最重要的实验。此
方法的另一原因是，即使来自客户的统计数据的量非常大，但是并非
所有文件均具有适当的尺寸(存在许多过小的文件)。最后，从客户
获得的可用统计数据由不同版本的HYDRAstor系统生成。对这样不一
致的数据进行的实验，据信比存在对由一个特定版本的系统创建的统
计数据进行实验的可能性时略差一些。
6.1.试验台
6.1.1.测试数据
所有测试在称为CL_2的测试数据集合上进行。在第4章中，分
析了CL集合，其中建立以下Math36。CL_2集合包含从接收自
HYDRAstor的真实用户(客户)的文件当中随机选择的50个XML文
件(CL仅具有30个)。这些文件由安装了各种补丁和更新的各种版
本的HYDRAstor系统来生成。仅同意大小为2MB至4MB并且由SN
生成的文件进行此测试。所选择的文件被转换成Zstat格式。它们包含
约50.000个统计数据，每个统计数据具有140-240个样本(但是一个
文件中的所有统计数据具有约相同数量的样本)。
[Math.36]
C L ⋐ C L _ 2 ]]>
6.1.2.测量性能
在与StatsMiner的测试(参见段落4.2.2)相同的机器上以相同的
方式进行测试。
6.2.实验结果
图41和图42呈现了在不同的模型中在CL_2集合上运行所设计
的解决方案的结果。第一个表(图41)示出平均StatsCompressor压缩
比，第二个表(图42)表示结果的标准偏差。在括号中，示出CL_2
集合上的实验中的值与LRT_A集合上的对应实验之间的差异。列的名
称表示段落5.10中所提及的模型。
乐观–利用在整个CL集合上挖掘的规则来压缩CL_2集合。需
要注意的是建立以下Math37以及|CL|＝30、|CL_2|＝50。在CL集合上
发现规则，因为在CL_2集合上运行的StatsMiner消耗过多内存(超过
40GB)。相似的实验是LRT_A/LRT_A全(图23)。
现实-利用在整个LRT_A集合中发现的规则来压缩CL_2集合。
相似实验的结果可见于图27。
已用-利用在用LRT_A集合中所发现的规则压缩LRT_A集合时
所使用的规则来压缩CL_2集合。相似实验的结果可见于图39。
无规则-不使用StatsMiner所创建的规则来压缩CL_2。相似实
验的结果可见于图36。
合并–利用由StatsMiner在此刻压缩的文件中找到的规则来压缩
CL_2。相似实验的结果可见于图40。
[Math.37]
C L ⋐ C L _ 2 ]]>
性能结果仅应用于StatsCompressor，除了“合并”模型(其中它
是StatsMiner和StatsCompressor的性能之和)以外。
6.3.实验结果的分析
从客户获得的统计数据上的实验结果是令人满意的。如已经提及
的，与LRT_A集合相反，CL_2集合包含由各种版本的HYDRAstor收
集的统计数据，因此自然，结果比来自LRT_A集合上的实验的那些结
果差。然而，损失不是太大——在完整文件的情况下为1.92-7.48％点，
对于仅主体为3.98-9.23％点。请注意，来自CL_2集合的统计数据包含
比来自LRT_A集合的那些(60-100)多许多的样本(140-240)，因此
用于压缩完整文件和仅主体的结果之比不同。所实现的结果证明了在
真实使用情况下使用所设计的解决方案是合理的。
“乐观”结果呈现了可实现的假定最佳结果。事实上，CL集合利
用仅在其子集(CL_2)中找到的规则来压缩，但是如果在全CL集合
中已经找到该规则，则StatsCompressor的压缩比将不会好得多(参见
图35和图38)，但是性能将显著下降。目前，“合并”模型的特征在
于结果下降小于“乐观”模型，如果在全CL集合中发现过“乐观”方
法中的规则，则这可能反转。
在StatsCompressor压缩比下降的情况下，最佳结果是利用“合并
模型”实现了的。这些也是最佳绝对结果(除了“乐观”模型，其由
于规则文件的大小庞大而完全不现实)。根据所使用的压缩器，Zplus
文件最终比Zstat文件小28％-49％——这是非常好的结果。不幸的是，
性能非常差——这看起来与来自CL集合的Zstat文件中的样本的较大
数量相关。另一方面，如已经提及的，StatsMiner和StatsCompressor
没有被设计为在此模型中有效地运行(关于性能)，可进行许多优化。
“现实”模型的结果平庸——它们是可接受的，然而损失显著并
且性能较差(尽管好于针对LRT_A集合的相同实验的情况)。然而令
人担心的是，在仅主体的情况下减小如此大——在针对各个外部压缩
器的所有模型当中最大！另一方面，使用“已用”模型的实验结果令
人满意——StatsCompressor压缩比的下降确实较大，但是略小于“现
实”模型中，然而性能非常好。据信如果在准备规则和压缩文件的情
况下HYDRAstor系统的版本不同，则限制所使用的规则的数量的这一
方法将表现较差，但是最终结果完全可接受。有趣的是，此模型的标
准偏差对于每个使用的外部压缩器和资源消耗类别均下降——这非常
好，因为标准偏差越低，最终Zplus文件的大小的预测越精确。
“无规则”模型的结果略微令人失望——它们在完整文件的情况
下下降了5.04-6.31％，尽管在此方法中StatsCompressor分别对每个文
件进行了所有分析。这看起来与各个Zstat文件中的样本的较大数量有
关，因此例如，寻找常数的效果不是太好。另一方面，这还可能源于
这样的事实：客户具有比用于针对LRT_A集合生成Zstat文件的
HYDRAstor更早的版本的HYDRAstor。最终，HYDRAstor在由客户正
常使用时的表现可不同于在人为长期运行测试中的表现。然而，“无
规则”方法的结果构成了另外的证据：即使在真实示例中，本论文中
所提出的所有方法对于获得好的压缩比也是重要的——仅仅使用
StatsCompressor不足以获得好的压缩比。
所有实验的结果的标准偏差均较好——没有增加很多，尽管压缩
的文件来自于不同版本的HYDRAstor。这暗示了不管使用哪一版本，
由系统生成的统计数据相似。这意味着基于统计数据的分析的异常检
测是合理的(至少使用由StatsMiner找到的相关性)。
当涉及外部压缩器的选择时，对于bzip2工具StatsCompressor压
缩比最高。
6.4.总结
利用所设计的用于压缩接收自客户的一些统计数据的解决方案进
行的实验证明了，基于相关性的压缩在实践中可成功使用。所实现的
结果比在压缩示例统计数据的情况下略差，但是它们仍是令人满意的。
已发现，两个方法明显比其它要好——将StatsMiner与StatsCompressor
合并是第一个，使用已经用于压缩训练集合的规则是第二个。上述第
一个方法具有较好的结果但是非常差的性能——使用它将需要创建新
的工具，该工具将被优化以按照这样的方式工作。第二个方法应该被
进一步调查，因为看起来性能和压缩比二者均可改善——例如，应该
检查利用具有最高显著性(但是还未用于压缩)的规则来扩展规则文
件。
总之，所设计的解决方案是可行的。
第7章现有技术
本论文介绍了一种利用所发现的相关性和领域知识来改善特定类
型的日志的压缩比的方法。所提出的方法看起来在文献中还没有提出
过，特别是在支持站点处搜索相关性并且在客户站点处使用此知识的
构思。然而，所设计的解决方案可应用于计算机科学的几个深入研究
的学科的交叉学科：数据挖掘、压缩和日志分析。
日志的压缩已被研究了很长时间，特别是在超级计算机[BS06]或
者分布式系统[RL04]和[SS07]的背景下。上述文章提出了使用附加的专
用压缩器，其应该随通用压缩器一起使用。所设计的解决方案基于相
同的方法。然而，StatsCompressor以统计数据作为输入。所述统计数
据是一种已经解析且紧凑的(compacted)日志。相反，所引用的文章
的作者自己在与日志解析作斗争，然后尝试寻找一些同一性，并由此
减小文件的大小。[BS06]的作者开发了作用于字节级的算法，而[SS07]
的解决方案通过比较日志的行来运行。[RL04]提出了利用不同的最有
效算法来压缩日志的各列。所有上述文章的作者均将大部分努力投入
了使他们的工具的资源消耗最小化——StatsMiner和StatsCompressor
的这一方面应该仍被改进。
日志是关于系统的状态的知识的非常重要的来源，其可按照许多
方式来使用，如调查[OGX12]所指示的。数据挖掘方法常常用于分析日
志[HBK+03]或者异常检测[OKA10]、[BKK01]、[FRZ+12]。他们全部
以某种方式使用了相关性，尽管不同的作者对此术语的理解不同。
[HBK+03]提出了“综合日志压缩”，其目的不是压缩数据，而是帮助
系统管理员通过寻找(纹理)模式来分析日志。从这一角度，由
StatsMiner生成的规则也可以是用于系统管理员的知识的重要来源。
[FRZ+12]的作者在调整系统时讨论了可能有趣的“瓶颈异常”的概念。
看起来通过将由StatsMiner为特定版本的HYDRAstor生成的规则的模
型集合与在特定Zstat文件中找到的那些进行比较，简单脚本的集合可
帮助发现这样的情形。无约束统计数据之间的异常同一性相关性(“统
计数据文件中的异常”)可就性能瓶颈的存在发出警告。有趣的是，
[FRZ+12]的作者也介绍了与StatsMiner相似的窗口概念。另一方面，
他们使用复杂的数据挖掘技术来进行分析。此段落中提及的所有文章
均提出了用于异常检测的工具，其可(或许)通过利用由StatsMiner
生成的规则来扩展和改进，因为它们全部基于某些类型的依赖性或相
关性——[OKA10]提出了影响结构图，[BKK01]聚集于操作依赖性，
[FRZ+12]描述了用于事件预测的工具。这最后一篇文章也具有详尽的
参考书目。最后，[Say04]介绍了按照与StatsMiner所使用的方法非常
类似的方法分析数据。[Say04]聚集于检测数据流中的时间相关性——
StatsMiner进行非常相似的工作，虽然该文章中所描述的方法搜索关注
的奇异事件，而本论文中所介绍的算法尝试发现一般关系。
从数据挖掘的角度，本论文中所使用的相关性的概念与特定关联
规则有一些相似。有大量方法寻找关联规则，然而，它们看起来过于
一般，因此太慢，无法被StatsMiner使用，特别是此工具的目的是挖掘
准确的数值关系。有趣的是，文章[BMS97]面临更新关联规则以使得它
们从数学角度相关的问题。此文章中介绍的数学方法可被采用以改进
限制StatsCompressor所使用的规则的数量的方法。事实上，本论文中
所使用的显著性的概念非常类似于源自关联规则领域的置信度。此外，
术语支持对应于可出现相关性(因为存在预期的统计数据)的窗口占
所有窗口的数量的百分比。
总之，看起来使用由数据挖掘工具找到的数值相关性来压缩另一
(或者甚至同一)数据集合的构思是新的构思。
第8章总结
本论文介绍了分布式的、基于数据挖掘的方法来压缩统计数据，
而所述统计数据是一种聚集的日志。实现了两种工具：StatsMiner，其
搜索统计数据之间的相关性；和StatsCompressor，其使用由StatsMiner
创建的规则来有效地压缩包含统计数据的文件。两个程序均旨在以分
布式模型来运行——StatsMiner在支持站点处的示例数据上运行的同
时发现相关性，而StatsMiner在客户站点处运行。所述工具的其它协作
模型也已被评价，例如，仅在客户的机器上运行整个软件。
所实现的压缩比满足所有预期——平均来讲，在最乐观的模型中，
使用StatsCompressor在将该工具与bzip2压缩器一起使用时可使节省
空间增加约50％，在将该工具与gzip压缩器一起使用时增加约45％，
在将该工具与xz压缩器一起使用时增加约30％。所述结果可通过实现
StatsMiner的一些扩展(目的是发现更多类型的相关性)来进一步改进。
另一方面，所实现的软件的性能低于预期，虽然它是原型版本，其中
识别性能瓶颈并且提出了一些初步解决方案。
StatsMiner-用于发现统计数据之间的相关性的工具-也可用作异常
检测软件的基础。
有计划将本论文中所描述的一些结果引入NECHYDRAstor中。
该项目的工作是由于HYDRAstor支持团队的实际问题而引发的，可利
用所提出的构思解决这些问题。
<附加说明>
以上公开的示例性实施例的全部或部分可被描述为(单不限于)
以下附加说明。下文中，将描述根据本发明的数据压缩系统的配置的
概要等。然而，本发明不限于下述配置。
(附加说明1)
一种数据压缩系统，包括：
相关性提取装置，用于基于收集的给定数据集合中的数据单元之
间的关系，从所述给定数据集合提取相关性的至少一个候选；
相关性验证装置，用于验证所述给定数据集合中的数据单元是否
满足由所述相关性提取装置提取的相关性；以及
数据压缩装置，用于基于所述相关性验证装置的验证结果，利用
所述相关性来压缩所述给定数据集合。
(附加说明2)
根据附加说明1所述的数据压缩系统，其中
所述给定数据集合中的各个数据单元是包括至少一个数据值的数
据组，并且
所述相关性提取装置基于所述给定数据集合中的数据组之间的关
系，提取相关性的至少一个候选。
(附加说明3)
根据附加说明2所述的数据压缩系统，其中
所述相关性提取装置生成至少一个局部化搜索范围，并且基于所
生成的局部化搜索范围中的数据组之间的关系，来提取相关性的至少
一个候选，在所述至少一个局部化搜索范围中，各个数据组具有相同
数量的数据值，并且
所述相关性验证装置验证由所述相关性提取装置生成的所述局部
化搜索范围中的相应数据组是否满足所述相关性。
(附加说明4)
根据附加说明2或3所述的数据压缩系统，其中
所述相关性提取装置提取预定类型的相关性的候选，然后将具有
所述相关性的数据组从所述局部化搜索范围移除，并且基于移除之后
的局部化搜索区域中的数据组之间的关系再次提取相关性。
(附加说明5)
根据附加说明2至4中的任一项所述的数据压缩系统，其中
所述相关性提取装置从所述给定数据集合提取其中数据值为常数
的任何数据组，然后将其中数据值为常数的所述数据组从所述局部化
搜索范围移除，并且基于移除之后的局部化搜索区域中的数据组之间
的关系再次提取相关性。
(附加说明6)
根据附加说明2至5中的任一项所述的数据压缩系统，其中
所述相关性提取装置从所述给定数据集合中的数据组当中，提取
基于预定标准被确定为相同的数据组的组合。
(附加说明7)
根据权利要求1至6中的任一项所述的数据压缩系统，其中
所述相关性验证装置针对各个数据单元存储满足以百科全书方式
列出的相关性的数据，并且验证所述给定数据集合是否满足以百科全
书方式列出的相关性中的各个。
(附加说明8)
根据附加说明1至6中的任一项所述的数据压缩系统，其中
所述相关性验证装置生成表示相关性的数值表达式，并且针对所
述给定数据集合满足所述数值表达式的情况以及所述给定数据集合不
满足所述数值表达式的情况，验证所述给定数据集合。
(附加说明9)
一种数据压缩方法，包括：
基于收集的给定数据集合中的数据单元之间的关系，从所述给定
数据集合提取相关性的至少一个候选；
验证所述给定数据集合中的数据单元是否满足所提取的相关性；
以及
基于验证结果，利用所述相关性来压缩所述给定数据集合。
(附加说明9-1)
根据附加说明9所述的数据压缩方法，其中
所述给定数据集合中的各个数据单元是包括至少一个数据值的数
据组，并且
所述方法包括基于所述给定数据集合中的数据组之间的关系来提
取相关性的至少一个候选。
(附加说明9-2)
根据附加说明9-1所述的数据压缩方法，还包括：
生成至少一个局部化搜索范围，并且基于所生成的局部化搜索范
围中的数据组之间的关系来提取相关性的至少一个候选，在所述至少
一个局部化搜索范围中，各个数据组具有相同数量的数据值；并且
验证由所生成的局部化搜索范围中的各个数据组是否满足所述相
关性。
(附加说明10)
一种提取用于压缩给定数据的相关性的数据压缩用相关性提取设
备，该设备包括：
相关性提取单元，其基于收集的给定数据集合中的数据单元之间
的关系，从所述给定数据集合提取相关性的至少一个候选；以及
相关性验证单元，其验证所述给定数据集合中的数据单元是否满
足由所述相关性提取单元提取的相关性。
(附加说明10-1)
根据附加说明10所述的数据压缩用相关性提取设备，其中
所述给定数据集合中的各个数据单元是包括至少一个数据值的数
据组，并且
所述相关性提取装置基于所述给定数据集合中的数据组之间的关
系，提取相关性的至少一个候选。
(附加说明10-2)
根据附加说明10-1所述的数据压缩用相关性提取设备，其中
所述相关性提取装置生成至少一个局部化搜索范围，并且基于所
生成的局部化搜索范围中的数据组之间的关系来提取相关性的至少一
个候选，在所述至少一个局部化搜索范围中，各个数据组具有相同数
量的数据值，并且
所述相关性验证装置验证由所述相关性提取装置生成的所述局部
化搜索范围中的所述各个数据组是否满足所述相关性。
(附加说明11)
一种使得信息处理设备实现以下装置的程序：
相关性提取装置，用于基于收集的给定数据集合中的数据单元之
间的关系，从所述给定数据集合提取相关性的至少一个候选；以及
相关性验证装置，用于验证所述给定数据集合中的数据单元是否
满足由所述相关性提取装置提取的相关性。
(附加说明11-1)
根据附加说明11所述的程序，其中
所述给定数据集合中的各个数据单元是包括至少一个数据值的数
据组，并且
所述相关性提取装置基于所述给定数据集合中的数据组之间的关
系提取相关性的至少一个候选。
(附加说明11-2)
根据附加说明11-1所述的程序，其中
所述相关性提取装置生成至少一个局部化搜索范围，并且基于所
生成的局部化搜索范围中的数据组之间的关系来提取相关性的至少一
个候选，在所述至少一个局部化搜索范围中，各个数据组具有相同数
量的数据值，并且
所述相关性验证装置验证由所述相关性提取装置生成的所述局部
化搜索范围中的所述各个数据组是否满足所述相关性。
应该注意的是，上述实施例和附加说明中所描述的程序被存储在
存储设备或计算机可读存储介质上。例如，存储介质是诸如软盘、光
盘、磁光盘和半导体存储器的便携式介质。
尽管参照上述示例性实施例描述了本发明，本发明不限于上述实
施例。在本发明的范围内可按照本领域技术人员能够理解的各种方式
改变本发明的形式和细节。
标号的描述
1统计数据压缩系统
2存储系统
21加速器节点
22存储节点
3统计数据挖掘设备
31数据发送/接收装置
32统计数据库
33窗口生成装置
34相关性提取装置
35相关性验证装置
36规则文件
4统计数据压缩设备
41数据发送/接收装置
42统计数据文件
43经验证规则文件
44统计数据压缩装置