支付风控系统设计：风控数据仓库建设（二）

2016-12-19 23:18:00

这篇文章是支付风控系统设计的第二篇，重点介绍支持支付风控的数据仓库建设。关于支付系统在风控上的具体需求，可参见上一篇文章《支付风控场景分析》。

支付风控系统在数据存储设计上和其它业务不同的地方在于数据获取与使用的流程。一般业务系统会先确定系统数据需求，再设计如何在业务流程中采集数据，以及数据的格式怎么定义。而支付风控面临的是一个无法预知的场景，需要在实践中根据当前运行情况不断调整。它会先把数据采集过来，之后才能从中发现可能存在的问题，并针对该问题制订风控规则。也就是风控是先采集数据，再使用数据。

风控分析不仅要看交易数据，还得研究所有相关联的数据，这才能全面分析出来风险的根源，推断出需要采取的措施。因而数据采集工作对风控系统建设和演化是非常重要的。本文分析风控所需要的数据，如何采集和存储数据，建立支持风控的数据仓库。

一、数据来源

一笔交易的风险等级的计算需要考虑到多个维度。未成年人购买高档酒、促销期间羊毛客刷单、在洗钱高发地区的商户销售的物品成交价格远超实际价格。这些可疑交易的识别，仅依靠支付系统本身是无法完成的。用户的年龄、商品特点(是否高档酒)、是否促销、羊毛号的识别等，需要从各业务系统，甚至公司外部收集和用户、商品、商家、地区、手机号相关的数据，通过对这些数据进行分析，提取特征，识别潜在的风险。

1. 内部数据

风控几乎需要收集所有相关系统的数据。用户系统需采集用户的静态信息，姓名、性别、年龄等。风控系统不仅仅关注这些静态信息，还需要重点关注用户的行为信息，包括注册、密码修改、修改个人信息等操作，需要收集这些操作的时间、地点、设备等信息。此外，用户之间的关系，也是风控系统需要关注的数据。

商户系统：除了采集机构的基本信息，如成立时间、注册时间、人员规模、营业额、销售额、经营范围、注册地点等，还需要考虑到该商户关联的用户，包括法人代表、公司组织结构、主要员工信息等。
商品系统：商品的静态信息，包括类型、价格、上架时间、库存等信息；商品的浏览、放入购物车、购买、评论、退货等用户操作，包括这些操作的时间、地点、设备等信息。
社交数据，包括评论、论坛、留言等。
业务系统，如视频系统中的观影记录、类型偏好、时间、地点、设备等信息。

当然，支付数据是风控最重要基础数据。用户在支付系统中涉及到的数据都需要收集整理来支持风控分析。包括但不限于账户数据、订单数据、交易数据、优惠券数据和账务流水等。这些数据在支付数据库中也存在，风控所需要的数据和业务数据略有不同。除了业务数据外，风控还关心如下数据：

用户当前上下文环境，包括用户所用设备的类型、操作系统、IP地址、设备ID、所在地等，而这些数据往往并不是业务所关心的。而且记录太多的上下文数据也影响性能。
账户，订单等操作实体的状态。在业务数据库中一般仅保留实体的最终状态，比如账户是否已锁定、订单是否已支付等。而风控需要关心这些状态变更的时机，以及变更的时间间隔。例如，用户频繁更改交易密码，超正常频率提交订单等，就不是一个正常的状态。

这些数据一般可以从日志中采集。

2. 外部数据

对于大部分业务单一和用户量不大的公司来说，其数据有限而且单一，需要使用外部数据来辅助完成风控计算。

常用的外部数据包括：

公安部的实名认证数据，包括用户姓名、身份证号信息；
央行发布的各种名单，如洗钱区域，恐怖组织名单等。
央行信用报告，这个查询可是要真金白银的。
微博数据，一个人经常了解如何养卡，套现等内容并不是太好的事情。
工商局提供的公司信息。
招聘网站上的公司招聘信息。公司一直有招聘说明业务还不错。
芝麻信用，这个需要申请。

二、采集方式

一般来说，风控的非实时数据采集，不能直接从线上的数据库中读取，这会把数据库打死。主要的数据采集方式有从库采集，日志采集和pingback三种方式。

1. 数据库从库

主流数据库，如Hbase，Mysql都提供同步数据进从库的功能，读取从库不会影响主库操作。但如上所述，采用从库有如下问题：

分析所需数据和业务数据不同，还需要从其他途径补充数据。
将风控所需数据和业务数据紧耦合起来了。一旦业务有变更，风控系统也需要调整。

2. 日志

这是风控数据采集的主要方式。业务方可以将风控所需要的数据输出到日志中，风控系统对接日志来异步采集数据。这使得数据采集不会影响业务处理主流程。这种方式风险在于：

需要规范日志的格式，否则每个系统一套日志格式，会导致对接工作量巨大。
保持日志的稳定性。一旦代码被修改，打印日志的代码被删除了，会导致日志数据无法采集的风险。
需要注意日志采集系统的可靠性。目前主流的采集框架都有可能会丢失日志。虽然从我们使用的情况来还未发生这种事情，但不排除这个风险。

从技术上来说，日志采集的框架主要框架有

ELK（Elastic + Logstash + Kibana）， Logstash 驻留在日志输出端采集日志，并发送到Elastic 服务器上。 Kibana则是一个日志分析的工具；
Flume + Kafka + Elastic 。通过Flume进行采集，输出到Kafka，汇总到Elastic进行存储。日志分析可以在Elastic上离线非实时进行，也可以直接对接Kafka准实时分析，即流处理。使用Storm 或者Spark都可以。

3. pingback

Pingback指在页面上埋入脚本来监测用户的操作，特别是点击操作和键盘操作，将检测到的用户行为异步发送到服务器端。这可以侦测到用户在页面停留时间，鼠标点击的区域等信息，由此可以推断用户偏好，情绪等信息。 pingback的挑战在于如何在服务器端应对流量洪峰。pingback数据一般不直接入库，可以先写入Kafka，风控系统对接Kafka来分析pingback数据。

三、数据特征

用于支持风控计算的最终数据，在静态与动态数据为基础计算出来的带置信度的推算数据为主的离散数据，有点绕口，我们详细分析下这里涉及到的几个概念，来说明最终用来支持风控计算的数据有什么特征。

1. 静态数据与动态数据

上述采集到的数据，大部分是静态数据。也就是这些数据一旦产生，一般不会被修改。但在分析时，还需要一些易变的动态数据来，比如用户的年龄，每天的访问量，每天消费金额等。

2. 原始数据与推算数据

不管静态还是动态数据，他们都是从用户输入或者系统采集的方式产生。但我们知道，互联网的数据可靠性是有问题的。网上千娇百媚的姑娘，在现实中可能是一位抠脚大汉。虽然系统中设计了复杂的表格来收集用户信息，但会提供全部信息的用户还是很少，大家对隐私内容还是捂得很紧。

所以，在进行风险计算前，还需要对数据进行验证和补充。这都需要借助其他数据来进行推算，这些数据被称为推算数据。推算数据和原始数据不同之处在于它会有多个可能取值，每个值都带有置信度。完全可信为100%，不可信为0。置信度总和为1。比如正常情况下，用户的性别要么男，要么女。假如有个用户注册时选择性别女，但经常买刮胡刀，衬衣，没有买过女性用品，那实际性别为男的置信度就非常高。

3. 离散数据与连续数据

这是从属性值的取值范围来评估。比如用户每天的订单额，一般来说是连续分布的。而性别，职业，爱好等，是离散值。一般来说，离散值更容易做分析处理，刻画特征，所以在分析前，需要对连续数值做离散化处理。

四、名单数据

名单数据是支付风控数据仓库中最重要的内容。风控系统数据仓库建设，也一般都从名单数据开始。名单加上简单的拦截规则，已经可以解决绝大部分风控的问题。就算在更先进的风控系统中，名单仍然是风控中的基础数据。在评估事件风险时，名单往往是用来执行第一道拦截时所用的数据。比如用户交易时使用的手机是黑名单中的手机，则必须终止本次交易。