银行业风险特征快速开发与部署的解决方案--粉丝服务平台-粉丝头条-fensifuwu.com

银行业风险特征快速开发与部署的解决方案

科技 08-25 来源： DataFunTalk

导读：唐庚阳老师来自百信银行大数据部，主要负责信贷领域相关交易场景下的风控特征的加工、部署还有评价的工作。本次分享主要从下面四个部分展开:

踩过的雷：过往特征加工过程中遇到的问题
解决方案1.0：快速解决痛点问题的一套管理方案
解决方案2.0：系统化、体系化管理风险特征全生命周期
能否做得更好：对做到“更高、更快、更强”的一些设想

踩过的雷

1. 早期情况介绍

早期特征加工主要使用Java方式进行定制化开发，随着三方数据种类越来越多，渐渐不能满足这个业务部门对于特征迭代的效率的要求。我们尝试通过Java的算子支持风控系统后台通过函数参数或者维度的形式配置以优化开发效率，这样做开发速度得到了一定的提升，但是整体的上线周期以及上线以后数值获取的一致性还是存在较大问题。后面尝试引入Flink做一些Flink SQL实现变量的加工，但是Flink SQL作为一个流SQL ，它对标准SQL的支持以及其 SQL性质还不是那么的一致。

2. 问题剖析

尝试过程中暴露了一些问题，可以大致分为四类：

上线慢
复用难
无下线
缺监控

前两个问题主要是开发模式导致的，后两个问题则是因为特征管理缺失。

① 上线慢

因为是两套代码，所以在理解和编写的时候，效率比较低。在百信银行业务开展初期，大部分的特征处于冷启动的状态，特征主要来源的方式还是策略或者模型人员的专家经验，通过原有的经验形成一套文字描述为主的特征需求，然后把这个需求交由开发同学在系统当中实现。经过一段时间数据积累，业务人员就可以通过在交易环节中产生的数据，还有一些结构化的数据做一些特征的挖掘。方式还是SQL为主，辅助用一些Python。

从冷启动到热启动方式，不仅仅会产生一些中文描述的需求文档，还会留下特征的一些实现逻辑，但是在上线到线上的时候，特征的加工方式还是以Java为主，因此整个过程会经历比较传统的需求评审、排期、开发、测试、部署这一套标准流程。

在这个过程当中，由于需求方看到的数据大部分是结构化的，故他对在接口之间传输的数据结构并不是那么清晰，加上Java开发人员对特征的理解是有偏差的，因此可能导致开发在看中文文档产生和需求方不同的理解。在开发完毕之后，可能会有一个很漫长的数据核对的过程，导致整个特征上线的流程拉长。

② 复用难

以Java的表达式或者jar包形式的特征上线之后，对于业务人员来说是一个黑盒，会直接导致业务人员在用特征的时候，很难掌握特征内部逻辑，如果再遇上文档管理欠缺，这些算子的函数逻辑可能都需要扒源代码去看，自然而然的就降低了特征的复用性。

③ 无下线

在业务开展初期，特征、相关制度与配套的评估还是较为欠缺、不够完善的。整体业务的节奏还是以快速接入和上线为主，在越来越多的三方特征介入之后，接口、特征、节点还有策略之间的关系网就变得非常复杂了。可能会出现衍生之上再产生衍生，依赖之上再产生依赖，关系错综复杂。特征有效性也需要定期进行复盘，以便特征更好地进行迭代。特征的调用逻辑的复杂以及盘点的缺失，会导致特征再下线的时候问题暴露得特别明显。

④ 缺监控

进行特征复盘的时候，策略和模型人员做了很多机械化、重复性的工作，导致时间成本、人力成本都很高。即便是定位到可以废弃的特征，但在下线的时候，虽然系统提供了检查的方式，但这种检查还是缺乏整体全局的视角，还是可能出现一些人为的操作风险。

解决方案1.0

在解决方案1.0中，思考的是如何在资源有限的前提下解决问题。主要依托现有的系统资源，没有进行新系统开发，解决了特征上线慢和复用难的问题。

资源永远都是有限的，如何满足需求让特征快速地上线，通过迭代的方式，先将重点问题逐个击破。

1. 加快上线速度

① 方案思路

实现离线系统和实时系统规范化：将离线系统和实时系统的数据信息统一，这样可以大大减少上线过程当中时间的损耗。
需求人员和开发人员口径一致：需求方特征和特征开发人员最好能看到的东西是一样的，而不是说需求方看到的是库表，而特征的开发人员看到的是一些接口文档。
特征开发语言的0变化：最大程度上减少特征语言的转化，在特征挖掘过程当中，产生了一些SQL和Python，能否把这些利用的更好，直接部署，使整个上线变得更平滑，减少逻辑的偏差。
核心数据源同源同构的搭建：依托lambada架构，借鉴使用Flink当时的一些数据治理的规范实现了落地。确保了离线环境跟实时环境的库表结构一致、数据类型一致，并且可以做到离线环境的变更到业务系统变更或者源端的变更同步到两个环境当中。可以将特征的逻辑更好地传递给开发人员。

② 前后变化

从整个流程来看方案上线前后变化：

上线前：模型策略人员需要进行数据挖掘探究，需要写新的需求文档，交给技术产品经理，再开需求评审，通过后Java的开发再去理解，然后再去检查现在的这个算子是不是满足，如果满足就做配置，如果不满足可能需要定制化开发，整个流程很漫长，最后还要在上线之后做大量的测试工作。
上线后：实现了同源同步，大家实现统一视图，基本上能无限接近零变化部署业务人员已经挖掘好的特征。

原有的方式整个流程的环节比较多，参与的人员也很多，容易产生理解偏差，导致整个周期较长。所以对业务人员写的SQL或者Python代码进行简单的改造和性能测试，直接进行特征的部署，可以确保特征实现的语言是一致的，并且减少一些测试的工作。由于开发人员在离线环境实现过特征，所以在上线之后获取离线的特征的数值只要能与线上的符合，基本不会存在太多的问题。保持逻辑一致性之后，减少了测试工作量，降低了特征返工的可能性，这个举措在实际应用当中取得了很好的效果——特征上线的周期的频率，能够提升50%左右。

2. 优化需求评估

初步解决了特征上线的问题之后，接下来就是业务人员评估需求，在评估方面主要做了两件事情：

第一个就是把策略调用过的所有的业务数据，进行了智能化的归类，并且全部做了解析并落库，方便策略人员和模型人员直接去取到在线上调过的策略、特征数据。
另一个是将模型跟策略人员常用的对于特征的指标进行自动化的执行，主要是减少模型和策略人员很多重复性、机械性的工作。

3. 优化特征评价

特征的表现分为两类，一种是特征调用情况，另一种就是特征数值情况。

特征调用情况：可以快速定位出哪些特征基本是无用的，比如特征缺失率，如果一个特征的缺失率很高，那么它在后期的使用的可能性就比较低。
从特征自身表现可以看出这个特征的稳定性，对于一个比较稳定且分布正常的特征，可以做进一步的关于y跟y相关联的评估。

做完这两件事之后，从业务反馈上来看，可以帮助他们定位出哪些特征是有价值的，哪些特征是可以下线的，便于他们做特征初步的筛选，反馈较好。

4、1.0任然存在的问题

1.0版本其实是在资源有限的情况下做的，还遗留下来一些问题。

问题主要是在特征整体的管理、加工方式以及性能方面。

举个简单的例子，因为特征是异步加工的，在缺少通知机制的前提下，它在加工和调用过程当中，类似于特征在调用和加工之间在进行赛跑，如果出现调用先到的情况，可能就会出现特征数据不完整的情况。

解决方案2.0

1. 建设特种工厂，完成特种全流程管理

百信银行针对特征的全生命周期管理，形成了从特征的注册、上线、评估再到下线，完整的管理机制。

① 特征注册

命名规范：针对特征注册时的命名规范，设计了一个严格的系统通过对名称进行校验判断是否符合命名规范，不符合命名规范的特征无法正常注册，以此来保证生产环境特征名称遵循规范。
避免特征重复加工：系统会根据特征的中文描述进行一个相似度的判断，如果有相似的特征，系统会推荐给业务人员，减少重复加工的情况。

② 特征下线

特征下线一直是一个令人头疼的问题，下线前的评估不够充分可能会引发严重的生产问题。百信银行在这方面也作了一些工作，主要是做了一个严格的特征审批流程。根据特征的种类、级别、归属情况，做了一个特征下线的审批流程。在特征下线的时候需要所有特征涉及的相关方均收到这个通知，并要求主要负责人对其进行审批。

2. 特种需求统一收口，落地特种管理规范

从制度上和流程上消除特征下线因评估不足导致的风险问题，完成了特征的全流程管理。但是当需求不统一这种情况还存在的话，会出现“一人一把号，各吹各的调”的问题，所以需要特征需求统一收口，规范特征的落地。具体工作主要为把特征的需求制定一个标准的介入流程，形成需求的收口，便于对特征准入精确地把握，也更好地把特征管理办法进行落地。

3. 同步调用改为异步调用，有效应对流量激增

1.0方案还存在特征异步化调用的情况。

① 之前存在的问题

之前特征的获取方式基本上是异步化加工加同步调用，很多场景都是异步化的，即前端或者合作方都是异步的请求，但是特征调用是同步的方式，这样就可能导致前端的异步形同虚设，因为后端在获取特征的时候会存在同步超时的情况，如果一旦超时可能这次特征获取就是失败的，白白浪费了很多流量。

② 解决方案

通过引入用异步化请求和异步化调用的方式去解决这个问题。通过引入特征工厂，将特征获取从原来的同步变成了异步。这样做在系统资源不变的前提下，可以承接特征需求请求的量明显增加。

4. 精细化特征加工与调用流程

将异步化调用改造完之后，还要实现的是精细化的调用，以确保整个调用链路的执行效率是最优的，具体过程如下文所述。

① 存在问题：

从同步改到异步的时候，增加的节点/环节是很明显的。

② 解决思路：

通过引入了一个事件中心和一个调度中心，将异步加工的特征和异步通知进行了关联，即特征是异步加工的，通知也是异步的，所以需要将加工过程与通知过程做好挂钩。

③ 具体过程：

做好特征的挂钩，并且对特征执行要调用最优的路径，减少不必要的调用和加工耗时。整体流程为：

当一个风控请求进来之后，请求特征工厂进行特征获取，请求发到kafka之后，这个交易线程就相当于自己中断或者睡眠了。
它的监听模块就会去特征结果通知的Topic里面去监听，直到整个特征的获取过程或加工过程完成。
这边请求到了特征工厂后，会去调度中心，根据前端的请求在配置中心里边的配置，获取到对应的执行链路以及依赖关系的对应事件，之后事件中心会获取这个事件，等到事件中心将所有的前置准备完成之后，再去完成特征的加工，然后把特征加工的结果放回到对应的topic里边。
最后由上游的风控系统监听这个数据完成之后，再把之前睡眠的线程重启起来，整个交易继续推进。

这个优化对于前端业务来说也有一定的好处，因为线程是一直在等待的，是个异步的过程，这样整个交易当中不会因为变量加工存在抖动或者超时而导致交易丢失，可以从根本上提升整个风控系统的交易吞吐量。

能否做得更好

目前大部分业务问题都找到了有效的解决方案，我们是否能否做的更好？用奥林匹克的精神去阐述就是要做到——更高、更快、更强。

1. 自助式特征开发，进一步降低特征使用门槛

接下来将着力自动化和智能化领域，降低特征获取门槛，优化人力成本消耗。

基于以上想法，将策略、模型工作人员使用SQL编写逻辑的方式优化为参数化配置的方式。
对于这种做法，有些人可能会产生回到原来的模式上的疑问，但是对于模型、策略人员来说，SQL参数化配置的方式相比较于Java表达式、Java源码的可读性得到了提高，这样也可以做到屏蔽业务人员与复杂的后端数据加工方式。
通过合理的数据源适配，确保业务人员在实时环境和离线环境能获得同样的特征结果，哪怕这些特征在交易环境没有调用过。这可以帮助他们更好的去分析特征，提高业务上模型和策略的迭代效率。

2. 自助式特征开发，进一步降低特征使用门槛

接下来期望使用智能化的方式帮助业务人员进行特征的筛选，前面的工作进行了特征的初筛，主要是对于特征的基本表现进行筛选，后面设想将这个评价过程做成自动化的，由于很多特征评估体系是相通的，这样可以减少业务人员机械重复的工作。

具体来说，接下来计划做这些事情：在交易过程当中产生了很多样本y，通过配置加定时的方式，可以生成不同的相当于y的样本包，对于样本包会有文字描述或者其他描述，通过基本特征信息，做一些基本衍生特征加工，例如缺失率等，之后通过模型训练，利用特征的表现使用模型（例如 XGBOOST）做重要性筛选，然后再将这个特征的IV值、KSI值、相关系数做一个输出，再将这些输出的结果做可视化的选型。最后，模型人员在平台上就可以直接基于样本包得到特征的一些表现，这样做可以释放更多的人力，加快模型和策略的迭代效率。

3. 整体规划应用