风控变量加工硬编码写sql_风控系统核心构成-变量中心

变量中心

如果说数据是原料，策略是产品的话，那么变量就是当中的零部件了。一个完整的风控策略依赖的关键变量可能有几百上千个，底层的变量池子就远远大于这个数了。

变量中心在风控平台中是最重要但是同时也最容易被人忽视的一部分，一方面不像审批系统、决策引擎那样是完整的产品平台，也不像底层数据平台那么有完整的技术方案。变量在不同公司体系里面，形态有很多，可以是一个接口，也可以是一段SQL。

由于变量需求数量多，同时迭代也迅速，变量开发一直技术同学头疼的地方，也是业务同学抱怨的点，成为了矛盾焦点。为了解决这个问题，有一种思路可以解决，让业务人员直接进行变量编制，不需要技术同学在中间进行中转，把离线SQL变成线上执行语句（java代码）。有点类似于，可视化平台中的敏捷拖拽olap和可视的ETL，把数据调度分析放在业务手中，使得报表更加敏捷。

为了使得业务能够主导变量开发，常见的有几种思路：

1. web端设计可交互的变量配置页面，完全使用页面交互实现：常见于支付领域反欺诈策略，可依托于流试计算；产品说明可见 Datavisor的方案。
2. Notebook online形式：将离线数据和线上数据进行打通，直接使用SQL语句来进行计算

本文介绍的主要是第二种方案

自助式变量平台

自助式变量平台的示例如下：

变量自助加工https://www.zhihu.com/video/1188443074282557440

变量自助加工流程：

1. 定义变量基础要素：变量code，名称，类型，默认值，变量描述
2. 加入变量加工逻辑，使用SQL基础语法，引入衍生功能（自定义函数），动态传参变量
3. 变量执行测试：模拟入参进行变量执行调用

平台设计的逻辑在于：沿用策略分析师惯用的查询语法（sql），添加包含特定加工逻辑的自定义函数，来执行实时的变量计算和资源调用（三方接口调用，中间表执行链路）。

变量中心架构

其中核心的功能模块有如下五个：

1. 代码编辑器：前端功能，方便代码维护和编写；常见功能有如输入联想，联想包括 SQL既有语法，自定义函数以及扩展的动态入参
2. 执行编译器：对代码进行解析，还原具体的代码执行链路
3. 数据计算实体：计算对象以表的形式展现，实质上背后可能是实体表（数据库中真实存在的表），也可能是虚拟表（可能是中间表，需要执行的时候进行创建和计算；也可能是三方征信源数据，需要查询外部接口，返回数据之后再返回）
4. 执行调度中心：还原出从主干到各个叶子节点的链路，根据链路去执行计算，最底层永远是原始表或者是三方查询接口服务
5. 底层数据资产：底层数据资产依赖于数据服务中的数据整合，数据首先要汇总在同一个服务中，才能支持上层的关联计算

执行编译器：如下

除了核心执行功能外，变量中心还需要一套完整的管理服务：

1. 测试流程：除了自助开发之外，变量的测试也可以引入业务人员自测的模式，通过执行指定订单的计算调用，来比对加工变量结果和离线测试结果之间的差异，来完成测试上线
2. 版本管理：一个变量会存在多个状态以及多个版本，有草稿状态也有线上的正式版本，以及历史发布的版本。版本管理主要控制变量的生命周期
3. 运营维护：变量计算的性能和效能，性能监控主要是做变量计算时效的分析，定位耗时长的变量做优化。效能分析主要是分析变量的使用率以及效果，积累变量研发经验