本发明涉及数据处理，更具体地，涉及一种基于规则的数据处理方法及规则引擎装置。
背景技术：
规则引擎是一种嵌入在应用程序或者植入在芯片上的一个组件，实现了业务决策从应用代码中分离出来，这种规则是可以配置化实现的。一条规则包含基本元素有：触发条件和目标动作。比如：规则是：当有人尝试开我家的锁失败3次，发一个警报信息到我的手机，其中的触发条件是：连续开锁失败3次，目标动作是：发送警报信息到某个手机
规则引擎需要在系统运行时允许用户动态配置业务规则，无需部署服务器即可实时生效，消息来源的数据结构中的字段和属性是不同的，比如一个灯泡相关的数据结构可能是{开关状态:”开”},而一个智能电表相关的数据结构可能是{电量:”40”,设备是否异常：”否”}。规则需要适用于各种不同的数据属性，易于配置，并且能够快速匹配运行。
相关技术中公开了一种基于规则引擎的流量采集方法，包括：在网络设备处设置流量采集代理；由流量采集代理通过镜像的方式将流量复制到规则引擎；规则引擎根据自定义规则分析流量并且采集相应流量。规则引擎可以将流量前后进行关联。规则引擎分析流量包括分析与自定义规则相关的以下一个或多个流量特征：访问频率、协议、请求端口、操作命令、http头部信息、get或者post请求、下载或者上传文件的大小。其自定义规则可以由用户通过规则编辑界面输入。规则引擎可以被配置成执行流量的频率统计、端口统计、http请求类型、c段统计、操作命令、协议分析统计、http头部分析匹配等操作。自定义规则可以是一条或多条关联特定流量特征并且指定相应条件的规则，例如：当通过telnet执行get命令时，记录其流量；当上传/下载的文件包含png或者jpeg文件时，记录其流量；当某c段ip访问超过一定频率时，记录其流量三个小时等等。规则引擎可以应用规则例如“当通过telent执行get命令时，记录其流量”，判断当前流量是否通过telent执行get命令，如果是则采集该流量，否则丢弃该流量。规则引擎在执行当前规则后，可以继续应用另一规则。
上述规则引擎存在以下问题：
1、规则存储结构需要数据库的支持，可以运行在服务器端，但设备端(如物联网设置端)运算能力有限，很难将规则的配置、存储和运行移植在设备上。
2规则匹配能力完全依赖数据库，在物联网海量消息情况下规则匹配的效率较低。
3、只能针对简单结构的数据进行处理。如果一个设备采集的数据是复杂结构(如具有多级属性)，实现就很困难。
4、不支持函数，比如不支持这样的规则：当abs(属性1的值)＝1时，执行xxx动作。
技术实现要素：
有鉴于此，本发明提供了一种基于规则的数据处理方法，包括：
规则引擎基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
如果匹配成功，所述规则引擎执行所述规则中定义的目标动作。
有鉴于此，本发明还提供了一种规则引擎装置，包括：
条件匹配模块，设置为：基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
动作执行模块，设置为：如果所述条件匹配模块对接收的数据匹配成功，执行所述规则中定义的目标动作。
有鉴于此，本发明还提供了一种规则引擎装置，包括cpu和存储器，其中：
所述存储器，设置为：保存程序代码；
所述cpu，设置为：读取所述程序代码以执行以下处理：
规则引擎基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
如果匹配成功，所述规则引擎执行所述规则中定义的目标动作。
上述方案使得规则配置变得容易理解、存储简单。
附图说明
图1是本发明实施例一基于规则的数据处理方法的流程图；
图2是本发明实施例一作为示例的基于规则的数据处理方法的示意图；
图3是本发明实施例二规则引擎装置的模块图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
实施例一
本实施例提供一种基于规则的数据处理方法。
本实施例的规则除定义触发条件和目标动作之外，可选地，还定义有数据源和数据构造方式，其中，数据源用于指示数据来源。本实施例中，要处理的数据是消息队列中的消息，数据源用消息队列标识。数据构造方式用于指示需要构造哪些及如何构造要在目标动作中使用的数据。消息队列标识可以用消息队列的主题即topic来表示，消息投递方投递到某个topic后，消息接收方只要订阅了topic都可收到消息。使用数据源时对其他数据来源的数据不做任何处理，可以初步过滤掉大量不需要的数据，提高处理效率。
本实施例的规则在整体上采用json数据结构但不局限于此，json是一种轻量级的数据交换格式，独立于语言，其结构比较简单，方便存储，但本发明可以采用其他数据结构如xml、自定义数据结构等。
本实施例采用json数据结构定义的规则包括规则名称、用于匹配的sql语句及动作列表三个部分，表示如下：
{actionname:’规则名称’
mappingsql:’用于匹配的sql语句’
actions：[动作列表]
}
本实施例中，所述规则定义的触发条件、数据源和数据构造方式均使用文本形式的语句如sql的查询语句，但不局限于此，也可以使用其他文本形式的语句。sql是结构化查询语言(structquerylanguage)，通常用于关系型数据库的查询、更新以及管理数据。
下面用一个示例说明sql查询语句如何表示规则定义的相应内容。
语句：select*,sin(d),deviceid()from‘/123/abc’wherea.b>0
该语句的from部分对应于数据源，where部分对应于触发条件，select部分对应于数据构造方式。其中：
■from部分的‘/123/abc’表示消息队列的topic，也就是说，这条规则针对topic为‘/123/abc’的消息队列，其他消息队列不用匹配。
■where部分的a.b>0表示from部分指示的消息队列有消息来了进行的条件判断，其条件是：属性a下属性b的值大于0。
■select部分的*,sin(d),deviceid()表示where部分的条件匹配成功(即从消息中提取的属性a下属性b的值大于0)后，需要将哪些数据构造出来，这些数据最后可以组装成json格式。在执行目标动作时候使用。就本示例来说，select部分表示的数据构造方式是需要提取设备标识和属性d的值，并且对属性d的值做正弦运算(sin()表示正弦函数)。
本实施例中，规则中的属性使用表达式，可以提取数据的任何字段。比如：如果一个设备采集的数据包含多级属性：
{属性1:值1，
属性2:[{属性3:样本值1},
{属性3:样本值2},
{属性3:样本值3}]，
属性4:{属性5:值}
}，
当规则是“当属性1的值大于xx时，执行xxx动作”，可以使用属性表达式：“属性1>xx”
当规则是“当属性2的中间记录属性3的值大于xx时，执行xxx动作”，可以使用属性表达式：“属性2[1].属性3>xx”。
当规则是“当属性4中的属性5的值大于xx时，执行xxx动作”，可以使用属性表达式：“属性4.属性5>xx”。
具体地，上述select部分和where部分都使用json格式来表示属性值(在其他实施例中也可以采用xml格式、自定义格式等其他格式)。例如，jsonpath(‘a.b’)意味着查找消息内属性a下的属性b的值，也可以支持数组以及通配符，例如jsonpath(‘a[0].b’)表示查找数组a索引为0的记录下属性b的值。如果是通配符可能得到多个结果，会返回一个列表数组值。表示时jsonpath是可选的，比如a.b默认等价于selectjsonpath(‘a.b’)。
目前标准sql的各部分是以一条记录为单位进行处理的，本实施例将其细化到对属性值的处理，这样就不需要将一条记录中的属性值再分拆到多条记录中，提高处理的效果。通过对规则引擎的语法分析器、词法分析器部分的设计，可以使规则引擎支持对于sql语句中属性的解析。
规则中目标动作(动作列表中包括一个或多个目标动作)可以各个业务情况来定义，具体的结构可以自定义也可以采用已有的数据结构。例如，目标动作定义为{type:’rds’,configration:’rds的参数’}，则表示把构造好的数据存储到关系型数据库服务(relationaldatabaseservice，简称rds)的磁盘，configration:’rds的参数表示rds的配置参数。
特别地，本发明的发明人考虑到目标动作有多个时，这些动作之间有些具有依赖关系，有些不具有依赖关系。对于具有依赖关系的动作需要串行执行。而不具有依赖关系的动作可以并行执行。例如，一个目标动作是将构造的数据存储到关系型数据库，另一个目标动作是将构造的数据存储到非关系型数据库，这两个动作是可以并行执行的。又如，一个目标动作是将灯打开，另一个目标动作是记录第一个动作执行后灯的状态并返回。这两个动作就需要串行执行。因此，本实施例在规则定义的目标动作中，还定义了多个目标动作之间的顺序关系，所述顺序关系包括并行执行或者串行执行。定义顺序关系可以保证执行成功，提高执行效率。
如图1所示，本实施例基于规则的数据处理方法包括：
步骤110。规则引擎基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
如前所述，本实施例的规则中还定义有数据源，所述数据源用消息队列标识来表示。所述规则引擎对接收的数据进行匹配时，根据所述规则中的消息队列标识选择相应的消息队列，只对选择的消息队列中的消息进行匹配。也就是说，通过定义数据源，可以对数据进行初步的过滤。
本实施例中，所述规则引擎对接收的数据进行匹配之前，对所述规则进行预编译并建立所述规则与所述消息队列标识的索引关系，将预编译后的规则和所述索引关系保存在缓存中。这样在接收到数据之后，可以利用缓存的索引关系选择相应的消息队列并匹配规则，提高处理的速度和效率。
步骤120，如果匹配成功，所述规则引擎执行所述规则中定义的目标动作。
本实施例中，所述规则中还定义有数据构造方式；在步骤中，如果匹配成功即满足触发条件，所述规则引擎解析所述规则中定义的数据构造方式，根据所述数据构造方式和匹配成功的数据，构造要在目标动作中使用的数据，然后执行所述规则中定义的目标动作，执行时使用所述构造的数据。值得注意的是，本实施例是在触发条件匹配成功之后再解析数据构造方式并构造数据，如果匹配失败并不需要进行这些处理，因而可以节约处理资源。需要说明的是，有些规则的目标动作并不需要使用数据，也就无需定义数据构造方式和进行数据构造的处理。
本实施例中，所述规则中定义的目标动作有多个时，所述规则中还定义了所述多个目标动作之间的顺序关系，所述顺序关系包括并行执行或者串行执行。因此，本步骤所述规则引擎是按照所述规则中定义的目标动作之间的顺序关系，执行所述目标动作。
本实施例中，所述规则引擎装置位于服务器侧时，所述规则引擎可以将在服务器配置的所述规则同步到终端设备去执行。而在终端设备上，也可以安装规则引擎来进行规则的匹配和执行相应的。
下面用一个示例对本实施例方法做进一步的说明，图2是该示例基于规则的数据处理方法的示意图。
如图的所示，用户可以通过服务器侧的规则配置界面定义规则，由规则引擎(图中示出的是服务器侧的规则引擎)保存配置信息，对规则的定义包括定义规则中的sql语句、规则中的触发动作及规则对应的topic。规则配置完成后可以启动规则，此时规则引擎预编译sql，建立起topic到预编译sql的索引并保存到缓存。用户也可以通过服务器侧的规则配置界面对设备侧要匹配和执行的规则进行定义，并由服务器侧规则引擎同步到设备侧(即图中的设备4“网关”)。
规则配置可以使用其它方式，比如drools的规则定义(drools是一种开源业务规则引擎)，但比sql学习成本高，且仅针对java语言。如果使用drools实现，那么规则的解析不能使用sql编译，而是使用drools的规则解析。
本示例中，网关向服务器发送消息到topic的消息队列，规则引擎的工作流程包括：
步骤一，当有消息到达时，规则引擎首先提取消息的topic属性(即所在消息队列的topic)，去缓存查找是否有与该topic匹配(或者说对应)的规则，如果有，执行下一步，否则不对消息进行处理；
步骤二，如果消息内容的字符文本本身是json格式，规则引擎将其直接作为json对象，比如{color:’red’,flags:{‘c’:1.5,’d’:90}}，表示颜色为红色，属性c的值为1.5，属性d的值为90。否则，可将将二进制转换为普通文本并使用统一格式：{data:’这里是解析后的字符串’}；
步骤三，规则引擎使用预编译的sql,这些预编译对象通常是一个词法分析器构造的结果，比如antlr或者javacc的对象，然后判断sql语句where部分定义的触发条件是否满足，和普通sql不一样的是where里面的取值来源是json的表达式，比如whereflags.c>1,按照上述示例，该触发条件成立，返回true；
步骤四，如果where是true的话，规则引擎再解析sql语句select部分的内容，比如selectsin(d),color，表示提取color值和属性d的值，并对d的值做正弦运算，解析后构造json格式的数据：{‘sin(d)’:0.894,color:’red’}，构造的数据将用于后续的action动作列表。
步骤五，执行目标动作。假定定义了两个动作：动作一是将构造的数据存储到数据库；动作二是将构造的数据转发到另外一个设备的队列topic。这两个动作的顺序关系是并行执行，因而会使用线程池并行执行。如果动作列表中的两个动作配置为串行执行，即动作二依赖动作一，则先执行动作一，在确定动作一执行完成后，再执行动作二。
本实施例方案至少具有以下优点：
1、规则采用文本形式的语句表示，取代了编程式的逻辑判断。如可以采用sql表达式：selectfrom“topic”wherecondition，用sql词法执行取代了编程式的逻辑判断。具有以下效果：a)属性过滤可以使用函数，比如当abs(属性1的值)＝1时，执行xxx动作；b)规则存储结构是一个普通的sql，可以放服务器端，也可以存放在物联网设备端，无需数据库的支持，可以通过服务器配置，同步到设备端去运行，使得某些规则在设备端也可以运行，比如“当用户开门了，如果当前亮度不足自动开灯”，这个规则可以在一个网关设备比如家庭局域网内运转。c)sql表达式通俗易懂，学习成本低，扩展性灵活。而且本实施例的sql比传统的语句扩展支持了json表达式。
2、规则中的属性使用表达式，可以提取数据的任何字段。
3、规则匹配能力提升，特别在物联网海量消息情况下使用时规则匹配高效。本实施例在用户配置规则阶段预编译sql到缓存，建立topic到编译后的规则的索引关系，有消息来了后一级过滤topic快速命中，无规则的消息无需解析。然后通过使用sql编译模块的词法分析器快速运行sql的where条件，判断规则是否通过，如果通过再解析select部分构造用于后续动作的数据，每个动作是异步处理的。从本地缓存拿到预编译后的规则执行效率，这个过程没有数据库io操作。
4、一条规则的多个动作配置顺序关系，可以配置为前置依赖即串行执行，也可以配置为并行执行，提升效率，保证执行成功。
实施例二
本实施例提供了一种规则引擎装置，如图3所示，包括：
条件匹配模块10，设置为：基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
动作执行模块20，设置为：如果所述条件匹配模块对接收的数据匹配成功，执行所述规则中定义的目标动作。
本实施例中，
所述规则中还定义有数据构造方式；
所述动作执行模块包括：
数据构造单元，设置为：如果所述条件匹配模块对接收的数据匹配成功，解析所述规则中定义的数据构造方式，根据所述数据构造方式和匹配成功的数据，构造要在目标动作中使用的数据；
动作执行单元，设置为：执行所述规则中定义的目标动作，执行时使用所述构造的数据。
本实施例中，
所述规则中还定义有数据源，所述数据源用消息队列标识来表示；所述接收的数据是存放在消息队列中的消息；
所述条件匹配模块对接收的数据进行匹配，包括：根据所述规则中的消息队列标识选择相应的消息队列，只对选择的消息队列中的消息进行匹配。
本实施例中，
所述条件匹配模块对接收的数据进行匹配之前，还包括：对所述规则进行预编译并建立所述规则与所述消息队列标识的索引关系，将预编译后的规则和所述索引关系保存在缓存中。
本实施例中，
所述规则中定义有触发条件、数据构造方式和数据源，所述触发条件、数据构造方式和数据源使用sql的查询语句来表示；
所述规则整体上采用json格式的数据结构，所述json格式的数据结构包括规则名称、匹配的sql语句及动作列表三个部分。
本实施例中，
所述规则中定义的内容包含属性，所述属性采用json格式来表示。
本实施例中，
所述规则中定义的目标动作有多个时，所述规则中还定义了所述多个目标动作之间的顺序关系，所述顺序关系包括并行执行或者串行执行；
所述动作执行模块执行所述规则中定义的目标动作，包括：按照所述规则中定义的目标动作之间的顺序关系，执行所述目标动作。
本实施例中，
所述规则引擎装置位于服务器侧，所述规则引擎装置还包括：同步模块，设置为：将在服务器配置的所述规则同步到终端设备。
本实施例中的规则的定义可以采用实施例一中的规则的定义。各个模块执行的处理也可以采用实施例一方法中的相应处理。
本实施例还提供了一种规则引擎装置，包括cpu和存储器，其中：
所述存储器，设置为：保存程序代码；
所述cpu，设置为：读取所述程序代码以执行以下处理：
规则引擎基于规则中定义的触发条件对接收的数据进行匹配，所述规则使用文本形式的语句表示；
如果匹配成功，所述规则引擎执行所述规则中定义的目标动作。
上述cpu可以执行实施例一方法中的任何处理，这里不再一一赘述。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。