CN104394149B - 一种基于并行分布式架构的复杂事件处理的方法 - Google Patents

Abstract

一种基于并行分布式架构的复杂事件处理的方法属于网络安全领域。本发明把关联分析的查询语句分解成由有状态操作和无状态操作组成的操作序列，按照每个子查询至多有且仅包含一个有状态查询的原则把操作序列进行拆分，并且按照拆分的数目把集群等分成几个子集群，然后把子查询部署到相应的子集群。这样部署到不同子群的不同子操作序列之间可以并行计算，部署到同一个子群的不同机器的同一个操作也可以并行计算。即不同查询之间是并行的(查询间并行)，相同查询之间也是并行的(查询内并行)；查询内并行不仅包括不同操作之间是并行的，而且相同操作之内也是并行的。即每个操作都是并行，这样即可解决查询计算遇到的节点性能瓶颈问题。

Description

一种基于并行分布式架构的复杂事件处理的方法

技术领域

本发明属于网络安全技术领域，特别是一种网络安全事件实时关联分析引擎基于分布式并行架构的实现方法。

背景技术

安全信息和事件管理系统技术为安全相关信息提供一个综合的视角。安全信息和事件管理系统作为安全信息和事件的最终汇总，并对其进行实时分析，其所处的位置居于整个安全防御系统的核心中央。目前的安全信息和事件管理系统已经广泛扩展了事件监控能力，包括主动安全事故监控管理，被动日志自动收集管理。

当前的安全信息和事件管理系统的关联分析引擎是一个集中式的解决方案，随着接入安全信息和事件管理系统的日志源增加，其收集到的数据增长速度已经远快于其关联分析引擎的计算能力提升速度。

目前安全信息和事件管理系统在面对收集数据的增加，主要采取三种思路：第一种思路是改进现有安全信息和事件管理系统关联分析引擎的处理能力，比如采用复杂事件处理技术改进关联分析引擎，该种方案可以暂时缓解关联分析引擎计算能力不足的问题；第二种思路是对未来得及处理的安全信息和事件先缓存，以等待进一步的分析，该种方案的好处是安全信息和事件不会被遗漏；第三种思路是对安全信息和事件采取QoS(服务质量控制)策略，对定义认为无效的事件做丢弃处理，该种方案的好处是对安全信息和事件可做快速的响应。从安全的角度出发，以上三种思路都有缺陷：

采取复杂事件处理技术，增强安全信息和事件管理系统关联分析引擎的技术能力，相比以前，增加了一定的关联分析计算能力的，但是这种增加无法赶上计算数据的增加速度，无法完全改善关联分析引擎的计算能力；

采取缓存技术，可保证安全信息和事件不会丢弃，保证分析的全面性，但是无法满足安全发现的及时性，延后的分析结果对安全处置几乎无太多用处；

采取QoS策略，可保证安全信息和事件的即时关联分析，并作出即时响应，但是丢弃的事件规则是人依据已有的知识制定的，可能会因此遗漏关键的安全事件，导致分析结果不完全。

发明内容

本发明是为了解决以上三种思路的困境，提出一种基于并行分布式架构的复杂事件处理方法，即结合复杂事件处理技术、分布式技术以及并行技术，以分布式并行的复杂事件处理引擎替代当前集中式的处理引擎，以彻底解决当前解决方案面临的技术困境。

本发明结合复杂事件处理技术的特点，把复杂事件处理技术对事件进行处理的操作分解成几个元操作，并把元操作分为两类：无状态操作和有状态操作。所谓无状态操作，即对后面的事件的处理操作和前面的事件的处理操作无关联。所谓有状态操作，对后面事件的处理操作需要依据结合前面事件的处理操作进行处理操作，通过滑动窗口实现。划分的无状态操作包括：映射、转换操作，过滤操作，联合操作；有状态操作包括：聚合操作，连接操作。

本发明方法的流程如图1所示。

本发明方法的具体步骤如下：

步骤1：获取用于关联分析的查询语句；

步骤2：把查询语句按照上文定义的有状态操作和无状态操作分解成一串操作序列；

步骤3：按照有状态操作把操作序列(查询语句)分解成子操作序列(子查询语句)，即有多少个有状态操作就划分成多少个子操作序列。其中划分的第一个子操作序列至少包括无状态的操作，可以仅由无状态的操作组成，且该子操作序列包含了第一个有状态操作之前的所有无状态操作。包含有状态操作的子操作序列其第一个操作一定是有状态操作，该子操作也包含下一个有状态操作之前的所有无状态操作。

步骤4：依照步骤3查询语句划分成子查询的数量，把集群按照该数目等分成相同数量的子群，把查询语句按照步骤2划分成的子操作序列分布式部署到划分好的每个子群上，子群中的每个机器都部署相应的子操作。

本发明结合复杂事件处理技术把关联分析的查询语句分解成由有状态操作和无状态操作组成的操作序列，按照每个子查询至多有且仅包含一个有状态查询的原则把操作序列进行拆分，并且按照拆分的数目把集群等分成几个子集群，然后把子查询部署到相应的子集群。这样部署到不同子群的不同子操作序列之间可以并行计算，部署到同一个子群的不同机器的同一个操作也可以并行计算。即不同查询之间是并行的(查询间并行)，相同查询之间也是并行的(查询内并行)；查询内并行不仅包括不同操作之间是并行的(操作间并行)，而且相同操作之内也是并行的(操作内并行)。即每个操作都是并行，这样即可解决查询计算遇到的节点性能瓶颈问题。

附图说明

图1是本发明流程图。

图2查询语句分解

图3操作序列划分

图4查询部署

具体实施方式

下面结合流程图，对优选实施例作详细说明，应该强调的是，下述说明仅仅是示例性的，而不是为了限制本发明的范围及其应用。

首先结合事件流定义，对复杂事件流元操进行定义：

映射操作Map，其定义如下：

给定一个输入事件流S，依照用户定义一组有序的转换表达式，例如对输入的事件进行属性转换并输出转换结果事件。

过滤操作Filter，其定义如下：

Filter{(P₁,O₁),...,(P_m,O_m),O_m+1}(S)

给定一个输入事件流S，依照用户预定义的一组有序的断言集合{(P₁,O₁),...,(P_m,O_m),O_m+1}，每一个输入的事件转发到该事件适配的第一个断言对应的输出，即符合断言P_m，则输出到O_m，如果全部断言都不符合，则输出到O_m+1。

联合操作Union，其定义如下：

Union(S₁,...,S_m)

该操作合并输入流S₁,...,S_m，并输出一个合并的流，其中这些流模式相同。输出流的模式和输入流的模式相同。

聚合操作Aggregate，其定义如下：

给定一个事件输入流S，在该输入流上执行滑动窗口，并在窗口上应用一组有序的聚合函数每个单独的窗口保持的事件的属性由“Group-by”的参数确定。其中窗口由窗口的大小size，滑动步长advance两个参数定义。窗口类型WType可分为基于时间(Time)和元组(Tuple)两类。

连接操作Join，其定义如下：

Join{P,size,advance}(S_l,S_r)

断言P对从来自左右两个流S_l、S_r的事件e^l、e^r进行判断，size为窗口大小，此处滑动步长advance等于窗口大小size。

下面示例开始：

步骤1：获取用于关联分析的查询语句。

例如：我们比较感兴趣：在180秒内，访问目的端口25、80、135的次数落在区间[15,30]的IP用户到底有多少。因为这可能是蠕虫爆发的结果。

输入事件的模式的域包括：ID(事件标识)、SRC_IP(源地址IP)、SRC_Port(源地址端口)、DST_IP(目的地址IP)、DST_Port(目的地址端口)、timestamp(事件时间戳)、Info(其他信息)。

步骤2：把查询语句按照上文定义的有状态操作和无状态操作分解成一串操作序列。

上文的查询语句可由2个有状态操作(聚合操作A1、A2)和3个无状态操作(Map操作M和Filters操作F1、F2)组成。具体各个操作定义如下：

Map操作M具体定义如下：

M{SRC_IP←SRC_IP,DST_Port←DST_Port,Time←Time}(I,O_M)

Map操作M完成对输入事件流I的元组的属性域进行裁剪，丢弃后续运算不需要的域，即在本示例中去掉ID、SRC_Port、Info等域。Map操作M的下一个操作是Filters操作F1，操作M输出流O_M是F1操作的输入流。

Filters操作F1具体定义如下：

F1{DST_port＝＝25||DST_Port＝＝80||DST_Port＝＝135}(O_M,O_F1)

F1操作仅转发端口等于25、80、135的事件元组。Filters操作F1的下一个操作是聚合操作A1，F1的输出流O_F1是A1操作的输入流。

Aggregate操作A1具体定义如下：

A1{Time,180,1,Access←count(),Group-by＝(SRC_IP)}(O_F1,O_A1)

聚合操作A1统计180秒内每个IP地址访问上面端口的次数(Access)。聚合操作A1的下一个操作是Filters操作F2，聚合操作A1的输出流O_A1是F2操作的输入流。

Filters操作F2具体定义如下：

F2{Access≥15∧Access≤30}(O_A1,O_F2)

F2操作用来过滤掉访问次数小于15次和大于30次的事件元组，仅转发访问次数处于[15,30]区间的事件元组。Filters操作F2的下一个操作是聚合操作A2，操作F2的输出流O_F2是A2的输入流。

Aggregate操作A2具体定义如下：

A2{Time,180,1,SRC_Users←count(),Group-by＝(DST_IP)}(O_F2,O)

聚合操作A2用来统计满足以上条件的IP地址的数目(SRC_Users)。操作A2的输出流O为最终计算结果。

以上可完成步骤1假设的查询语句全部功能。

步骤3：按照有状态操作把操作序列(查询语句)分解成子操作序列(子查询语句)，即有多少个有状态操作就划分成多少个子操作序列。其中划分的第一个子操作序列也可以仅由无状态的操作组成，且该子操作序列包含了第一个有状态操作之前的所有无状态操作。包含有状态操作的子操作序列其第一个操作一定是有状态操作，该子操作也包含下一个有状态操作之前的所有无状态操作。

上文查询语句经过分解操作可做简单抽象，如下图2所示：

按照子查询划分策略，即上述的查询语句可做如下划分，具体如图3所示：

即第一个子查询包含操作M和F1，第二个子查询包含操作A1和F2，第三个操作包含A2。

步骤4：依照步骤3查询语句划分成子查询的数量，把集群按照该数目等分成相同数量的子群，把查询语句按照步骤3划分成的子操作序列分布式部署到划分好的每个子群上，子群中的每个机器都部署相应的子操作。

假设部署的集群的节点数量为90，参照上文划分的子查询语句数，集群划分为3个子集群，每个子集群30个节点。

查询语句最终部署效果如图4：

该种查询部署方式相对代价较小，并且很好的解决了查询计算遇到的节点性能瓶颈问题。

下面给出子操作序列划分原则和查询部署方式的依据：

对于并行计算的代价，定义2个参数表示并行的代价：扇出开销，跳数开销。扇出开销(f表示)：在全系统范围内，任何计算节点和其他计算节点建立联通并维持通信管道的代价。即计算节点和其他节点联通的管道数目越高，花销越大。跳数开销(h表示)：表示在运行在不同节点的操作之间移动(转移)一个元组花费的代价。在不同节点之间转移一个元组，每个元组在发送前是排序好的，在接收端则是乱序的。需要注意的是，给定一个查询，这种开销影响所有运行在不同节点上的串行操作对。对于任何并行策略，定义如下代价函数：

c(X)＝α·f(X)+β·h(X)

其中，α,β∈[0,1]是两个任意的权重。

查询计算分布式部署方法首先可以想到2种：

1、全查询分布部署(FQ表示)：即整个查询部署到每一个计算节点上，每个节点部署同样的查询。假设集群有N个计算节点，则N个节点的每一个节点都需要和N-1个节点保持通信，其扇出开销是N的二次方(N²)。跳数开销和有状态操作数目成正比，这是因为元组在每个有状态操作前需要重新编配。对于在一个查询中有s个有状态操作和N个计算节点，该分布式部署策略的代价是：

2、单操作分布部署(SO表示)：即查询包含的全部操作分别部署到每一个子集群上。在由l个操作组成的额查询和N个计算节点组成的集群，该部署策略的代价如下：

以上两种查询部署策略代价其实可以进行折中。在全查询分布部署策略中，其最小化了跳数的开销(只有在有状态操作之间)，同时最大化了扇出开销(所有节点之间)。在单操作分部部署策略中，其最大化了跳数开销(每对连续操作之间)，同时最小化了扇出开销。本发明给出的查询部署策略同时最小化了这两个代价。即每个元组的跳数等于有状态操作的数(如果第一个有状态操作之前没有无状态操作，本发明假设第一个有状态操作之前有无状态操作)。本发明部署策略(混合策略Mix表示)的代价如下：

显然c(FQ)>c(Mix)，c(SO)>c(Mix)。本发明的查询部署方法代价属于相对较小。

Claims (1)

1.一种基于并行分布式架构的复杂事件处理的方法，其特征在于：

把复杂事件处理技术对事件进行处理的操作分解成几个元操作，并把元操作分为两类：无状态操作和有状态操作；所谓无状态操作，即对后面的事件的处理操作和前面的事件的处理操作无关联；所谓有状态操作，对后面事件的处理操作需要依据结合前面事件的处理操作进行处理操作，通过滑动窗口实现；划分的无状态操作包括：映射、转换操作，过滤操作或联合操作；有状态操作包括：聚合操作或连接操作；

具体步骤如下：

步骤1：获取用于关联分析的查询语句；

步骤2：把查询语句按照上文定义的有状态操作和无状态操作分解成一串操作序列；

步骤3：按照有状态操作把操作序列即查询语句分解成子操作序列即子查询语句，即有多少个有状态操作就划分成多少个子操作序列；其中划分的第一个子操作序列至少包括无状态的操作，或者仅仅由无状态的操作组成，且该子操作序列包含了第一个有状态操作之前的所有无状态操作；包含有状态操作的子操作序列其第一个操作一定是有状态操作，该子操作也包含下一个有状态操作之前的所有无状态操作；

步骤4：依照步骤3查询语句划分成子查询语句的数量，把集群按照该数量等分成相同数量的子群，把查询语句按照步骤2划分成的子操作序列分布式部署到划分好的每个子群上，子群中的每个机器都部署相应的子操作。