风控系统之事件溯源，决策流程记录与版本控制

发表于 2024-08-28 更新于 2024-08-29 阅读次数：本文字数： 1.7k 阅读时长 ≈ 6 分钟

个人语雀：wnhyang

背景

一天，小明在风控管理台查看事件数据时，发现一笔决策结果为“拒绝”❌的交易事件，小明点开事件详情发现其触发了一条“24小时内向不同陌生账户转账超过30w”的规则，规则设置的处置方式是“拒绝”❌。小明通过策略规则却查不到那条“24小时内向不同陌生账户转账超过30w”的规则，经确认原来是这条规则在此交易触发后一段时间内被修改了，已经不知道当时是如何配置的！？

这该怎么办？

我们要知道风控等其他系统都需要对于配置实时生效，所以使用了规则引擎，规则引擎具有实时生效优雅热刷新的特性，但也因此，如果规则设置有问题而没有回滚/溯源/复现的机制，将是很大的问题！！！

所以本质上就是要在规则引擎应用之上打造完善的版本控制，能够对规则历史进行溯源。

事件记录

之前的文章风控系统建设，指标策略规则流程设计，LiteFlow隐式子流程，构造EL和Chain，提到了最终存储在es中大概有哪些数据。以下仅供参考，有部分还没做。

这里再次梳理一下：

1、基础数据，保留所有事件字段。

2、事件处理流程，也就是输入的数据经历了哪些流程和组件处理！

3、策略集结果，包括策略集、策略、规则的所有决策结果。还要加上特殊配置的策略执行流程。

4、指标数据，本次事件计算的所有指标数据。

{
  "result": {
    "name": "手机登录策略",
    "code": "phone_login",
    "disposalName": "通过",
    "disposalCode": "pass",
    "policyResults": [
      {
        "name": "手机登录最坏",
        "code": "phone_login_worst",
        "mode": "worst",
        "disposalName": "通过",
        "disposalCode": "pass",
        "ruleResults": [
          {
            "name": "测试规则03",
            "code": "352452",
            "disposalName": "通过",
            "disposalCode": "pass",
            "score": 0
          }
        ],
        "mockRuleResults": [

        ]
      },
      {
        "name": "手机登录顺序",
        "code": "phone_login_order",
        "mode": "order",
        "disposalName": "通过",
        "disposalCode": "pass",
        "ruleResults": [

        ],
        "mockRuleResults": [

        ]
      }
    ]
  },
  "zbs": [{"id":"1","name":"24小时交易金额之和","type":"sum","version":0,"value":"1413.07938"},{"id":"3","name":"选必于","type":"sum","version":0,"value":"436864.3324399999"},{"id":"4","name":"24小时交易金额大于10万求和","type":"sum","version":0,"value":"1413.07938"},{"id":"5","name":"规支才公照还","type":"ass","version":0,"value":"1.0"},{"id":"6","name":"且者矿","type":"max","version":0,"value":"988.56238"},{"id":"7","name":"北在文地","type":"min","version":0,"value":"424.517"},{"id":"8","name":"看活历地许","type":"avg","version":0,"value":"706.53969"},{"id":"9","name":"情性特问写养八","type":"sum","version":0,"value":"1413.07938"},{"id":"10","name":"其断子把酸","type":"count","version":0,"value":"2.0"}],
  "fields": {
    "N_S_ipCity": "南昌市",
    "N_S_lonAndLat": "98.63974,12.4825",
    "N_S_payerType": "关在那边员",
    "N_S_idCardCity": "未知",
    "N_S_payeeIDNumber": "640000198102131788",
    "N_S_ipProvince": "江西省",
    "N_S_payeeIDCountryRegion": "US",
    "N_F_transAmount": 424.517,
    "N_S_payerAddress": "其它区 山西省 承德市",
    "N_S_seqId": "c678bfbfb4c544eaaeb52373702a0aca",
    "N_S_payeePhoneNumber": "18643006812",
    "N_S_transSerialNo": "809bbad3-1c81-4b59-9e42-fa0b028d1448",
    "N_S_payerAccount": "1234567890",
    "N_S_payeeAccount": "1234567880",
    "N_S_ip": "106.230.80.158",
    "N_S_policyCode": "phone_login_worst",
    "N_S_payeeType": "济常准属适",
    "N_S_payerIDNumber": "420000199805245558",
    "N_S_payeeBankName": "ABC Bank",
    "N_S_phoneNumberProvince": "未知",
    "N_S_ipIsp": "电信",
    "N_S_payerIDCountryRegion": "US",
    "N_D_transTime": "2013-06-21 16:30:09",
    "N_S_phoneNumberCity": "成都",
    "N_S_phoneNumberIsp": "中国电信",
    "N_S_payeeAddress": "- 福建省 抚州市",
    "N_S_payeeRiskRating": "HIGH",
    "N_S_policySetCode": "phone_login",
    "N_S_payerBankName": "XYZ Bank",
    "N_S_idCardDistrict": "未知",
    "N_S_appName": "phone",
    "N_S_idCardProvince": "湖北省",
    "N_S_ipCountry": "中国",
    "N_S_payeeName": "范明",
    "N_S_payerName": "石娜",
    "N_S_payerPhoneNumber": "18123341918",
    "N_S_payerRiskRating": "HIGH"
  }
}

以下仅是示例，表示一笔事件要记录当时处理流程，示例是线性简单的流程，但实际上怎么样，不知道呢🤷

这样每次事件都具备了溯源的基础了，相当于对于当时场景拍了照片（快照嘛）。但是有了照片怎么找到照片里的人呢？🥺

请安心，随着时间的变化，照片里人早已变了模样，只能试着找找喽。

版本控制

这就要提到一种主表+历史表（或者讲快照表）的设计，这种设计特别适用于需要跟踪数据变更的场景。

1. 主表 (Master Table)

主表存储的是最新的、有效的数据记录。通常情况下，主表中会包含业务关键字段以及一些基本的元数据信息（如创建时间、最后修改时间等）。

示例字段：

id：唯一标识
name：名称
status：状态
created_at：创建时间
updated_at：更新时间

2. 历史表 (History Table)

历史表则用来保存所有历史版本的数据记录。每当主表中的数据发生变化时，旧的数据会被复制到历史表中，以便长期保存。

示例字段：

id：唯一标识
master_id：与主表中的ID对应
name：名称
status：状态
version：版本号
changed_by：变更操作者
created_at：创建时间
updated_at：更新时间

上面是大致的思路，具体怎么实现还是取决于具体的业务场景。

在使用LiteFlow的情况下版本控制又要复杂一些，这里仅提供思路。

关于风控系统中变化最多的规则配置，先来评估一下数据量。已知策略集-策略-规则，策略集对策略是1-n，策略对规则也是1-n，那么对应数据是\[n^{2}\]。如果n是100（100条规则也不是很夸张🙂‍↕️)，那么一个版本的规则库就有1w条数据，任意修改变更一次，一年变化100次也不多对吧🙄，那么历史表就要再✖️100，也就是100w，好像有点难顶了！

怎么办呢？

不想数据行过多的话就降维打击吧🤔

主表可以设置为`1-n-\[n^{2}\]，但历史表可以简化一下，降一个纬度。

history历史表可以设置字段：

id：主键
policy_set_id：策略集id
policy_set_name：策略集名
policy_id：策略id
policy_name：策略名
version：版本号
changed_by：变更操作者
created_at：创建时间
updated_at：更新时间

具体的策略对应的信息进行垂直拆分，

history_ext历史扩展表设置字段：

id：与历史表一致
policy_info：策略信息json字符串
rule_info：规则信息json字符串
等

这样的话其实就是将策略-规则通过json串压缩在一张表里了，不再是1-n了。

这样的还有一点注意，status如何定义。

如果主表表示最新数据，那么主表就是运行区，status应该是表示开关等，只有大的修改后才会进入历史表，历史表最新版本数据不包含主表数据，。
如果历史表最新版本表示最新数据，那么历史表status就有history和online之分，主表就表示工作区，状态是等待提交、已提交，类似于git工作区。