一个规则引擎的可视化方案

Posted IT职场笔记

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一个规则引擎的可视化方案相关的知识，希望对你有一定的参考价值。

背景

最近有个新项目可能会用到规则引擎，所以花了些时间对相关技术做调研，在百度、google用“规则引擎”作为关键字进行搜索，可以找到很多关于这方面的资料，绝大部分都会提到 drools、urules、easy-rules等等这么些开源项目，有一些文章也提到他们是采用groovy脚本来实现的。通过对项目需求的评估，初步判定groovy脚本已经可以满足实际的场景。

然而，在这些资料或者方案之中，除了urules，大部分只是关注框架的性能和使用上的简便，很少探讨如何让业务人员可以自行进行规则定义的方案。而urules虽然自带了可视化的规则管理界面，但是界面样式不好自定义，无法跟现有后台管理界面不突兀的融合。

通过不断尝试变换关键字在搜索引擎搜索，最终在stackoverflow找到了一个探讨这个问题的帖子，特此将帖子中提到的方案分享一下，如果你跟我一样在研究同样的问题，也许对你有用。不过在介绍这个方案之前，得先简单了解一下什么是规则引擎

什么是规则引擎？

简单的说，规则引擎所负责的事情就是：判定某个数据或者对象是否满足某个条件，然后根据判定结果，执行不同的动作。例如：

对于刚刚在网站上完成购物的一个用户（对象），如果她是 "女性用户 并且 （连续登录天数大于10天 或者 订单金额大于200元 )" (条件) , 那么系统就自动给该用户发放一张优惠券（动作）。

在上面的场景中，规则引擎最重要的一个优势就是实现“条件“表达式的配置化。如果条件表达式不能配置，那么就需要程序员在代码里面写死各种if...else... ，如果条件组合特别复杂的话，代码就会很难维护；同时，如果不能配置化，那么每次条件的细微变更，就需要修改代码，然后通过运维走发布流程，无法快速响应业务的需求。

在groovy脚本的方案中，上面的场景可以这么实现：

  • 1）定义一个groovy脚本：

def validateCondition(args)return args.用户性别 == "女性" && (args.连续登录天数>10 || args.订单金额 > 200);

  • 2）通过Java提供的 ScriptEngineManager 对象去执行

    <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy</artifactId>
      <version>3.0.7</version>
    </dependency>
/*
 *
 * @params condition  从数据库中读出来的条件表达式
 */
private Boolean validateCondition(String condition)
    //实际使用上，ScriptEngineManager可以定义为单例
    ScriptEngineManager engineManager = new ScriptEngineManager();
    ScriptEngine engine = engineManager.getEngineByName(scriptLang);
    Map<String, Object> args = new HashMap<>();
    data.put("用户性别", "女性");
    data.put("连续登录天数", 11);
    data.put("订单金额", 220);
    engine.eval(script);
    return ((Invocable) engine).invokeFunction(functionName, args);

在上面的groovy脚本中，经常需要变动的部分就是 ”args.用户性别 == "女性" && (args.连续登录天数>10 || args.订单金额 > 200)“ 这个表达式，一个最简单的方案，就是在后台界面提供一个文本框，在文本框中录入整个groovy脚本，然后保存到数据库。但是这种方案有个缺点：表达式的定义有一定门槛。对于程序员来说，这自然是很简单的事，但是对于没接触过编程的业务人员，就有一定的门槛了，很容易录入错误的表达式。这就引出了本文的另一个话题，如何实现bool表达式的可视化编辑？

如何实现bool表达式的可视化编辑？

一种方案就是对于一个指定的表达式，前端人员进行语法解析，然后渲染成界面，业务人员编辑之后，再将界面元素结构转换成表达式。然而，直接解析语法有两个确定：

  • 1）需要考虑的边界条件比较多，一不小心就解析出错。

  • 2）而且也限定了后端可以选用的脚本语言。例如，在上面的方案中选用的是groovy，它使用的"与"运算符是 && , 假如某天有一种性能更好的脚本语言，它的"与"运算符定位为 and ，那么就会需要修改很多表达式解析的地方。

另一种方案，是定义一个数据结构来描述表达式的结构(说了这么多，终于来到重点了)：

     "all": [
         "any": [
             "gl": ["连续登录天数", 10] ,
             "gl": ["订单金额", 200] 
        ],
         "eq": ["用户性别", "女性"] 
    ]

然后，使用递归的方式解析该结构，对于前端开发，可以在递归解析的过程中渲染成对应的界面元素；对于后端人员，可以生成对应的bool表达式，有了bool表达式，就可以使用预定的脚本模板，生成最终的规则。

// 模板的例子
def validateCondition(args)return $s;
/**
 * 动态bool表达式解析器
 */
public class RuleParser 
    private static final Map<String, String> operatorMap = new HashMap<>();
    private static final ObjectMapper objectMapper = new ObjectMapper();

    static 
        operatorMap.put("all", "&&");
        operatorMap.put("any", "||");
        operatorMap.put("ge", ">=");
        operatorMap.put("gt", ">");
        operatorMap.put("eq", "==");
        operatorMap.put("ne", "!=");
        operatorMap.put("le", "<=");
        operatorMap.put("lt", "<");
    

    /**
     * 解析规则字符串，转换成表达式形式
     * 示例:
     * 输入：
     *     "any": [
     *         "all": [
     *             "ge": ["A", 10] ,
     *             "eq": ["B", 20] 
     *        ],
     *         "lt": ["C", 30] ,
     *         "ne": ["D", 50] 
     *    ]
     *
     * 输出：
     *    ( A >= 10 && B == 20 ) || ( C < 30 ) || ( D != 50 )
     * @param rule 规则的json字符串形式
     * @return 返回 bool 表达式
     * @throws IOException 解析json字符串异常
     */
    public static String parse(String rule) throws IOException 

        JsonNode jsonNode = objectMapper.readTree(rule);
        return parse(jsonNode);
    

    /**
     * 解析规则节点，转换成表达式形式
     * @param node Jackson Node
     * @return 返回bool表达式
     */
    private static String parse(JsonNode node) 
        // TODO: 支持变量的 ”arg.“ 前缀定义
        if (node.isObject()) 
            Iterator<Map.Entry<String, JsonNode>> it = node.fields();
            if(it.hasNext())
                Map.Entry<String, JsonNode> entry = it.next();
                List<String> arrayList = new ArrayList<>();
                for (JsonNode jsonNode : entry.getValue()) 
                    arrayList.add(parse(jsonNode));
                

                return "(" + String.join(" " + operatorMap.get(entry.getKey()) + " ", arrayList) + ")";
             else 
                // 兼容空节点：例如 "all": [, "eq":"A","1"]
                return " 1==1";
            
         else if (node.isValueNode()) 
            return node.asText();
        

        return "";
    

 

Flink/CEP/规则引擎/风控

 

 

 

 

基于 Apache Flink 和规则引擎的实时风控解决方案 ?

对一个互联网产品来说，典型的风控场景包括：注册风控、登陆风控、交易风控、活动风控等，而风控的最佳效果是防患于未然，所以事前事中和事后三种实现方案中，又以事前预警和事中控制最好。这要求风控系统一定要有实时性。本文就介绍一种实时风控解决方案。风控是业务场景的产物，风控系统直接服务于业务系统，与之相关的还有惩罚系统和分析系统，各系统关系与角色如下：

 

技术图片

 

业务系统，通常是 APP + 后台 或者 web，是互联网业务的载体，风险从业务系统触发；

  • 风控系统，为业务系统提供支持，根据业务系统传来的数据或埋点信息来判断当前用户或事件有无风险；
  • 惩罚系统，业务系统根据风控系统的结果来调用，对有风险的用户或事件进行控制或惩罚，比如增加验证码、限制登陆、禁止下单等等；
  • 分析系统，该系统用以支持风控系统，根据数据来衡量风控系统的表现，比如某策略拦截率突然降低，那可能意味着该策略已经失效，又比如活动商品被抢完的时间突然变短，这表明总体活动策略可能有问题等等，该系统也应支持运营/分析人员发现新策略；

其中风控系统和分析系统是本文讨论的重点，而为了方便讨论，我们假设业务场景如下：

 

风控系统有规则和模型两种技术路线，规则的优点是简单直观、可解释性强、灵活，所以长期活跃在风控系统之中，但缺点是容易被攻破，一但被黑产猜中就会失效，于是在实际的风控系统中，往往需要再结合上基于模型的风控环节来增加健壮性。但限于篇幅，本文中我们只重点讨论一种基于规则的风控系统架构，当然如果有模型风控的诉求，该架构也完全支持。规则就是针对事物的条件判断，我们针对注册、登陆、交易、活动分别假设几条规则，比如：

  • 某 IP 最近 1 小时注册账号数超过 10 个；
  • 某账号群体最近 1 小时购买优惠商品超过 100 件；

规则可以组合成规则组，为了简单起见，我们这里只讨论规则。

  • 事实，即被判断的主体和属性，如上面规则的账号及登陆次数、IP 和注册次数等；
  • 指标阈值，判断的依据，比如登陆次数的临界阈值，注册账号数的临界阈值等；

规则可由运营专家凭经验填写，也可由数据分析师根据历史数据发掘，但因为规则在与黑产的攻防之中会被猜中导致失效，所以无一例外都需要动态调整。技术图片

 

  • 实时风控数据流，由红线标识，同步调用，为风控调用的核心链路；
  • 准实时指标数据流，由蓝线标识，异步写入，为实时风控部分准备指标数据；
  • 准实时/离线分析数据流，由绿线标识，异步写入，为风控系统的表现分析提供数据；

实时风控是整个系统的核心，被业务系统同步调用，完成对应的风控判断。前面提到规则往往由人编写并且需要动态调整，所以我们会把风控判断部分与规则管理部分拆开。规则管理后台为运营服务，由运营人员去进行相关操作：

  • 场景管理，决定某个场景是否实施风控，比如活动场景，在活动结束后可以关闭该场景；
  • 黑白名单，人工/程序找到系统的黑白名单，直接过滤；
  • 规则管理，管理规则，包括增删或修改，比如登陆新增 IP 地址判断，比如下单新增频率校验等；
  • 阈值管理，管理指标的阈值，比如规则为某 IP 最近 1 小时注册账号数不能超过 10 个，那 1 和 10 都属于阈值；

讲完管理后台，那规则判断部分的逻辑也就十分清晰了，分别包括前置过滤、事实数据准备、规则判断三个环节。

2.1.1 前置过滤

 

业务系统在特定事件（如注册、登陆、下单、参加活动等）被触发后同步调用风控系统，附带相关上下文，比如 IP 地址，事件标识等，规则判断部分会根据管理后台的配置决定是否进行判断，如果是，接着进行黑白名单过滤，都通过后进入下一个环节。

2.1.2 实时数据准备

 

在进行判断之前，系统必须要准备一些事实数据，比如：

  • 注册场景，假如规则为单一 IP 最近 1 小时注册账号数不超过 10 个，那系统需要根据 IP 地址去 Redis/Hbase 找到该 IP 最近 1 小时注册账号的数目，比如 15；
  • 登陆场景，假如规则为单一账号最近 3 分钟登陆次数不超过 5 次，那系统需要根据账号去 Redis/Hbase 找到该账号最近 3 分钟登陆的次数，比如 8；

Redis/Hbase 的数据产出我们会在第 2.2 节准实时数据流中进行介绍。

2.2.3 规则判断

 

在得到事实数据之后，系统会根据规则和阈值进行判断，然后返回结果，整个过程便结束了。整个过程逻辑上是清晰的，我们常说的规则引擎主要在这部分起作用，一般来说这个过程有两种实现方式：

  • 借助成熟的规则引擎，比如 Drools，Drools 和 Java 环境结合的非常好，本身也非常完善，支持很多特性，不过使用比较繁琐，有较高门槛，可参考文章【1】；
  • 基于 Groovy 等动态语言自己完成，这里不做赘述。可参考文章【2】；

这部分属于后台逻辑，为风控系统服务，准备事实数据。把数据准备与逻辑判断拆分，是出于系统的性能/可扩展性的角度考虑的。前边提到，做规则判断需要事实的相关指标，比如最近一小时登陆次数，最近一小时注册账号数等等，这些指标通常有一段时间跨度，是某种状态或聚合，很难在实时风控过程中根据原始数据进行计算，因为风控的规则引擎往往是无状态的，不会记录前面的结果。同时，这部分原始数据量很大，因为用户活动的原始数据都要传过来进行计算，所以这部分往往由一个流式大数据系统来完成。在这里我们选择 Flink，Flink 是当今流计算领域无可争议的 No.1，不管是性能还是功能，都能很好的完成这部分工作。

  • 业务系统把埋点数据发送到 Kafka；

  • Flink 订阅 Kafka，完成原子粒度的聚合；

注：Flink 仅完成原子粒度的聚合是和规则的动态变更逻辑相关的。举例来说，在注册场景中，运营同学会根据效果一会要判断某 IP 最近 1 小时的注册账号数，一会要判断最近 3 小时的注册账号数，一会又要判断最近 5 小时的注册账号数……也就是说这个最近 N 小时的 N 是动态调整的。那 Flink 在计算时只应该计算 1 小时的账号数，在判断过程中根据规则来读取最近 3 个 1 小时还是 5 个 1 小时，然后聚合后进行判断。因为在 Flink 的运行机制中，作业提交后会持续运行，如果调整逻辑需要停止作业，修改代码，然后重启，相当麻烦；同时因为 Flink 中间状态的问题，重启还面临着中间状态能否复用的问题。所以假如直接由 Flink 完成 N 小时的聚合的话，每次 N 的变动都需要重复上面的操作，有时还需要追数据，非常繁琐。

  • Flink 把汇总的指标结果写入 Redis 或 Hbase，供实时风控系统查询。两者问题都不大，根据场景选择即可。

通过把数据计算和逻辑判断拆分开来并引入 Flink，我们的风控系统可以应对极大的用户规模。前面的东西静态来看是一个完整的风控系统，但动态来看就有缺失了，这种缺失不体现在功能性上，而是体现在演进上。即如果从动态的角度来看一个风控系统的话，我们至少还需要两部分，一是衡量系统的整体效果，一是为系统提供规则/逻辑升级的依据。

  • 判断规则是否多余，比如某规则从来没拦截过任何事件；
  • 判断规则是否有漏洞，比如在举办某个促销活动或发放代金券后，福利被领完了，但没有达到预期效果；
  • 发现全局规则，比如某人在电子产品的花费突然增长了 100 倍，单独来看是有问题的，但整体来看，可能很多人都出现了这个现象，原来是苹果发新品了……
  • 识别某种行为的组合，单次行为是正常的，但组合是异常的，比如用户买菜刀是正常的，买车票是正常的，买绳子也是正常的，去加油站加油也是正常的，但短时间内同时做这些事情就不是正常的。
  • 群体识别，比如通过图分析技术，发现某个群体，然后给给这个群体的所有账号都打上群体标签，防止出现那种每个账号表现都正常，但整个群体却在集中薅羊毛的情况。

这便是分析系统的角色定位，在他的工作中有部分是确定性的，也有部分是探索性的，为了完成这种工作，该系统需要尽可能多的数据支持，如：

  • 业务系统的数据，业务的埋点数据，记录详细的用户、交易或活动数据；
  • 风控拦截数据，风控系统的埋点数据，比如某个用户在具有某些特征的状态下因为某条规则而被拦截，这条拦截本身就是一个事件数据；

这是一个典型的大数据分析场景，架构也比较灵活，我仅仅给出一种建议的方式。技术图片

 

相对来说这个系统是最开放的，既有固定的指标分析，也可以使用机器学习/数据分析技术发现更多新的规则或模式，限于篇幅，这里就不详细展开了。http://archive.keyllo.com/L-编程/drools-从Drools规则引擎到风控反洗钱系统v0.3.2.pdfhttps://www.jianshu.com/p/d6f45f91bedehttps://jinfei21.github.io/2018/09/29/基于规则的风控系统/https://sq.163yun.com/blog/article/183314611296591872https://sq.163yun.com/blog/article/213006222321659904https://github.com/sunpeak/riskcontrol

 

 

Apache Flink 及大数据领域盛会 Flink Forward Asia 2019 将于 11月28-30日在北京国家会议中心举办，大会议程已上线，点击「阅读原文」可了解大会议程详情。

 

技术图片（点击图片可查看 Flink Forward Asia 2019 详情）

 

 

 

 

从滴滴的Flink CEP引擎说起

技术图片

CEP业务场景

复杂事件处理（Complex Event Process，简称CEP）用来检测无尽数据流中的复杂模 式，拥有从不同的数据行中辨识查找模式的能力。模式匹配是复杂事件处理的一个强 大援助。 例子包括受一系列事件驱动的各种业务流程，例如在安全应用中侦测异常行为；在金 融应用中查找价格、交易量和其他行为的模式。其他常见的用途如欺诈检测应用和传 感器数据的分析等。

说了这么多可能还是觉得比较抽象，那么我们可以看看这次滴滴分享的FlinkCEP在滴滴中的业务场景。

技术图片技术图片技术图片

 

吐槽时刻：

虽然，业务场景ppt写的很好，但是最近几次顺风车事故，给大家留下了糟糕的印象。大数据没用起来，cep其实应该也可以用在顺风车安全检测上吧。

Flink CEP

Flink的CEP是基于Flink Runtime构建的实时数据规则引擎，擅长解决跨事件的匹配问题。
可以看看，滴滴的屁屁踢上给出的两个demo

技术图片技术图片

Flink CEP的特点

技术图片技术图片

 

动态规则

其实，对于实时领域的规则引擎，我们不想每次修改都要打包编码，只希望简单修改一下规则就让它能执行。

当然，最好规则是sql 的形式，运营人员直接参与规则编写而不是频繁提需求，很麻烦。。。。此处，省略万字。。

要知道flink CEP官网给出的API也还是很丰富的，虽然滴滴这比也给出了他们完善的内容。

 

技术图片技术图片

flink官方的CEP文章，浪尖及浪尖组织的flink小团队，已经翻译过了。链接如下：

https://github.com/crestofwave1/oneFlink/blob/master/doc/CEP/FlinkCEPOfficeWeb.md

那么，为了实现动态规则编写，滴滴的架构如下：

技术图片

具体的规则实现如下：

技术图片

可以看到，其规则还是要编码成java代码，然后再用groovy动态编译解析，不知道效率如何。。。

对于规则引擎，当然很多人想到的是drools，这个跟flink结合也很简单，但是效率不怎么苟同。

Flink CEP的SQL实现

熟悉flink的小伙伴肯定都知道Flink的SQL引擎是基于Calcite来实现的。那么细心的小伙伴，在calcite官网可以发现，calcite有个关键字MATCH_RECOGNIZE。可以在这个网页搜索，找到MATCH_RECOGNIZE关键字使用。

http://calcite.apache.org/docs/reference.html

技术图片

那么这时候可能会兴冲冲写个demo。

final String sql = "select frequency,word,timestamp1 "
    + "  from wc match_recognize "
    + "  ("
    + "       order by  timestamp1 "
    + "       measures A.timestamp1 as timestamp1  ,"
    + "       A.word as  word ,"
    + "       A.frequency as  frequency "
    + "       ONE ROW PER MATCH "
    + "    pattern (A B) "
    + "    within interval ‘5‘ second "
    + "    define "
    + "      A AS A.word = ‘bob‘ , "
    + "      B AS B.word = ‘kaka‘ "
    + "  ) mr";

很扫兴的它报错了：

技术图片

 

那么问题来了，calcite支持而flink不支持，为啥？

赶紧发了个issue，然后迅速得到官方回复：

 

技术图片

 

 

但是，翻翻阿里的blink使用手册和华为的flink使用手册发现两者都支持。

好吧。其实，很不服气，周末，除了健身就是加班。

波折一番，解决了，需要修改flink-table相关的内容，执行计划，coden等。

最终，实现了。

技术图片

 

 

 

 

以上是关于一个规则引擎的可视化方案的主要内容，如果未能解决你的问题，请参考以下文章

java规则引擎---Jess

drools开源规则引擎比较难上手，有没有一款容易上手的规则引擎？

Spring Boot + URule 规则引擎，可视化配置太爽了！

java 使用规则引擎drools 出现异常

什么时候使用规则引擎drools

低代码/零代码平台表单引擎技术方案