CN105103452B - 数据压缩系统 - Google Patents

Abstract

系统包括：相关性提取装置，用于基于收集的给定数据集合中的数据单元之间的关系从所述给定数据集合提取相关性的至少一个候选；相关性验证装置，用于验证所述给定数据集合中的数据单元是否满足由所述相关性提取装置提取的相关性；以及数据压缩装置，用于基于所述相关性验证装置的验证结果利用所述相关性压缩所述给定数据集合。

Description

数据压缩系统

技术领域

本发明涉及一种数据压缩系统、数据压缩方法、数据压缩用相关性提取设备和程序。

背景技术

在诸如可伸缩存储的分布式系统中，为了解决漏洞或者改善性能，定期地收集各个软件组件的运行情况以及硬件资源的系统状态作为统计信息。

统计信息由巨量的数据组成。例如，为了利用从客户端一侧获得的统计信息来分析系统中的问题，可取的是尽可能多地收集统计信息。同时，存在例如由于安全原因导致可下载的数据量有限的问题。因此，需要压缩数据并且发送压缩的数据，以便在不增加分组的大小的情况下，发送更大量的统计信息。

如上所述，为了实现诸如基于收集的数据执行分析的给定目的，可存储或传送大量的数据。在这种情况下，为了解决如上所述的安全问题，或者从成本的角度看，可取的是压缩数据。

作为一种数据压缩技术，例如已知有专利文献1。专利文献1公开了一种技术，其基于项目信息中的一致性的分布，对压缩目标数据组的数据进行分组，并且根据确定的信息精度对信息已经被重写的数据进行压缩。

引用列表

专利文献

PTL 1：JP 2012-168671 A

发明内容

技术问题

如上所述，在获得数据以用于调查等的情况下，可能关键的是获得大量数据。然而，仅通过利用上述技术执行压缩不总能实现可取的压缩比。

另外，当执行数据压缩连同诸如数据传送的处理以用于调查时，有必要在维持高可靠性的同时压缩数据。然而，与简单地压缩数据相比，在维持高可靠性的同时高效地压缩数据要困难很多。

如上所述，存在难以在维持高可靠性的同时高效地压缩数据的问题。

鉴于上文，本发明的目的在于提供一种能够解决上述问题，即，难以在维持高可靠性的同时高效地压缩数据的问题，的数据压缩系统。

问题的解决方案

为了实现上述问题，作为本发明的一方面的数据压缩系统包括

相关性提取装置，用于从收集的给定数据集合提取构成所述给定数据集合的数据值之间的相关性的至少一个候选；

相关性验证装置，用于验证所述给定数据集合是否满足由所述相关性提取装置提取的相关性；以及

数据压缩装置，用于基于所述相关性验证装置的验证结果，利用所述相关性压缩所述给定数据集合。

另外，作为本发明的另一方面的数据压缩方法包括

从收集的给定数据集合提取构成所述给定数据集合的数据值之间的相关性的至少一个候选；

验证所述给定数据集合是否满足所提取的相关性；以及

基于验证结果，利用所述相关性压缩所述给定数据集合。

另外，作为本发明的另一方面的数据压缩用相关性搜索设备，是提取相关性以用于压缩给定数据的数据压缩用相关性提取设备，该设备包括

相关性提取单元，从收集的给定数据集合提取构成所述给定数据集合的数据值之间的相关性的至少一个候选；以及

相关性验证单元，验证所述给定数据集合是否满足由所述相关性提取单元提取的相关性。

另外，作为本发明的另一方面的程序是使得信息处理设备实现以下装置的程序

相关性提取装置，用于从收集的给定数据集合，提取构成所述给定数据集合的数据值之间的相关性的至少一个候选；以及

相关性验证装置，用于验证所述给定数据集合是否满足由所述相关性提取装置提取的相关性。

本发明的有益效果

由于本发明如上所述配置，所以本发明能够实现一种数据压缩系统，其能够在维持高可靠性的同时高效地压缩数据。

附图说明

图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中的有限差分的dstatistic C的值相同。因此，相关性提取装置34确定统计数据B或A与dstatistic C之间存在同一性相关性(发现存在统计数据B＝dstatistic C以及统计数据A＝dstatistic C的规则)。

通过上述处理，相关性提取装置34提取同一性相关性。然后，作为启发式方法，相关性提取装置34执行处理以将抽象类的代表留在窗口中。在图7所示的情况下，如上所述，统计数据A和统计数据B的值相同。如此，相关性提取装置34删除统计数据A或统计数据B的样本。由此，统计数据A或统计数据B的样本被留在窗口中。

然后，相关性提取装置34提取总和相关性。具体地讲，相关性提取装置34将每两个统计数据的样本相加，并且检查结果是否等于统计数据的现有样本(相关性提取装置34可被配置为检查三个或更多个总和)。另外，当搜索总和相关性时，相关性提取装置34可使用各个统计数据的样本的有限差分。例如，参照图8，发现统计数据D是统计数据E与作为统计数据F的有限差分的dstatistic F之和。因此，相关性提取装置34发现统计数据D与统计数据E和dstatistic F之间存在总和相关性(发现存在统计数据D＝统计数据E+dstatistic F的规则)。

通过上述方法，相关性提取装置34从窗口生成装置33所生成的各个统计数据的样本提取相关性。然后，相关性提取装置34将说明所提取的相关性的规则(验证之前的规则)发送给相关性验证装置35。例如，相关性提取装置34将验证之前的规则，例如，统计数据G＝常数、统计数据A＝统计数据B、统计数据B＝dstatistic C、统计数据A＝dstatistic C、以及统计数据D＝统计数据E+dstatistic F，发送给相关性验证装置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章背景

本论文中尝试解决的问题出现在使用NEC HYDRAstor系统的过程中，因此所述解决方案应该解决HYDRAstor的特定要求。因此，需要所提及的系统的简短描述，涉及它对所开发的解决方案的约束。HYDRAstor的全面规范可见于[DGH+09]中。

此章包含三个章节。

2.1.“HYDRAstor的概述”包含HYDRAstor系统的描述。这里将定义稍后将参考的许多重要术语。

2.2.“系统监测”讨论了日志收集和分析问题，包括HYDRAstor视角。此章节还包含本论文中所描述的研究为何重要的扩展说明。

2.3.“在HYDRAstor中收集统计数据”介绍了在HYDRAstor系统中收集统计数据的处理的一些技术细节以及用于存储统计数据的文件的格式，因为所描述的解决方案必须适应框架。

2.1.HYDRAstor的概述

NEC公司所提供的HYDRAstor是代替磁带驱动器使用硬盘驱动器的企业级、可伸缩、二级存储系统。它支持以高吞吐量和低延迟写备份数据(这些是这种类型的软件的关键要求)。这非常重要，因为备份操作可显著降低被备份系统的效率，所以备份窗口总是具有非常有限的长度。这构成对本论文中所描述的解决方案的主要约束——与HYDRAstor一起运行的软件均不能对写性能具有负面影响。

由于写是HYDRAstor中进行的主要操作，所以将更详细一点地描述它。当进入系统时，备份数据的字节流被分成可变大小的、不可变的组块流。如果一些组块已经存在于系统中，由于组块的内容散列化的使用而将发现这一事实，此类组块将不被写两次。该处理被称为在线去重(inline deduplication)，此概念的使用对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版本处理中，各自具有约50 000个统计数据，然而，在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中的统计数据用于保存关于当前系统状态的所有信息。如前所述，根据在设备中的角色和软件版本，各个机器生成约50 000条不同的统计数据。

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::requestsInProgress::RecentMax和METRIC::DataSynch::DiskRequestManager::RequestsCount::cannotExecuteBecauseOfLimit::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。弱相关性的示例是以下同一性——存在统计数据f_w和g_w，f_w(0)＝5，f_w(1)＝3，f_w(2)＝8并且g_w(0)＝5，g_w(1)＝6，g_w(2)＝8，并且f_w＝g_w+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]中定义的有限差分算子(以下Math 1)的概念将被扩展地使用：以下Math 2。应该注意的是，在以下描述中，使用“d”代替Math 1，如以下Math 3中所示。

[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个统计数据，此外还包括它们的有限差分，则将意味着将需要各个统计数据的100000个样本，由于通常每20秒收集一次统计数据，所以将需要花23天收集的样本！此方法的第二个问题是高斯消去法具有O(n3)的复杂度，因此在使用100000个统计数据的情况下，计算时间将不能接受的高。另一约束来自于内存消耗——存储包含C++的双重(double)的大小为100 000*100 000的矩阵将消耗75吉字节的内存！

由于无法挖掘线性相关性，所以对结果强加的一些要求应该被削弱以使得问题更容易并因此可求解。首先，看起来非常明显的是，相关性的系数将为整数——此观察来自于描述事件的离散空间的统计数据的本质。遗憾的是，搜索具有整数系数的线性相关性是NP难题——存在从子集-和问题的简单归约。由于所研究的问题无法被限制为约束更多的一个，所以选择了另一方法。存在在输入数据上运行的大量简单算法，它们中的每一个发现统计数据之间的另一类型的精确定义的关系。此方法的结果将是从对线性相关性的真实搜索获得的结果的一些子集，但是计算上述子集是可实现的。

4.1.2.阶段

StatsMiner的主要功能是发现统计数据中的相关性。该工具的前几次运行已证明它可找到甚至数十亿的相关性，因此很快，关于相关性的精确定量信息的需要变得明显。此外，由于待搜索的数据量非常大(一次100 000个统计数据)，所以加入了用于加速挖掘处理的一些启发法。最重要的一个是，如果发现一些统计数据上的一种相关性，则在搜索其它类型的相关性之前将它们从工作集移除。此问题将在涉及具体算法时详细描述，但是该方法的效果之一是轻松的相关性可隐藏繁重的相关性。

为了应对这些情况，工具的工作被分成两个阶段。第一阶段是挖掘阶段(图17)，在这一阶段从头开始挖掘统计数据集合中的相关性。自然，这是耗时的处理。例如，在100 000个统计数据(各自具有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.测量性能

所有测试在具有两个Intel Xeon 5645CPU以及48GB的RAM的开发机器上运行。时间和内存利用以参数％U(在用户模式下进程所花费的CPU总秒数)和％M(进程在其寿命期间的最大驻留集大小)运行的时间程序来测量。校正内存消耗结果，使得它们不受熟知的时间计数漏洞的影响[com13]。

4.3.窗口

窗口是StatsMiner中的中心概念，可被描述为所有可用统计数据的可比的、长度相同的样本序列的集合。窗口的长度是各个序列中的样本的数量。窗口的宽度是统计数据的数量。事实上，窗口是矩阵。需要注意，窗口不包含关于它所包含的任何样本的收集时间的任何信息——这是简化窗口的使用的假设。

图19呈现了长度为10宽度为7的示例窗口。单个文件可被切成许多窗口(比较呈现示例Zstat文件的图15与示出从所述文件生成的一个窗口的图19)。搜索相关性的各个算法要求窗口作为输入。由于窗口性质(各个统计数据的样本的数量相同)，挖掘算法的实现被简化。使用窗口的另一益处是结果比较的标准清楚——规则总是应用于特定数量的、良好定义的窗口。另一方面，由工具分析的文件可包含各个统计数据的不同数量的样本，因此与“在3个文件中发现规则”的陈述相比，说“在3个窗口中发现规则”精确许多。在验证过程中扩展地使用窗口的概念——具有描述相关性的规则和窗口，针对各个规则检查两个事实，然后将其保存(参见图18)：相关性是否可应用于窗口(所有预期的统计数据存在)以及样本是否确实满足该相关性。

作为挖掘算法的输入，窗口的内容对发现的相关性的数量和类型具有显著影响。两个独立的问题是重要的——窗口的大小以及生成其的算法(从加载自数据库文件的统计数据得到窗口)。

窗口生成看起来是琐碎的，但是在此处理的过程中需要面对一些问题，使其非常复杂。如之前所提及的，在HYDRAstor中，可按照不同的频率收集统计数据，在单元层面上讲收集处理是异步的，统计数据可能在每一刻出现或消失，最终，样本被存储在长度变化的文件(Zstat)中。在接下来的章节中将介绍用于生成窗口的两个算法。

窗口的大小对在给定数据库文件中发现的相关性的数量和质量具有巨大影响。由于实验已证明太小的窗口会是误导性的，因为所找到的相关性可仅仅是偶然的，但是在过长的窗口中，许多相关性可能被遗漏，因为统计数据收集处理的异步本质打乱了样本，使得严格相关性消失。严格相关性是令人关注的，因为与搜索弱相关性相比，找到它们要容易许多(参见段落4.7.5)。

相关性的质量的度量是其显著性水平。对于相关性C，它被定义为Math 4。

[Math.4]

其中

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的同一性的规则。然而，为了保存相关性f₁＝g₁＝h₁，需要使用三个同一性规则，每一个描述两个特定统计数据之间的关系。在抽象类方法中，需要使用一个规则来存储相关性f＝g，还仅需要一个规则来存储相关性f₁＝g₁＝h₁。

使用组合方法导致更高的内存消耗，例如，当应对简单总和p＝q+r时，如果p＝p₁并且q＝q₁＝q₂并且r＝r₁＝r₂＝r₃，则将创建24个规则来存储所有相关性！在抽象类方法中，仅创建4个规则——每一个抽象类一个，简单总和一个。问题是，是否保存p＝q＝r并且在描述p、q和r的抽象类的其它规则的情况下使用这些规则，或者保存总和作为((p＝p₁)＝(q＝q₁＝q₂)+(r＝r₁＝_r2＝r₃))。总之，从内存消耗的角度，基于抽象类的方法看起来肯定更好，但是当应对多个窗口时情况变得更复杂。

我们假设在窗口W₁中，找到之前描述的相关性(总和)。然而，在窗口W2中，相似但不是相同的相关性：p＝p₁并且q＝q₁＝q₂并且r₁＝r₂＝r₃(以下Math 5)。如果使用组合方法，则此改变将不涉及新规则的创建——更新现有规则的使用计数器(用于计算显著性)就足够了。同时，对抽象类方法没有好的解决方案。一个构思是增加新的规则来描述类r₁＝r₂＝r₃(或者(p＝p₁)＝(q＝q₁＝q₂)+(r₁＝r2＝r₃))，但是规则p＝q＝r该怎么办——应该增加规则p＝q＝r1？如果是，则在W1的情况下相同的相关性将被表示两次(因此在验证阶段被计数两次)。此问题可通过将规则(p＝p₁)＝(q＝q₁＝q₂)+(r＝r₁＝r₂＝r₃)分成两个规则：(p＝p₁)＝(q＝q₁＝q₂)+(r₁＝r₂＝r₃)和(p＝p₁)＝(q＝q₁＝q₂)+(r)来解决。这将解决使用计数器的错误值的问题，但是规则的总数可呈指数激增，因为(p,p₁)、(q,q₁,q₂)、(r,r₁,r₂,r₃)的子集的每一个组合均可出现。另选地，可使用规则p＝q＝r，因为存在类r₁＝r并且可运用传递闭包的概念。然而，在这种情况下，每一个规则可稍后应用于每一个窗口，因为抽象类的数量和大小将增长——结果，规则使用计数器将完全是误导性的。

[Math.5]

r≠r₁

总而言之，基于抽象类的方法是内存消耗和使用计数器的准确性之间的权衡。另外，在组合方法中，验证之前和之后的规则的数量相同，但是在抽象类方法的情况下，如果选择了分割规则作为对计数器问题的补救，则验证之后的规则的数量可急剧增加。

将这两个方法的优点结合得出将各个规则存储为树，因此所有规则创建森林。本论文仅包含此方法的草案。树的根包含最一般形式的相关性(例如，(p＝p₁)＝(q＝q₁＝q₂)+(r＝r₁＝r₂＝r₃)——参见图20)，内部节点包含关于抽象类的分割的信息列表(例如，以下Math 6和r)，叶具有使用计数器。在从根走到叶的过程中，可确定通过从所访问的内部节点到存在于根中的规则应用切割而创建的相关性集合的使用计数器的值是多少。如果仅存在单抽象类，此表示使用至少与抽象类方法相同的内存量(如果不存在内部节点的话)，不超过组合方法(对于树实现的细节)的内存量。此数据结构的复杂度是其内存效果的代价。这仅是该方法的草案，其还未实际测试。

[Math.6]

在所设计的解决方案中，选择组合方法，因为其实现更简单，动作更快(抽象类的分割看起来成本很高)，充分准确并且具有可预测(尽管较高)的内存消耗。此外，以组合方式存储的规则易于可视化或合计——在计数器上进行一些操作就足够了。当规则被转存在硬盘驱动器上时，它们以CSV格式来存储，因此易于利用类似Libre Office、MicrosoftExcel或者仅仅bash脚本的工具来操纵它们。

基于抽象类的方法可以是在客户站点处存储规则时减小规则的大小的方式——所有挖掘可利用组合方法来进行，然后实际发送给客户端的数据可被转换为抽象类形式(特别是如果当时不需要具有使用计数器)。这可被认为是规则文件的一种无损压缩。

4.5.相关性的类型

相关性可被分成两种主要类别——互相关性和内相关性。最受关注的是互相关性，其描绘两个不同统计数据之间的关系。此类型的基本示例是同一性(f＝g，其中f和g是两个统计数据)。完全不同的是内相关性，其仅影响一个统计数据并且描述其一些可重复的特性。内相关性的最简单的示例是常数。

相关性的另一划分与挖掘算法的技术限制关联——在大的统计数据集合中搜索相关性的能力。搜索大多数类型的简单相关性(类似同一性)可在包含所有可用统计数据(在移除常数统计数据之后，70000个)的集合中进行。此类相关性(以及因此，挖掘算法)被称为全局相关性。另一方面，无法一次在许多统计数据(例如，一次不超过1000)之间有效地找到更隐蔽的相关性，类似线性组合，——此类相关性(以及算法)将被称为局部相关性。局部挖掘算法的使用需要首先选择将运行此类算法的所有可用统计数据的子集——这构成全局与局部挖掘算法之间的主要差异。

从压缩的角度，互相关性是最有价值的相关性。全局或局部之间的区别没有不同，虽然希望全局相关性的数量大于局部相关性的数量。相反，对全局相关性的挖掘看起来更简单并且成本更低，如果CPU和内存消耗将保持在可接受的水平，则可在客户站点处进行这种类型的分析。

请注意，在第3章中介绍了严格相关性与弱相关性之间的区别。然而，通常，本论文中所讨论的所有相关性均为严格的。

4.6.全局互相关算法

如前所述，搜索常规的线性组合成本过高，但是可容易地找到一些类的线性组合。互相关算法在窗口中寻找不同统计数据之间的这些特殊类型的关系。在此章节和随后的章节中，n将是窗口中的统计数据的数量(窗口的宽度)，k将是各个统计数据的样本的数量(窗口的长度)。

需要注意的是，仅所介绍的算法中的一些被实现并在实践中评估：用于同一性发现的排序算法以及用于简单总和发现的蛮力算法。其它算法应该被当作如果性能不满意的情况下的可选方案。一些算法具有所描述的一些可能扩展。这些扩展可增加找到的规则的数量。

4.6.1.同一性的挖掘

同一性是互相关性的最基本的示例。据信由于相同的事件常常在系统的不同层中被独立地记录，所以同一性的数量将非常高，例如，接收或发送的消息的数量。

搜索同一性的算法在窗口中发现样本向量的抽象类。为了减少后续挖掘算法的运行时间(参见图17)，仅各个抽象类的一个代表被留在窗口中，剩余成员被移除。平均而言，IdentityMiner得到包含20366个统计数据的窗口作为输入，并且它输出包含12 236个统计数据的窗口(两个值均是针对LRT_A数据集计算的)。

用于同一性发现的排序算法

描述

此算法的构思非常简单——各个统计数据可被当作样本向量，因此统计数据可利用样本值的词典比较物(lexicographical comparator)来排序。当使用类似合并排序的标准算法时，算法的此步骤的复杂度为O(kn log n)。复杂度的下界(以下Math 7)来自决策树分析[Knu98]，此复杂度通过[FG05]中描述的算法来实现。然而，由于在StatsMiner中通过指针来访问样本向量，所以上述文章的作者建议经典快速排序也可具有O(nk+n log n)的复杂度。

[Math.7]

ω(nk+n log n)

在对样本向量进行排序之后，花费O(nk)时间来检查后续向量是否相同，因此可记录同一性相关性。总之，所实现的算法具有O(nk log n)的复杂度，但是理论上可实现O(nk+n log n)的最佳情况复杂度，但是需要更多努力。

自然，如果在窗口中两个统计数据f和g相同，则它们的有限差分也相同(df＝dg)。然而，不存在相反暗示(以下Math 8)。StatsMiner的目的是为StatsCompressor生成规则，因此保存规则f＝g就足够了。由于实际执行的原因，规则df＝dg从未被创建——它是基于没有太多(df＝dg以及以下Math 9)的示例的假设的启发性构建。

[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::aioC tx-shred::AioStat::numberReqsCompleted

3.METRIC::transaction::FP::05DM::tl::syncs::req::NumStarted＝METRIC::transaction::FP::05DM::tl::creations::req::NumStarted

在客户的日志上运行该算法花费(总共)21秒，生成776 814个规则(平均每一分析的窗口57 210个规则)。(需要注意，一个规则可在许多窗口中被发现，因此它在各个窗口的情况下单独地影响“每一分析的窗口的规则的平均数量”，但是在讨论所生成的规则的“总”数时该规则仅被计数一次。)对LRT_A数据的分析导致在54秒的累积时间内挖掘561 560个规则(平均每一分析的窗口29 026个规则)。结果的讨论可见于段落4.9。所发现的规则的显著性将在段落4.9中讨论。

用于同一性发现的散列(hashing)算法

描述

先前算法的主要问题在于，在最差情况下，应该比较各个向量中的所有样本的值，以对向量集合作出次序。提高排序算法的速度的最简单的方式之一是首先比较向量的散列-仅在散列相等的情况下才返回到向量值的比较。先前算法的其余部分保持不变。可自由选择散列方法。

该算法在最差情况下的复杂度仍为O(nk log n)，但是平均情况下的复杂度为O(nk+n log n)。重要的是，如果向量的散列已经被实现，则从常规的排序算法升级到其散列版本应该非常简单。

由于用于同一性发现的排序算法很好地执行，所以散列版本还未实现。

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集合中的挖掘，而之前，开发者机器快速地用光内存。

平均而言，此章节中所描述的任何类别的算法得到包含12 236个统计数据的窗口作为输入(对于LRT_A集合)。

用于简单求和发现的蛮力算法

描述

蛮力算法不是太复杂——每两个统计数据的样本被求和，然后检查结果是否等于任何现有统计数据。该算法的成本为(kn2+kn2log n)＝O(kn2log n)，因为存在一定数量的成对统计数据将被求和，如以下Math 10所示，对一对求和与k成线性关系，检查结果是否等于现有统计数据意指在统计数据的有序集合中的二分查找，复杂度为O(k log n)。

[Math.10]

上面介绍的总和模型假设加法是可交换的。对于浮点数，如果它们的表示使用不同的指数，则在对超过两个元素的序列求和的情况下并非如此。此外，即使仅搜索两个元素的和，结果的舍入(数值误差)在实现此算法的过程中也是实际问题。作为解决方案，使用long double型来对样本进行排序(代替常规的double型)。

测试结果

该算法为客户日志创建了(总共)25 803 555个规则，花费了6137秒(平均每一分析的窗口4 601 590个规则)。LRT中的挖掘导致在20402秒(340分钟)内发现(总共)13 738732个规则，平均每一分析的窗口生成431 324个规则。由于使用组合形式来存储规则，所以由更新规则的数据库而导致运行该算法的较长时间。结果的讨论可见于段落4.9。所找到的规则的显著性在段落4.9中讨论。

该算法将在示例窗口(图19)中找到以下规则：stat_delta＝stat_epsilon+dstat_zeta。

在真实HYDRAstor的统计数据中找到的一些求和规则(将不说明其名称的含义，因为这将需要系统内部的精确描述)：

1.METRIC::dci::NumFinisedGetReqs＝METRIC::dci::HintVector@WI::NumNegHintHits(finitedifference)+METRIC::dci::NumHashArrayGetReqs(finitedifference)

2.DISK::sdl2::totalBandwidth＝DISK::sdl::writeBandwidth+DISK::sdl::readBan dwidth

3.DISK::sdb6::writesMergedPerSec＝DISK::sdb12::readsMergedPerSec+METRIC::ackCollector::dataLocs::dataLocCacheSize::RecentAvg

可能扩展

此朴素算法的成本非常高，挖掘三个元素之和看起来根本不是好的构思。另一方面，可实现简单启发以使它合理。在发现一些统计数据(被称为lhss——先导)等于一些其它统计数据总和之后，可尝试对lhss求和并且检查结果是否不与任何其它现有统计数据相同。此构思基于这样的认识：常常存在计数器的层次结构——存在一些零级计数器告知一些事件的数量，存在一些一级计数器是零级计数器之和，等等。

用于简单总和发现的散列算法

加法散列

作为减小StatsMiner的CPU消耗的方法，已经在讨论用于同一性发现的散列算法(参见段落4.6.1)时建议了散列法。发现总和的处理也可利用此方法的优点，虽然可使用特殊的散列函数——加法散列函数。

加法散列函数应该具有以下性质：

以下Math 11

这里，

以下Math 12、13

[Math.11]

[Math.12]

统计数据的样本向量

[Math.13]

H：散列函数Qⁿ→N

事实上，从线性代数的角度，这种函数是一种“弱化的”线性函数(仅需要可加性——而非完全线性)。

好的散列函数应该具有两个性质(根据[Knu98])：

1.散列值的计算应该快速，

2.冲突的数量应该最小化。

以下函数满足此章节中所提及的所有标准(它是“好的散列函数”并且它也是线性的)：

以下Math 14

这里

以下Math 15、16

b：大自然数

[Math.14]

[Math.15]

统计数据的样本向量

[Math.16]

不太小的质数的向量

如上所述的函数H是加法的，因为它是所使用的所有操作均为加法的。它可快速计算，特别是可使用SIMD指令来增加计算速度(易于通过使得编译器能够自动将它向量化的方式来实现此函数)。存在此函数的原型实现，它证明了如果b尽可能大(优选质数，但是在64位机上264更加实际)并且c包含足够大的质数，则冲突数量在可接受的水平，因此针对(以下Math 18)的大多数值建立以下Math 17。另一方面，H表示一种模块散列函数，据信此类函数具有良好的性质(根据[Knu98])。

[Math.17]

f[i]·c[i]＞f[i]·c[i]mod b

[Math.18]

已试验性地实现了所描述的函数(作为整个算法)，虽然由于在对IEEE-754浮点进行工作时无法以这种方式将浮点值散列化(舍入使得整个构思不可用)，所以进一步工作(和实验)已停止。使用定点运算将解决该问题，但是它还未最终实现。因此，该算法仅对整数值适用。

描述

散列算法类似于蛮力算法，但是它使用改进的求和及比较方法。由于加法散列，可从朴素算法的复杂度移除k因子，因此散列算法将具有O(kn+n²+n²log n)＝O(kn+n²log n)的平均时间复杂度。蛮力算法的复杂度中的k因子来自于样本的比较和求和，而当使用所描述的散列方法时，两个操作均可在(O(1))时间中进行。自然，应该首先计算所有统计数据的散列，此步骤具有(O(kn))的复杂度，但是另一方面，将数据加载到内存具有相同的复杂度，因此实际上，此成本可被忽略。

测试结果

对此算法没有进行性能实验，因为它仅被部分地实现，还没有充分调整，并且如已经提及的，它无法适当地用于浮点样本。

可能扩展

自然，在介绍蛮力算法时描述的启发法也可用于散列算法。值得一提的是，预计计数器的层次结构现象将仅随整数值计数器出现，因此这里，即使弱散列方法(不支持小数值)也将足够了。据此，混合方法是可行的——蛮力算法可用于找出一级计数器，更高级计数器可利用散列算法来寻找。就计数器的层次结构可出现在整数值统计数据上的认识，是基于这样的假设：小数值的统计数据通常用于描述时间周期，它们不会如此频繁地被一起求和。另外，如果存在小数值的更高级计数器，则它们可能已经被一些源自浮点数的本质的数值误差所污染，因此寻找此类总和会极其困难。

4.6.3.总结

全局互算法是StatsMiner的规则的最重要的来源。在所介绍的构思当中，用于同一性发现的排序算法和用于简单求和发现的蛮力算法已被完全实现，(功能上)进行了测试和评估。结果是它们可发现数量巨大的相关性，规则的存储方式是它们的主要问题。

4.7.局部互算法

此章节中所描述的算法由于其特性或复杂度而无法在整个窗口上运行。不幸的是，这里所介绍的构思由于对项目的时间限制均没有在所描述的软件中实现，因此它们应该被当作未来工作的草案。

4.7.1.限制窗口宽度

随机选择

限制窗口的宽度的最简单方法(此类窗口将被称为缩小窗口)是随机地选择期望数量的统计数据。倘若挖掘算法将能够很好地用于足够大的集合，则这会是很好的想法。例如，在对LRT_A集合挖掘的情况下，当计划运行局部互算法时，窗口中一次存在约15 000个统计数据(参见图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。

相同词干

如已经陈述的，统计数据的名称由一列项组成。此外，这些项中的每一个由按照骆驼拼写法(Camel Case)拼写的词(称为词干)构建而成，因此可容易地从长的名称提取单个词干。自然语言在进行命名时看起来非常灵活，但是存在可用来对相似事物进行命名的有限一组词，例如，METRIC::DataSynch::SccCache::SccChunksCount和METRIC::memory::PerClass::DataSynch::SingleSccCache::SUM具有略微不同的名称，但是实际上它们表示相同的事物，此外，它们的名称共享许多相似的词干。这一观察可用于构建智能启发法以用于发现相似统计数据——相似的统计数据在其名称中具有许多共同的词干。

相同发送者

Zstat文件包含关于从其收集了统计数据的单元(统计数据的发送者)的信息。它可以是以下启发法的基础：来自相同单元的统计数据比来自不同单元的那些统计数据更相似。此方法来自于这样的观察：单元具有精确定义的、窄范围的功能，因此两个统计数据测量相关的事件的机会更高。另一方面，来自不同单元的统计数据之间的关系看起来更受关注(从理论的角度，因为它们可揭示HYDRAstor中的一些非预期的依赖性)，但是通过此启发法评估它们欠佳。

相同类型

Zstat文件包含关于统计数据的类型(浮点、百分比、计数器等)的信息。通常，相关性可更愿意出现在相同类型的统计数据之间，但是已知一些例外情况(特别是当提到测量每秒的事件数量的定时器时，例如，METRIC::flowControl::node::SlotsComputer::Bandwidth::duplicateWriteCountPerSec)。

动态启发法

相关性

已经在窗口中相关的统计数据应该被当作非常相似。在同一性的情况下，顶点甚至可被合并，但是将存在将所合并的顶点与其它顶点链接的边缘的不同权重的问题。因此，具有表示“完全相似”的权重的边缘应该是优选的。另一方面，相关性中涉及的统计数据越多，它们之间的相似性越小(例如，如果存在相关性f₀＝f₁+f₂和g₀＝g₁+g₂+g₃，则与g₀、g₁、g₂、g₃相比，f₀、f₁、f₂彼此更相似)。

相同的值改变次数

并非所有统计数据在每次它们被采样时改变它们的值。假设统计数据之一是几个其它统计数据之和(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.线性组合

线性组合是统计数据之间搜索的最一般、因此最受关注的一种关系。通过窗口，利用线性代数的方法来计算线性相关的统计数据。按照此理论的语言，窗口可被表示成以下面的Math 19表达的矩阵，其中m是窗口的长度(样本的数量)，n是窗口的长度(统计数据的数量)——需要注意的是，窗口这里被转置。预计m＝n，否则将存在至少|m-n|个相关向量，此外，将出现结果的解释问题。上述要求是不在整个窗口上运行线性组合的挖掘的最重要的原因，因为可能由于需要大量的样本而无法满足此预期。

[Math.19]

W∈Q^m×n

确定来自的W哪些向量线性相关的经典方法是高斯消去法。所描述的问题可按照下面的Math 20的形式来表达，因此求解线性方程的任何算法可应用于它。非平凡x表示一些向量(统计数据)线性相关，但是从x得到系数可能令人困惑，需要缩小列阶梯形式。

[Math.20]

手动编码的高斯消去法可能效率低(从高速缓存使用等的角度)并且由于数值误差而发生偏差，因此这里优选使用线性代数库。事实上，此类软件提供使用例如LU分解的计算，代替纯高斯消去法。

不管选择高斯消去法还是任何其它流行的分解方法，在给定窗口中寻找统计数据之间的线性组合的复杂度均为(O(n³))。

4.7.5.回归

线性组合是StatsMiner所寻找的最强大的一种关系。然而，StatsCompressor足够灵活以使用弱相关性。此特征被介绍用于缓解统计数据的异步收集问题，它允许StatsCompressor甚至在挖掘阶段使用无法完全应用的规则。此类规则可利用多维回归分析(在[SE02]中简要介绍)来寻找。事实上，在此领域已进行了许多研究，因此选择挖掘回归规则的最佳方法将需要进一步的调查。此刻，已经知道的是，这种类型的任何算法由于其高复杂度((O(n³)或更差)而应该在缩小窗口上运行。

4.7.6.总结

此章节中所介绍的构思由于缺少时间均没有被实现——详尽阐述现有算法看起来比介绍一些新的、测试不好的算法更重要，特别是对聚类的许多工作应该首先进行。另一方面，发现统计数据之间的线性组合(严格线性组合和基于回归的弱线性组合二者)的能力可很大地提高StatsCompressor所实现的压缩比。它对于异常检测也是重要的。

4.8.内算法

内算法搜索统计数据的可重复性质。由于无需在不同统计数据之间比较样本，所以这种类型的算法可在统计数据的所有样本上运行——将样本分成窗口可能是多余的。内算法的这种特性使得它们是成为用于减小互算法的搜索空间的启发法的知识来源的完美候选。

4.8.1.发现常数

常数函数是内相关性(还有任何其它相关性)的最简单示例。意外的是，许多HYDRAstor统计数据长时间保持恒定——平均来讲，来自LRT的Zstat文件(具有约83个样本)包含约48940个统计数据，11 860个根本不改变其值(约25％)。

发现常数是简单的过程——检查给定统计数据的所有样本是否具有相同的数值就足够了。在各个窗口中针对统计数据单独地进行该搜索——它是来自以下假设的例外：寻找内算法仅对未被分成窗口的样本才合理。事实上，由StatsMiner发现常数，但是StatsCompressor不从规则文件加载这些规则——StatsCompressor自己发现常数(参见段落5.8.1)。

发现常数统计数据之间的相关性(例如，求和)是比统计数据改变值的情况简单许多的任务，但是此类互相关性从压缩的角度来看相当无用。此外，将存在描述常数统计数据之间的相关性的数量巨大的规则。因此，StatsMiner在生成窗口之后直接发现常数统计数据，这些统计数据不用于此窗口上的进一步挖掘。

在示例窗口(图19)中，将找到一个常数：stat_eta。

该算法为客户日志创建了(总共)154023个规则，花费了8秒(平均每一分析的窗口33152个规则)。LRT中的挖掘导致在38秒内发现(总共)117310个规则，平均每一分析的窗口生成36 633个规则。结果的讨论可见于段落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％所发现的规则具有以下Math 21的关系。如果仅具有最高显著性的规则可被传送至客户站点(参见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集合的值为8 599 140，CL的值仅为6 774 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]

Space saving(Compressor,Zstat)＝1-ScCR(Compressor,Zstat)

这里，

size of Compressor(Zplus)＝由StatsCompressor压缩，然后由Compressor压缩的Zstat文件的大小。

size of Compressor(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呈现了绝对压缩比(示出于下面的Math 24中)。行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(r₁)，cost(t₁)＝15，cost(r₁)<cost(t₁)

12＝cost(r₂)，cost(t₂)＝30，cost(r₂)<cost(t₂)

其中，t₁和t₂是应用于与对应r₁和r₂相同的统计数据的变换格式。

对规则进行评分的绝对成本方法

规则的得分为

score(r_i)＝cost(r_i)

在上面定义的示例的情况下，将为score(r₁)＝10和score(r₂)＝12。这些得分引入以下顺序：

[Math.25]

r₁＞r₂

对规则进行评分的相对成本方法

规则的得分如Math 26中所示。

[Math.26]

其中，t_i是r_i尝试压缩的相同统计数据的变换格式。在上面定义的示例的情况下，将为score(r₁)＝0.625和score(r₂)＝0.4。这些得分引入以下顺序：

[Math.27]

r₁＞r₂

如实验所证明的，相对成本方法执行得略微更好，根据所使用的外部压缩器提供高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。在所有检查的有向规则当中，4 523 420(每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，则图形中将存在以Math 28表示的边缘。因此，求和规则p＝q+r的使用引入以Math 29和Math 30表示的边缘。该图形被保存在存储器中，并利用深度优选搜索算法来检测环的存在。

[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(n log(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＝f₀,f₁,f₂,f₃的压缩，可选择以下规则：f₁＝f₀，f₂＝f₁，f₃＝f₂。然而，这不是最佳的，因为应该使用至少三个不同的标识符——x、y、z并且x＝id(f₀)、y＝id(f₁)、z＝id(f₂)＝id(f3)。最佳方法是如下对整个抽象类进行编码：f₁＝f0，f2＝f₀，f₃＝f₀，因为将仅使用一个标识符t＝id(f₀)。将存在t＝id(f₀)＝id(f₁)＝id(f₂)＝id(f₃)。请注意，在这种情况下，无法得到统计数据f₁、f₂和f₃的原始标识符。然而，这不是必要的。

抽象类的表示的优化处理被称为展平，因为其目的是降低用于对抽象类进行编码的规则树的高度。最佳树高度为1，因此各个抽象类只有一个代表。使用并查集(Find-Union)算法来进行它。在开始，各个统计数据形成单元集。如果统计数据之间存在严格同一性，则适当的集合(表示此统计数据的抽象类)被合并。最后，每个集合仅有一个代表被使用(在来自先前段落的示例中，f0)。实际上，使用Boost不相交集库。复杂度为O(以下Math31)，其中以下Math 32是逆阿克曼函数，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-统计数据的样本序列

s_i–序列s的第i样本

T_i(s)-将变换格式t应用于序列s的第i样本的结果

0-变换格式

仅为了清晰而引入0-变换格式，以使得以下陈述总成立：“如果统计数据的样本应该被(明确地)转存在Zplus文件中，则使用变换格式。”0-变换格式不以任何方式变换样本——其值仅仅按照与其存在于Zstat文件中的相同方式被“原样”保存。

T_i(s)＝s_i

差分变换格式

差分变换格式基于这样的假设：统计数据的值逐渐改变，因此保存当前样本与前一样本之差可比明确地保存两个样本的值成本更低——所述差常常是较小的数，具有较低成本。此外，相同的值可频繁地作为差而出现，因此它们将被外部压缩器有效地压缩。为了能够计算差，假设统计数据的第一样本之前的样本的值为0。在StatsCompressor中针对有限差分上的所有计算运用此方法，从而允许例如，当已经知道统计数据g的样本时，利用规则df＝g压缩的统计数据f的解压缩。

T₀(s)＝s₀-₀＝s₀

T_i(s)＝s_i-s_i-1 i>0

优势变换格式

发明优势变换格式是因为观察到一些统计数据很少改变它们的值，因此保存这些统计数据的优势值以及偏差向量就足够了。由于使用稀疏偏差向量(参见附录A)的编码，后者可有效地进行。优势变换格式的计算需要读取统计数据的样本两次——在第一次，寻找优势(最常见的值)，在第二次，确定偏差。然而，如性能结果所证明的，扫描序列两次对StatsCompressor的性能没有可见的影响。

c–序列的优势——样本序列s中的最常见的值

T_i(s)＝s_i-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的假象，因为一些统计数据(为压缩的文件中的常数)可能由于缺少上述同一性规则而被极为无效地压缩。例如，如果建立以下Math 33、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文件平均42 010个(因此，86％的统计数据可利用相关性来压缩)。另一方面，平均41 008个规则压缩常数统计数据并且由StatsCompressor自己生成。然而，这是相当好的消息，因为这证明了在StatsMiner中放弃常数(参见段落4.8.1和段落5.8.1)是好的决策——否则的话，规则文件将巨大，且StatsCompressor将比现在慢许多。因此，从文件加载的规则的应用次数(总共6598)应该与非常数的统计数据的数量(14 528)进行比较，因此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集合，其中建立以下Math 36。CL_2集合包含从接收自HYDRAstor的真实用户(客户)的文件当中随机选择的50个XML文件(CL仅具有30个)。这些文件由安装了各种补丁和更新的各种版本的HYDRAstor系统来生成。仅同意大小为2MB至4MB并且由SN生成的文件进行此测试。所选择的文件被转换成Zstat格式。它们包含约50.000个统计数据，每个统计数据具有140-240个样本(但是一个文件中的所有统计数据具有约相同数量的样本)。

[Math.36]

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集合。需要注意的是建立以下Math 37以及|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]

性能结果仅应用于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-用于发现统计数据之间的相关性的工具-也可用作异常检测软件的基础。

有计划将本论文中所描述的一些结果引入NEC HYDRAstor中。该项目的工作是由于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 统计数据压缩装置

Claims (9)

1.一种数据压缩系统，包括：

相关性提取单元，所述相关性提取单元基于收集的给定数据集合中的数据单元之间的关系，从所述给定数据集合中提取相关性的至少一个候选；

相关性验证单元，所述相关性验证单元验证所述给定数据集合中的数据单元是否满足由所述相关性提取单元提取的相关性；以及

数据压缩单元，所述数据压缩单元基于所述相关性验证单元的验证结果，利用所述相关性来压缩所述给定数据集合，

其中，

所述给定数据集合中的数据单元中的每一个是包括至少一个数据值的数据组，并且

所述相关性提取单元基于所述给定数据集合中的数据组之间的关系来提取相关性的至少一个候选，

其中，

所述相关性提取单元提取预定类型的相关性的候选，并且然后从局部化搜索范围中移除将具有所述相关性的数据组，并且基于移除之后的所述局部化搜索范围中的数据组之间的关系来再次提取相关性。

2.根据权利要求1所述的数据压缩系统，其中，

所述相关性提取单元生成至少一个局部化搜索范围，并且基于所生成的局部化搜索范围中的数据组之间的关系，来提取相关性的至少一个候选，在所述局部化搜索范围中，各个数据组具有相同数量的数据值，并且

所述相关性验证单元验证由所述相关性提取单元所生成的所述局部化搜索范围中的各个数据组是否满足所述相关性。

3.根据权利要求1所述的数据压缩系统，其中，

所述相关性提取单元从所述给定数据集合中提取数据值为常数的数据组中的任何一个，并且然后从所述局部化搜索范围中移除数据值为常数的数据组，并且基于移除之后的局部化搜索范围中的数据组之间的关系来再次提取相关性。

4.根据权利要求1所述的数据压缩系统，其中，

所述相关性提取单元从所述给定数据集合中的数据组当中，提取基于预定标准被确定为相同的数据组的组合。

5.根据权利要求1所述的数据压缩系统，其中，

所述相关性验证单元针对各个数据单元存储满足以百科全书方式列出的相关性的数据，并且验证所述给定数据集合是否满足以百科全书方式列出的相关性中的每一个。

6.根据权利要求1所述的数据压缩系统，其中，

所述相关性验证单元生成表示相关性的数值表达式，并且针对所述给定数据集合满足所述数值表达式的情况以及针对所述给定数据集合不满足所述数值表达式的情况，来验证所述给定数据集合。

7.一种数据压缩方法，包括：

基于收集的给定数据集合中的数据单元之间的关系，从所述给定数据集合中提取相关性的至少一个候选；

验证所述给定数据集合中的数据单元是否满足所提取的相关性；以及

基于所述验证的结果，利用所述相关性来压缩所述给定数据集合，其中，

所述给定数据集合中的数据单元中的每一个是包括至少一个数据值的数据组，并且

基于所述给定数据集合中的数据组之间的关系来提取相关性的至少一个候选，

其中，

提取预定类型的相关性的候选，并且然后从局部化搜索范围中移除将具有所述相关性的数据组，并且基于移除之后的所述局部化搜索范围中的数据组之间的关系来再次提取相关性。

8.一种提取用于压缩给定数据的相关性的、用于数据压缩的相关性提取设备，所述设备包括：

相关性提取单元，所述相关性提取单元基于收集的给定数据集合中的数据单元之间的关系，来从所述给定数据集合中提取相关性的至少一个候选；以及

相关性验证单元，所述相关性验证单元验证所述给定数据集合中的数据单元是否满足由所述相关性提取单元提取的相关性，

其中，

所述给定数据集合中的数据单元中的每一个是包括至少一个数据值的数据组，并且

所述相关性提取单元基于所述给定数据集合中的数据组之间的关系来提取相关性的至少一个候选，

其中，

所述相关性提取单元提取预定类型的相关性的候选，并且然后从局部化搜索范围中移除将具有所述相关性的数据组，并且基于移除之后的所述局部化搜索范围中的数据组之间的关系来再次提取相关性。

9.一种存储程序的非瞬时计算机可读介质，所述程序用于使得信息处理设备实现以下：

相关性提取单元，所述相关性提取单元基于收集的给定数据集合中的数据单元之间的关系，来从所述给定数据集合中提取相关性的至少一个候选；以及

相关性验证单元，所述相关性验证单元验证所述给定数据集合中的数据单元是否满足由所述相关性提取单元提取的相关性，

其中，

所述给定数据集合中的数据单元中的每一个是包括至少一个数据值的数据组，并且

所述相关性提取单元基于所述给定数据集合中的数据组之间的关系来提取相关性的至少一个候选，

其中，

所述相关性提取单元提取预定类型的相关性的候选，并且然后从局部化搜索范围中移除将具有所述相关性的数据组，并且基于移除之后的所述局部化搜索范围中的数据组之间的关系来再次提取相关性。