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

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

---

背景

一天，小明在风控管理台查看事件数据时，发现一笔决策结果为“拒绝”❌的交易事件，小明点开事件详情发现其触发了一条“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工作区。

写在最后

拙作艰辛，字句心血，望诸君垂青，多予支持，不胜感激。

---

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview