这是系列文章解密姨搜的第一篇,主要包括对于风控系统的理解,用户的多种需求,以及架构的总体设计。 看完本篇之后,大家会对信贷场景下的风控系统有更深的认识,知道姨搜作为一个基于数据的风控基础设施,给风控带来了什么样的好处。 希望能给大家一些有益的启发。

信贷场景下的风控

一个信贷产品大体上有如下的部分组成:

信贷产品结构图

在上图中,越靠近上部,越偏产品的自身逻辑, 越靠近下部,越偏技术和实施。 这里面,风控属于核心的地位,它保证了这个产品核心资产的质量。 但它不是独立存在的,产品设计和营销决定了进来的人群,而这些人群决定了用什么样的风控策略。 风控的结果需要跟客户进行沟通和交流,对于逾期等的客户需要有催收等服务。 风险策略主要来包括一个或者一系列预测模型,建模的依据来自数据分析,建模之后还需要不间断的监控,以期在出现问题是能及时发现。 这些分析、模型运行和监控等,都需要有完整的数据系统来进行支持,而数据系统中的数据来自各种不同的数据源。

熟悉数据分析和挖掘的朋友们知道,原始数据的质量很大程度上决定了特征变量的质量,而特征变量的质量决定了模型的准确度以及整个系统的质量。 在信贷场景下,数据的特性有一些独特的地方。比如,数据的来源和形式种类繁多,很难结合使用。例如,通话详单是需要和银行卡流水一起用,但通话详单是通过运营商的API调用获得的json数据,而银行卡流水是爬虫授权后抓取下来的XML数据,如何能放到一起做分析,是很困难的。又例如,宜信作为一个很大的公司,内部有很多的信贷产品,这些产品都有各自的特点,如何让数据系统足够灵活满足各种需求,也不容易做到。

用户的需求点

风控政策人员

他们一般有如下的特点:

  1. 对金融市场的风险有丰富经验。
  2. 有一定统计分析的背景,复杂算法的能力不足。
  3. 对负责的产品理解深刻,但对其他产品认识有限。

相对应的有如下的需求:

  1. 灵活方便的控制风控政策的执行。这一点对于政策人员很重要,首先他们可以自主的控制风控政策的创建、修改、上线和下线等,这样能不再麻烦开发人员就可以自助的完成各种操作。再次,能做到风控政策对于无关人员的隔离,开发人员能看到的也只是一个政策的结果,而无法知道内部的原理。
  2. 执行历史的BI报表和报警机制。有了这些报表才能第一时间发现问题(例如某个规则的通过率异常升高或者降低),并有依据来采取应对措施。
  3. 简单高效的政策分析和回测。新政策的制定和旧政策的修改,都是需要个合适的开发环境。这个开发环境中需要有全部的线上数据,需要跟线上政策执行有相同的环境方便一键发布,还要有高效的分布式执行环境来加快迭代开发速度。
  4. 研究成果的跨团队共享。一个风控团队发现的新现象或者新的分析思路,需要能顺畅的共享给其他团队使用,才能总体上提升整个公司的风控能力。

数据科学家

他们一般有如下的特点:

  1. 对数据挖掘和机器学习算法有深入的理解。
  2. 对数据有很好的感觉。
  3. 有一定的编程能力。

相对应的有如下的需求:

  1. 完整清晰的数据定义和数据流,方便科学家们专注于自己的强项。
  2. 高性能的分布式计算集群和基础设施。
  3. 多人协作以及跨团队协作的能力。
  4. 能轻松将研究成果应用到业务系统中。

产品开发工程师

他们一般有如下的特点:

  1. 专业的系统开发能力。
  2. 开发任务排期紧张。
  3. 关注系统稳定性和性能。

相对应的有如下的需求:

  1. 对接工作尽量简单。
  2. 有完善的文档和测试环境。
  3. 有系统级别的监控报警。
  4. 有专人负责对接工作和问题联调。

架构设计

刚才看到,不管从信贷风控的场景出发,还是从用户的需求出发,对于我们姨搜都很非常多的迥异的需求。 在对这些需求的深刻分析和理解的基础上,结合我们自身的特点,设计了姨搜的各个组成部分,并用非常创新的方法把他们实现了出来。 这里先进行一些总体的介绍,让大家有个印象。在这个系列接下来的几篇文章中会详细的讲解每个部分。

总体结构

姨搜总体结构

从数据角度看,下面的数据整合部分负责各种类型的数据的管理、融合和基础服务,实时服务主要提供给左上角的决策引擎,离线服务主要提供给右上角的分析平台,而分析平台得到的关于数据的insight,则可以推送给决策引擎来做线上服务。 从用户的角度看,风控相关的三类人都能在我们这里得到充分的支持。数据科学家能在我们的数据上执行复杂的数据挖掘算法,风控政策人员能用实验分析平台来迭代和验证自己的想法,而贷款产品的开发人员可以使用我们提供的简洁的接口来接入风控政策服务。

数据整合部分 – 知识图谱

kg总体结构

我们使用知识图谱来管理数据,这个图就是我们知识图谱的大体结构。 知识图谱是一种数据的组织形式,借鉴自语义网对事物的定义,任何一个概念(不管是人,公司还是某个房产)都是巨大的网状结构里的一个点,不同的点有不同的属性(比如人有姓名,公司有营业额,房产有建造时间),点与点之间有各种关系(比如一个人就职于某公司,拥有某个房产)。 这种组织形式足够灵活而且足够有表达能力,并且这些数据之间的关联关系是内置的,在不同类别的数据集进行融合的时候特别有用。

这里简要介绍一下我们的知识图谱的结构。 最中间的是实际存储知识数据的图数据库,考虑到数据规模和使用场景,我们基于ES和Hbase自己研发了图数据库,可以支持各种类型的在线实时查询和离线任务。 数据来源包括网络,内部数据库和合作第三方。 左侧是我们的网络爬虫,在控制器的管理下,会去抓取各种公开数据和授权信息。抓下来的数据会被实时分析和处理,比如计算一个手机号的画像,并实时写入到kg中。另外还会存储到HDFS中,供离线分析用。 第二部分是数据库,我们有自己研发的一套ETL工具,支持Oracle, mysql, hbase等,支持各种复杂变换和自定义UDF函数,而且也能支持流式计算和离线批量执行。ETL的输出可以是Hbase,mysql等,也可以直接写入到KG中。 第三部分是合作第三方的数据。合作方的数据类型和提供方式差异巨大,我们做了一个统一的接口,对内提供一致的restful接口,并且有统一的计费管理。除了在线服务,我们还会将这些合作方对接来的数据输入到KG中。 另外我们还提供了在线的实时写入的功能。

政策执行部分 – 决策引擎

决策引擎总体结构

决策引擎是在线执行风控政策的组件。它不是个简单的规则引擎,而是包含了数据源自动查询、自定义的变量计算、模型计算和规则判断、界面化控制、BI报表定制化分析展示等多种功能的全流程决策支持平台。

它对于产品开发人员,是一组restful API,返回对某个进件的审核结果但并不知道内部逻辑;对于风控政策人员,是一个自主控制每个细节的决策执行环境,能进行实时的调整,也能看到历史统计信息。 内部原理上说,它包括三个部分:从知识图谱等外部数据源中获取数据,用自定义的脚本提取决策特征变量,然后是模型计算和逻辑判断。风控政策人员在我们这里获得了最大的自由度,能随意的控制执行细节,也能看到每个执行的历史和各种统计信息。

实验分析部分 – ALBUS

Albus总体结构

Albus是为风控政策人员提供的开发环境,帮助他们快速的进行各种实验和尝试,并将结果快速推送到线上环境中执行。 同时,它还能为数据挖掘科学家们提供了分析环境和发布环境,可以把自己的成果作为一个模块放到Albus中,而风控政策人员就能直接把它应用到实验甚至是线上决策环境中。

总体上看Albus可以分为两个层面,逻辑层展示给用户并能进行操作,从逻辑上定义出一个实验,包括读数据、过滤和采样、特征计算、模型训练、结果可视化等多种模块。图中展示出的是最简单的场景,但用户可以随意组织各种模块,编制出非常复杂的实验。 在执行层中,用户的实验定义会转换成实际执行的代码,发给后端的Spark在分布式环境中高效执行,同时保持跟前端的交互。

总结

这里只总结了姨搜系统中最基本的几特点,短短的文章无法面面俱到。 我们计划用一系列文章来详细讲述我们是如何做到这些的,接下来的三篇会分别讲述知识图谱,决策引擎和实验分析平台Albus,再之后会慢慢涉及到风控搜索引擎、爬虫、ETL系统等,还望大家关注。