软件优才夏令营A decentralized approach for mining event correlations in distributed system monitoring译文（原创）

用一种分布式处理方法 挖掘分布式系统检测到的事件联系

 点击下载演示文档

abstract：现在，对监控、分析和控制大规模分布式系统的需求越来越高涨。监控下的事件往往呈现出相关联的关系，这对资源分配、工作调度还有故障预测有很大帮助。为了发现在检测到的事件中的联系，很多已有的方法是把被检测事件放到数据库中并对其进行数据挖掘。但是我们认为这些方法并不适合大规模分布式系统，因为监控事件的数据量增长得非常快以至于很难用一台计算机的力量来进行事件之间联系的发现。在本文中，我们提出了一种分布式的方法有效地检测事件、过滤无关事件，然后发现他们之间的联系。我们提议用基于MapReduce的算法即MapReduce-Apriori，数据挖掘事件关联规则，这利用了系统中多个专用节点的计算资源。实验结果表明我们分布式的事件关联挖掘算法相比于集中式的挖掘方法得到了近乎理想的速度提升。

 

1.introduction

       大规模分布式系统：机群系统（clusterSystem）、云计算系统（cloud computing System）

       建立一个有效可靠的分布式环境的关键是监测并控制节点、服务和应用。监测这样一个大型系统需要以一个固定频率不断收集性能属性值（比如cpu占用，内存占用）。随着系统的规模扩大，监测产生的间接费用会成为限制性因素。

       在监测期间检测到的事件可以帮助管理员快速定位和解决瓶颈、失败和其他问题。比如，Fisichella等人的论文（在社交网络中检测卫生健康时间来预测传染病）中提出一个三阶段的过程来检测无监督下的公共卫生事件。在特定时间下，我们可以认为一个属性值被观测到超过一个给定的阈值时，故障的时间可以认为是特例。但是，当系统的复杂度持续增长，失败会变为常态而不是例外【44】。传统的方法比如检查点经常被证明为计数器有效【16】。所以故障管理方面的研究已经转移到故障预测和相关主动管理技术上了。【25，30】

       大家一致都认为事件不是独立的而是相互关联的。过去关于故障分析的研究显示了很重要的故障分布模式。尤其，事件在长时间跨度上有很强的联系。前面的研究成果已经显示了事件联系对资源分配、工作调度和故障预测的重要性。【43,16,17】

       事件联系模式描述了不同时间之间的共现现象，这可以通过数据挖掘方法被发现。但是，经典的数据挖掘算法，比如Apriori在挖掘频繁模式时具有指数搜索空间。因为数据挖掘既是计算密集型又是数据密集型，当数据级增大，提高数据挖掘的性能是一个很严峻的挑战。除此之外，基于Apriori的方法不能发现在被检测事件间的短暂联系。之前一些工作【5，,36】致力于在传感器网络中挖掘事件间的短暂联系。但是，在这些方法中，所有的数据都被存储在集中的数据库中。当系统的规模扩大时，聚合事件到一个集中数据库会不够有效。

       集中数据挖掘方法在一些情况下不够实用。第一，在一些监测会持续很多年的领域，被监测到的事件量会太大以至于不能被集成。第二，在一些关键领域，事件联系挖掘很难在一个可接受的时间里仅使用一台计算机的能力完成。相比之下，分布式的数据挖掘尤其适用于那些处理大量数据的应用（比如交易数据、科学模拟、电信数据等），而这种大量数据不能被一个传统的模式在一个可接受时间内分析出来。我们还认为事件不会贯穿整个监测过程，因此事件联系的短暂性必须被处理。

       在本文中，我们聚焦于发现短暂的事件联系，为了加速挖掘事件联系的过程，我们建议事件应该被聚集到一系列数据库中而不是一个集中的数据集，这样事件关联挖掘可以并行完成。除此之外，为了减少聚集开销，事件应该被在本地过滤（在每个节点中）。最后，一个以MapReduce为基础的的事件关联挖掘是实施在一系列数据库上的，以此来并行发现事件关联。事件关联被视作事件关联规则，事件关联规则彰显了基于相同活动间隔之间的暂时性关联。事件关联规则促进预测系统故障的发生并且提高了系统的服务质量（QoS，quality ofservice）。比如，我们期待去收到一个来自某节点某个时间点的事件，但是实际上这并没有发生。这时，我们可以推断那个节点上可能产生了故障。

       本文的主要工作总结如下：

1.我们提升了事件关联挖掘方法通过把被检测到的事件的暂时性考虑在内。

2.我们提出一种方法来有效地在本地过滤无关事件来减少需要聚集事件的数量。

3.我们提出一种基于MapReduce的算法来并行挖掘来自一系列贡献节点的事件的关联规则。

本文的剩下部分被组织如下：

section2描述了模型和概念。

section3给了一个例子来论述我们的方法。

section4介绍了具体算法。

section5给出了实验。

section6复习了相关的工作。

section7总结了论文并讨论了将来的发展

 

 

 

2.Models  and concepts

       在这个部分，我们首先介绍了监测和时间检测框架，然后给出了挖掘监测联系规则的模型。

2.1Monitoring framework

       分布式系统的结构可以被看做一个异构监测树，节点被分为超节点（SN，super node）、管理节点（AN，admin node）、工作节点（WN，working node），超节点是整个监测树的根节点，监测树对整个系统进行控制。管理节点是中间节点，分别管理一系列工作节点。每一个工作节点是一个叶节点。检测事件的任务是分布式的，任务涉及在每一个工作节点的监测单元。一个单元（agent）是一个应用级别的监测程序，这个程序相比于系统中的其他应用独立运行并且通过message-passing【4】与外界进行通信。对于每一个工作节点，他有一个本地存储用来在检测过程中存储被检测到的事件。所有的节点分享一个GlobalDistributeFileSystem（GDFS），GDFS被建立在节点的本地存储之上。每一个节点可以从GDFS上下载文件到自己的本地存储，也可以上传文件到GDFS。

       一个监测请求包括长期运行的活动，用来观察、分析和控制大规模分布式系统和他们服务的应用。每一个监测单元周期性地收集确切属性的值并把它们与已给的阈值进行比较。通常，我们定义一个监测请求如下：

Definition2.1:

、、、

       监测请求由超节点发起，然后通过管理节点被传播到所有工作节点。最后，它激活了监测来启动监测。监测的目标是检查一系列系统性能属性（CPU占有率、内存占有率、网络带宽和在应用层面的任何自定义属性）是否超过相应的阈值。如果一个阈值在某一个时间点某一个地点被超过，那么一个事件被监测到。我们只对一个事件是否被检测到感兴趣，而对相应的属性值不感兴趣。我们给出事件定义如下：

、、、

2.2 Eventcorrelation mining framework

       基于在一个传统数据库的关联规则定义，我们在我们的领域定义item、事务、事务数据库。

       每一个item有自己的生命周期，生命周期明确表示了他的持续时间，我们也定义了item的生命时间。

 

 

3. Motivational examples

       在这个部分中，我们用一个做证明的例子来说明在我们的方案中我们怎么能够挖掘频繁模式

 、、、、

       挖掘结果：((n1, e1) ⇒ (n2, e3), 10 min, 100%).

       意思是：如果事件e1在节点n1上被检测到，十分钟内在n2上检测到e3的可能性为100%。

       给定一个事务的数据库和最小置信度、最小支持度，数据挖掘的问题就是产生所有关联规则（置信度、支持度都大于或等于给定最小值），这可以被分为两部分：

       1.找到频繁模式（频繁项集）；

       2.总结关联规则；

       第一阶段基于一种迭代的方法来发现频繁项集，这个阶段占据数据挖掘开销的统治地位。所以，成功挖掘的关键就在于怎样有效地减少第一部分的开销。

       在下一段我们提出一种分布式的方法来有效地减少开销并加速挖掘进程。

 

4. The algorithms

       在本节中，我们首先介绍本地事件检测算法，然后我们提出MapReduce-Apriori算法，这是一个基于MapReduce的关联规则挖掘算法，在被检测到的事件上有效地过滤掉某些事件（在他们被传送之前），然后并行检测他们的关联。

4.1本地事件检测

       在每个时间点，每一个工作节点上的监测单元检查各个属性是否超过阈值，如果是的，就存储r=（t,(n,e)），即说明事件e被节点n在时间点t检测到。可见Algorithm1.

4.2MapReduce-Apriori

       MapReduce是一个编程模型，是处理大规模数据集的相关实现。用户指定一个映射方法来处理一个键值对从而生成一组键值对，把一组中间值（有相同的中间key）结合在一起。当组件故障成为一种常态而不是特例，MapReduce提供了一种编程的方便和容错。

       MapReduce包括四个阶段：本地事件过滤、合并事件成事务，全局频繁项集挖掘，全局关联规则总结。

       以下是4个阶段的描述：

      1.本地事件过滤：过滤那些支持度计数小于最小支持度的元组（即1-项集，（n，e））或者包括了这些元组的元组。

      2.合并事件为事务：一个MapReduce方法来合并那些在同一时间发生的所有事件到一个事务。

      3.全局频繁项集挖掘：一个多遍迭代的Mapreduce方法来发现频繁项集。

      4.全局关联规则总结：一个Mapreduce方法来总结事件关联规则。

      MapReduce-Apriori从几个输入参数启动，包括最小支持度、最小置信度。

      此时，每一个节点保存了被检测到的事件在他的私有存储里（local storage），GDFS中还没有任何东西可以被分享。 

4.2.1Local fitering

       在这个阶段，我们目标在于当上传记录到GDFS上时减少交流开销。这背后的想法是过滤掉所有支持度计数小于最小支持度的元组。因为如果一个元组在本地不是频繁的，那么它在全局范围内也必定不是频繁的。一旦监测阶段结束，一个在每个工作节点上的扫描便启动，扫描本地存储的每一条记录来计算每一个元组的生命周期（lifetime）和支持度计数。如果一个时间的支持度计数不小于最小支持度，所有的记录都被保存下来，一旦过滤阶段结束，所有留下来的记录全部被上传到GDFS。记录是被存储在不同节点。

       下面Algorithm2描述了细节：

       比如，我们考虑在table2中的事件，给定最小支持度为3，所有支持度大于等于3的时间都将被保存。所以，在本地事件过滤阶段结束之后，只有4条记录被留下，大大减少了需要被传递的记录量。没有记录留下的节点不用传输数据。

4.2.2. Merging records into transaction

        在GDFS中的事件需要在发现他们的关联之前通过时间点分组。这个过程可以并行执行。这里一个Mapreduce的过程是为了合并记录到事务。每一个mapper以键值对的形式输入记录（key=recordID，value=record），record=（t,(n,e)），然后mapper把记录分解为键值对（key=t（t为某个时间点），value=（n，e））所有的mapper都结束之后，对每一个唯一的key t，MapReduce收集他相关的items，然后把键值对（key=t，value=items）传给reducer，这里items是同一个时间点的所有item。reducer收到了同一个时间点的所有键值对，集合所有相同时间点的item到一个事务T，并赋予一个唯一的TID,输出键值对（key=TID，value=T)。

4.2.3. Globalfrequent itemset mining

       因为事务是在GDFS上分布的，所以Mapreduce模型刚好适用于我们的方案来并行全局频繁项集挖掘，这里介绍几条迭代的mapReduce过程。在k次MapReduce过程后，频繁项集被总结完成，这会一直循环直到频繁项集不再增长。

       频繁项集挖掘包括两步：

       1.从频繁（k-1）项集Fk-1总结候补k-项集Ck；

       2.总结频繁k-项集Fk（消除Ck中的支持度计数肖玉最小支持度的项集）；

       第一步成为候选集，需要两小步：第一，在连接过程

       对于两个k-项集{I1, I2, …, Ik-1, Ik}，{I1´, I2´, …, Ik-1´, Ik´}，能够连接产生一个k+1－项集，当且仅当Ii=Ii´,其中iÎ {1, 2, …, k-1}且Ik¹ Ik´，连接结果为( k+1项集)：{I1, I2, …, Ik-1, Ik, Ik´}

如{A, C, D}与{A, C, E}连接产生{A, C, D,E}；而{A, C, D}与{A, B, D}不能连接。

       第二，在修剪步骤，删除掉所有存在k-1项集不属于频繁项集的k-项集。

引理4.1：

一个频繁k-项集与一个频繁j-项集的lifetime=（ik并jk）=[t1,t2],如果（t2-t1)/检测时间间隔<最小支持度，那么ik并ij并不是一个频繁项集。

证明：略

Algorithm是扩大候选集的算法

       在第二步的总结频繁k-项集中，多次Mapreduce过程，每一个从候选k-项集中总结频繁k-项集（通过支持度计数）每一个mapper下载所有候选k-项集，然后它收到一个键值对（key=TID，value=T），然后对每一个候选k-项集中的项，map方法决定T是否包含这个项集，如果包含，输出一个键值对（key=该项，value=1）。reducer总结所有相同key（即候选项）的键值对，重新该候选项的计算生命周期，并判断总支持度计数是否不小于最小支持度。如果是，他输出一个键值对（key=该候选项，value=sup（i，lifetime（i）），Algorithm5给出具体算法：

4.2.4. Globalassociation rule generation

        为了总结关联规则，需要找到频繁项集的所有子集。比如一个频繁项集D，我们必须找到对于每个合适的子集D1，有(D1 ⇒ (D−D1), [t1, t2], conf )，如果conf不小于最小置信度，则这是一个关联规则。Ale和Rossi[3]提出了一个问题，考虑一个频繁项集i，要找出他的所有子集需要一个指数的计算过程。

       为了避免这个，Ale和Rossi假设项集在他的生命周期里均匀分布，所以任何子集出现的概率是相同的，我们认为这在我们的情况中是无效的，因为时间在他的生命周期里不是均匀分布的。

       为了解决这个问题，我们为项集提出了一种增强的生命时间的格式，它记录了项发生的所有时间点而不是最小时间点跟最大时间点。在这种格式的基础上，我们可以直接计算sup（D1，lifetime（D））而不用扫描数据库。

       为了使这个阶段并行化成一个mapReduce过程，每一个Mapper读入一个频繁项集F和他的支持度计数sup(F , l(F ))，输出键值对（key=F,value=F1），F1是F的非空子集，每一个reducer计算(F1 ⇒ (F −

F1), l(F ))的置信度，Algorithm6中给出具体算法，关联规则按照置信度排序，可以直接找出置信度最前的k个规则。

       总结，我们提出的算法的好处如下：

1.不需要把所有数据集中到同一个数据库。而是把时间收集到不同的节点。

2.挖掘时间极度减少，尤其在某些关键领域。

3.时间在本地被过滤，所以需要上传的时间量大大减少。

4.MapReduce是最适合处理今天这种分布式系统产生的大量数据的。

5.我们设计了扩大候选集算法来有效地减少产生的候选项。

 

 

5. Experimental results

       我们在Apache hadoop上实现了提出的算法，Apache Hadoop是一个GoogleMapreduce 框架的开源实现。Apache-Hadoop是一个java框架，支持数据集中分布式应用，Hadoop让应用可以处理上千个节点和pb级的数据。除此之外，hadoop Distributed File System（HDFS）对GDFS来说是一个适合的实现。

       我们首先建立一个分布式系统，然后模拟监测环境来产生合成时间。然后我们应用MapReduce-Ariori算法在合成事件上来发现事件联系。为了展示Mapreduce的有效性，我们还实现了经典的Apriori算法然后把它应用在一个集中地数据库上。我们比较了两种方法挖掘关联规则的执行时间。

5.1. Synthetic eventgeneration

       模拟器通过输入的几个参数产生事件，可以在table6中看到：

       收到这些参数，模拟器会在每个节点上产生属性集合A的值，然后判断值是否超过他的相关阈值。每一个数据集都是独立的，属性值符合标准分布（0，,1），合成事件程序运行在PC上。

我们的模拟包括以下几种方案：

• Given N = 50, A =10, ξmin = 0.7, ξmax = 1.0, with the

increaseof T , collect detected events that are distributed in different nodes within T .

• Given T = 10 000,A = 10, ξmin = 0.7, ξmax = 1.0, with

the increase of N,collect detected events that are distributed

in different nodeswithin T .

• Given T = 10 000,N = 50, ξmin = 0.7, ξmax = 1.0, with

the increase of A,collect detected events that are distributed

in different nodeswithin T .

       一旦事件产生结束，模拟器立刻开始本地过滤时间。通过table8可以看出，我们很有效的过滤了很多不频繁的事件。

 

5.2. Relativeperformance

       在这个部分，我们实现了两种算法来挖掘关联。Apriori运行在一台PC上，MapReduce-Apriori运行在两个节点的Hadoop机群（两台计算机）。我们计算了两种算法的执行时间包括频繁项集挖掘事件和关联规则产生时间。

       2、4、6、7中可以看到两种算法的性能表现不一样，破折号线代表Apriori的表现、、、在我们的试验中，Mapreduce的理想表现已经减少了Apriori时间的一般，获得了两倍的速度提升。

 

5.2.1. Varying monitoring time slots（T不同）

       6 datasets：N50A10T5k,N50A10T10k,N50A10T20k, N50A10T40k, N50A10T70k, andN50A10T100k

       Fig.2可以看出两种算法在T改变时执行时间的变化，T的增大会导致事务的增多。因为TID与一个特定时间点相关联，所以我们后面直接用TID代替代替监测时间点。当事务数相对较小时，两种方法的区别不是很明显。随着事务增加，MApReduce-Apriori开始展示了他的优越性。并且，

       MapReduve-Apriori的表现非常接近理想MapReduce-Apriori。

       接下来，我们研究了频繁项集挖掘，发现对于每个数据集，只有1-项集和2-项集被挖掘了。因为最小置信度为0.07，并没有3个事件的关联可以有如此高的支持度。

       Fig.3描述了被挖掘出的频繁项集数量，黑色是1-项集，红色是2-项集。从图表中我们可以看到在T=20时没有挖掘到2-项集，而6000个2-项集在T=100时被挖掘出来。这可能解释了为什么Fig.2中N50A10T20k的执行时间增长如此快。

 

5.2.2. Varying the number of nodes in a synthetic system

       4 datasets,N50A10T10k,N100A10T10k,N150A10T10k, and N200A10T10k

       分布式系统节点数N变化时两种算法的变化，节点的增长会导致不同元组（item）数量的增长。N50A10T10k已经测试过了，Fig.4展示了当节点增长时，两种算法的不同表现。从图中我们可以看出，MapReduce远远优于apriori,并且接近理想。频繁项集挖掘的数量在Fig.5中可以看出，N100A10T10k的2-项集大于1-项集，但是N150A10T10k的2-项集很小。不幸的是N200A10T10k中没有挖掘到2-项集，

 

5.2.3. Varyingattributes in the system

        4 datasets,N50A10T10k,N50A15T10k,N50A20T10k and N50A25T10k,

        当属性值增长时，会导致不同元组（item）数量的增长。Fig.6比较了两种算法的执行时间，两种算法的执行时间都随着属性种类增长而增长了。Mapreduce-Apriori优于Apriori，减少了一半的执行时间。

 

5.2.4. Varying min_sup_rate in a specific dataset

        我们把最小支持度从0.06开始，每次提高0.01，计算时间数量还有本地过滤算法过滤的元组（item）。接下来，我们应用两种算法在过滤后的时间上，并记录执行时间。

        table9描述了过滤结果，当最小支持度上升，过滤效果提升。

        Fig.7比较了两种算法在不同最小支持度的执行时间。最小支持度上升，执行时间下降，除此之外，mapReduce-Apriori完全由于Apriori，而且逐渐逼近理想情况。

 

6. Related work

 

7.Conclutionsand future work

    在这篇文章中，我们提出了一个在分布式系统挖掘事件关联规则的扩展模型，考虑了检测事件的短暂性。另外，我们提出了一种基于Mapreduce的算法来有效地过滤不相关事件并且发现他们的短暂联系。我们的实验结果体现了我们的算法优于基于Apriori的集中挖掘方法，而且速度大大提升。

    我们的工作会在两个方向被扩展，第一，为了提高挖掘方法的生产能力，我们应该考虑扩展我们的框架来使频繁项集挖掘阶段和关联规则挖掘部分可以使用流水线。第二，我们计划部署我们的框架到一个实际的分布式环境下来进一步验证提出的算法的有效性。