干货 | 携程风控数据仓库实践

作者简介

 

K.Y.Xing，携程高级开发经理，对高并发数据处理，流式数据处理，风控大数据处理，用户行为分析有浓厚兴趣。

一、引言

携程风控包括了酒店，机票，度假，火车票等所有携程产线的支付风控，同时也包括每个产线的业务风控。自2018年开始，携程风控归属于携程金融，进而也包括也携程金融的信用风控。总而言之，在携程，只要与钱相关的交易都离不开风控。

携程的业务线多，各业务的差异非常大。携程也是以BU制为单位的，各BU都建有自己的小数仓，使得各业务线的数据变化多样。为了能够满足风控的需要，如何搭建一个可以同时适用于反欺诈风控，业务风控和金融信用风控的数据仓库，是风控近两年需要解决的最重要的问题。

       

风控是一个横向部门，依赖于各个BU的数据，而OTA行业的特点又决定了数据很难统一。风控数据仓库需要解决的难点问题如下：

1）标准化各业务线的数据，为风控规则策略人员，数据分析人员，模型人员提供稳定准确可靠的中间层数据。

2）保证数据完备性，同时与各BU业务保证同步，为各个使用数据的团队做好数据质量监控。

3）提供高效稳定宜用的工具，使得各个用数团队可以快速高效操作海量订单，设备，用户行为各种数据。

4）在整个数仓基础上支持数据的回放以及各类特征的回溯。为规则策略人员以及模型人员提供基础保证。

本文将介绍携程风控是如何解决以上重要问题的实践和思考，与大家一起探讨互联风控数据仓库的发展，希望对大家有所帮助。

二、实践篇

       

传统数仓建设主要目的是为了提供业务决策分析使用，我们称之为BI。但风控数仓建设的主要目的是为了实现风险识别，包括支付欺诈识别，业务风险识别，个人信用风控识别。在数仓建设中包括 ODS层建设，DW层建设，DM层建设。数据治理，质量监控。

       

整体上，风控的数仓包括了下图中的内容。从业务系统的源数据，到数仓，最后到应用。

图2-1 风控数仓的物理结构

风控数仓的分层结构如下图，以简单直接，易于维护，同时方便回溯为目标。由于互联网行业的业务迭代速度非常快，这就要求数仓也需要适应这种快速迭代的要求，所以我们以简单化层次，并最大化复用为标准。设计如下的层次结构：

图2-2 风控数仓的分层

 

2.1 如何搭建ODS层

       

由于各业务线已经全面接入风控系统，数据量非常大，所以风控的ODS数据并不完全是从DB中抽取，只有少量人工审核相关的数据是通过ETL进入数据仓库的，大量的数据是通过流的方式“流进”数仓的。而风控依赖各个BU业务的数据则是在业务ODS同步完成之后，风控基于业务的ODS进行更进一步的加工处理为风控标准数据。

       

在ODS层，除了同步风控所有的数据以外，还做了标准的脱敏操作。不管是金融数据，还是订单数据，或者是支付数据，都涉及了大量的用户敏感信息。所以在数据进入数仓之前，我们使用了公司统一的神盾服务进行脱敏处理。

携程风控目前所有业务接入了800+个接入点的数据，相当于传DB的800+张不同的业务数据表。经过统一的ETL工具，每天零点到1：30这一个半小时完成ODS层的同步处理建设。

图2-3 风控数仓的丰富来源

    

2.2 如何标准化各业务线，建设DW层

       

携程的数据产线非常多，几乎涵盖了整个OTA行业所有的业务。

图2-4 风控数据产线

目前风控数仓以主题划分：