光大银行：风险一体化项目实施成功案例

一、企业名称

光大银行

二、所述分类

金融科技

三、案例背景

随着大数据和互联网+时代来临，大数据成为商业银行在市场竞争重要手段之一。新的市场和业务变化推动商业银行向智能化转型。银行信用卡中心数据外延大，与个人的结合点多，单笔消费信贷金额小，总体消费信贷金额高，对风险控制与管理的要求较高。因此，信用卡风险管理对信用卡业务具有重要的意义，促进信用卡中心业务增长，努力建设数据驱动的新一代信用卡业务体系成为目前国内银行的理想选择。

四、实施时间

2016.10-2017.9
 

五、应用场景

当前光大信用卡风险管理涉及贷前、贷中、贷后等各业务环节，已建设完成信用卡审批、催收、调额等系统，目前这些系统独立运作，而且各业务系统与V+核心系统进行不间断的数据交互。

由于缺乏统一的数据管控平台，无法实现风险数据统一存储管控，同时缺乏集中调度管理各风险模块的机制，各个风险子系统独立运行，不利于实现对业务风险全面整体把控。风险业务分析数据来源多样化，针对不同的业务场景很多数据都是重复的，数据未被重复利用造成很大程度的资源浪费。

光大信用卡中心拟基于现有各风险管理子系统功能，通过风险事件实现各子系统业务处理流程调度，搭建客户全生命周期内的风险统一管理平台。该平台不仅能够最大限度地拓展各个子系统的风险管控功能，并基于事件和信息在各子系统中的流转实现系统间的风险事件交叉反馈评价及检测机制，从而形成整个客户生命周期内的信息统一管理、事件信息联动，为银行信用卡风险政策的制定与落地提供统一的平台支撑。

六、面临挑战

风险业务分析数据来源多样化，数据源多，非结构化数据的清洗、转化等规则复杂，硬件载体不同，开发平台不同，系统环境不同。

七、数据支持

采集多源数据，整合光大信用卡中心各业务系统所涉及的数据资产；建立统一的数据存储规范，实现多源数据融合存储；为上层业务系统提供统一数据出口，对外提供数据查询服务；做到一次写入多次利用，提高数据利用率；多源数据融合存储，多源数据横向对比，提高数据质量。

目前风险一体化平台已上线运行，接入的数据来源主要为光大信用卡各业务系统。

数据格式主要为：JSON格式，文本格式等。

数据分类（类型）主要有：申请信息、人行信息（包括信用卡明细、贷款信息、担保信息、养老信息等）、第三方数据（百分点数据、国税数据、公积金、学历、公安等信息）、调额信息、贷中数据、催收数据、账单数据等。

支持的数据量情况：日接收及存储的数据量为：200-300万左右；数据总量：6亿左右；对外提供数据查询服务，日请求量200万次左右。

八、应用技术

8.1、风险一体化基础架构

8.1.1 分布式存储技术

风险一体化平台底层具有开放的架构，所有组件之间的交互利用标准的接口，具备很强的开放性。Hadoop的生态系统的组件有很多，它们之间有各自的分工也会有部分的重合，利用这些组件匹配出适合业务场景的组件，并要把适合的组件有机的组合在一起才能实现对业务有限的支持。开放性架构保证系统能够针对业务需求灵活整合底层Hadoop组件，实现面向业务的最佳技术组合。

下图中包含了最常用的组件，主要包括：

应用程序协调服务zookeeper、Hdfs分布式文件系统、资源管理器Yarn、分布式列存储数据库Hbase等；

计算框架：Spark：分布式大数据内存计算框架

8.1.2 多集群管理

系统底层集群的规模越来越大，在集群上线前期，部署通常要占用大量的时间和精力。Hadoop作为分布式计算平台，虽然可以很容易的处理海量数据，但是部署步骤较为繁琐。官方上的部署文档一般是配置免密钥登录、配置jdk、修改相关配置文件，再分发几台到节点服务器上。

几个节点的集群从系统安装好到集群部署完成需要几个小时，相关服务无法启动的话还需要慢慢排错，意味着集群投入使用需要更长的时间。每次部署如果都手动部署环境的话会非常麻烦，手工部署显得效率低，容易出错。因此，自动化部署集群显得更适合大规模集群上线的情景，而且只需配置一次，测试成功后以后都可以使用。

平台的自动化部署不只支持部署Hadoop，包括集群、主机、服务等在内均可自动化部署完成。天云大数据BDP企业级平台的自动化部署，保障了版本的一致性，可以帮助用户快速搭建Hadoop集群，2小时内即可完成一套10节点集群的部署，大大提高了部署效率。

为方便开发者更灵活方便的使用风险一体化平台资源进行开发，系统提供REST风格的服务端接口。REST具有结构清晰、符合标准、易于理解、扩展方便等特性，开发者使用REST接口可以实现对底层多个Hadoop集群的统一监管。

平台的集群管理功能，提供向导式的安装步骤，协助使用者管理物理资源分配，可根据服务模型、集群角色等多种方式进行分配，做到最大限度的使用集群，并有效的降低集群管理的复杂度。

根据不同的服务模型、集群角色等方式,可添加多个主机，并将主机按集群分组。按不同的主机配置分配到不同用途的集群中，得到物理资源合理利用、资源利用最大化的效果。

用户需要完全理解工作负载，这样才能选择最优的大数据硬件，下边是一个BDP企业级平台定义集群，主机分组的例子：

如图所示，根据不用的硬件资源和使用目的，将集群和主机分组，用于归档数据查询的集群由千兆网络、双核高频CPU、32GB内存、低速磁盘的主机组成；用于高并发的集群由千兆网络、多核低频CPU、64GB内存、高速磁盘的主机组成；用于复杂分析类的集群由万兆网络、多核高频CPU、128GB内存、挂载固态硬盘的主机组成。

平台的主机管理功能可以创建、配置主机，与集群管理配合使用，完成集群和主机的对应，根据不同的服务模型、集群角色等方式，进行主机分配。使用平台的主机管理功能使用户不必专门学习Linux与Hadoop相关配置知识，只需要通过简单的界面操作即可实现对主机的管理与监控，有效的简化了Hadoop集群的部署过程。

大数据平台系统出现问题，可能的原因很多，具体原因有网络、硬件故障、操作系统故障、服务配置与运行、病毒、异常进程、负载等。往往对具体原因不便追查。在实际工作中，日志中经常有各种严重错误信息，但也不影响信息系统正常运行。这时就会出现积累性或累加性的错误，系统运行初时没有影响，一旦累计到一定程度，会发生系统崩溃。为防止出现这种情况，需要进行相关性分析。在故障处理时，相关性分析尤其重要，可以迅速定位故障、减少判定时间。

8.1.3 开源服务框架管理

系统采用当前业内主流Hadoop平台进行底层支撑，将Hadoop平台下相关技术组件均进行封装，使应用开发平台用户不必关心Hadoop底层实现方式，只需要调用应用开发平台API即可进行相应的操作，可以做到平台无关性，并简化相关操作。这些组件的封装包括但不限于HDFS、HBase、MapReduce、YARN、Hive、Impala、Storm、Spark、Sqoop、Kerberos、Flume、Solr、Kafka、zookeeper。

8.1.4 多源数据融合

数据融合模块针对多个数据源实现全量数据的统一存储，定制相应的数据模板及校验规则对各系统接入的数据源进行一致性校验，并根据规则对脏数据、重复数据、缺失数据进行处理。

数据融合模块区别于传统技术，利用大数据技术手段，以Key/Value键值对的形式存储全量业务数据，通过分析业务需求预定义合适的主键，并将增量数据逐条插入到数据库中，形成统一的数据宽表，方便后续数据分析处理。

历史数据的一次性入库
将已经有数据格式的历史业务数据，直接调用数据融合模块，进行数据录入存储。

新增数据的批量入库
负责定期定时从业务系统中采集业务增量数据，并对数据进行一致性校验，校验成功后，直接调用数据融合模块，进行数据录入存储。

8.2 SQL查询技术

Hadoop大数据技术通过Hive和Spark等组件提供标准SQL支持，尤其是Spark2.0发布以后，Hadoop生态队已经能够支持TPC－DS 99标准，可以实现标准的SQL查询语法。

同时在开源Hadoop SQL支持之上，天云采用自主研发的数据探查工具，能够实现基于不同数据源的灵活SQL查询。

1)能够实现底层基于不同的数据源大数据平台、数据仓库、传统关系型数据库的跨数据库灵活查询。

2)支持标准SQL查询语句，实现灵活SQL查询。

通过Hadoop生态体系的SQL支持能力和天云的数据探查工具，完全能够满足对于结构化数据的查询需求。

实时OLTP引擎灵活查询技术

针对业务对查询性能要求高的问题，系统采用HBase分布式列存数据库支撑数据查询业务，HBase通过主键Row key进行数据查询，可以达到实时查询响应，但这种方式也导致了HBase自身灵活性较差；

针对查询条件灵活的问题，系统采用SolrCloud做为HBase的二级索引，通过索引手段来保证查询的灵活性。灵活性体现了可以实现根据任意字段、关键字进行查询，或者是字段的任意组合。例如指定查询包含某个或某几个字段，同时要求不包含某个字段任意组合条件查询等。

Hbase和Solr自身无法保证数据的一致性且两者结合开发人员使用难度高，需要同时熟练使用Hbase与Solr。针对以上问题我方提供一款中间件产品BDTQ，它从底层支持事务，很好的保证了数据的一致性，同时对开发者提供友好的接口，开发者不需要关心Hbase与solr之间如何关联如何使用，只需要写简单的代码就可以实现数据的入口与检索，降低了开发成本提高了开发效率，使代码维护工作更加方便。

1)BDP-RT特性：

与Hadoop生态圈紧密结合。

Hbase与solr的有效整合。

通过solr实现Hbase二级索引。

强大的一致性支持。

线性扩展能力。

读写严格一致。

基类支持HBase表的MapReduce作业。

数据查询的秒级、毫秒级响应。

 
2)BDP-RT用途

针对OLTP工作负载，能够快速低延迟的访问数据。

针对ACID，能够保证数据的强一致性。

针对开发人员，简化使用的复杂度，降低开发成本。

针对OLAP工作负载，能够对数据对象中的大部分数据进行批处理的处理引擎。

 
8.2.1 客户信息真实性判断

作为信用卡业务的生命线，风险管理被视为信用卡工作的重中之重。随着近年信用卡业务发展，信用卡申请数据激增，部分用户为了提高信用卡申请成功率和授信额度，在申请信息中提供虚假信息，成为信用卡风险的重要来源之一。风险一体化平台一个重要功能就是实现用户信息真实性判断，发现其中的风险信息，具体如下：

风险一体化平台通过数据融合整合多方数据来源，包括光大业务系统数据和第三方数据，尤其是人行征信数据、公安数据、公积金数据等，从用户、账户等多个层面进行数据打通。在基于客户数据统一管理的基础上，实现用户信息在多方数据之间的交叉验证，对用户信息进行真实性判断，筛选屏蔽其中的虚假客户信息，以便准确授信，降低风险。

 
8.2.1.1地址信息模糊匹配功能技术实现

针对地址匹配功能，天云所采用专业的文本分词技术，实现地址信息的分词，根据分词信息进行地址模糊匹配。

天云分词系统提供高精度的切词功能。同时，利用新词识别模块，自动化扩充领域词典。

 
8.2.2 事件管理模块

事件管理模块基于系统日志功能，实现对事件数据的记录和采集，并通过对日志数据的查询和分析，实现事件的全程可追溯，从而到实时预警，实现降低信用卡使用风险的业务目标。

Flume是Hadoop生态体系中提供的日志收集系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。

本系统创新的将Flume和Kafka整合在一起，形成基于消息总线的分布式数据聚合系统，实现日志数据的实时采集。

数据采集负责从各节点上实时采集数据，选用cloudera的flume来实现,flume是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方的能力。

flume的逻辑架构：

Flume架构

Flume采用了分层架构：分别为agent，collector和storage。其中，agent和collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。Flume使用两个组件：Master和Node，Node根据在Master shell或web中动态配置，决定其是作为Agent还是Collector。

数据接入

由于采集数据的速度和数据处理的速度不一定同步，因此添加一个消息中间件来作为缓冲，选用apache的kafka, Kafka是Linkedin所支持的一款开源的、分布式的、高吞吐量的发布订阅消息系统,可以有效地处理流式数据。

9、商业变化

办理信用卡中存在的风险问题，使得银行每年因金融欺诈损失数十亿元，传统的离散式反欺诈分析方法的漏洞暴露的越来越多，已无法有效的阻止这些欺诈行为，经验丰富的欺诈者利用这些漏洞创造出更多的欺诈手段，而不被金融机构发现。如何迅速有效识别欺诈，为业务风险分析提供高效的数据服务成为题中之义。

致力于解决银行内部数据的分析和已有数据孤岛问题，光大风险一体化平台成功整合了信用卡中心各业务所涉及数据资产，建立统一的数据资源池，建立统一的数据存储规范，实现多源数据的融合存储。通过多源数据融合存储，实现多源数据的横向比对，提高数据质量，为上层业务提高更好的数据支撑。

风险一体化平台的建设，为业务风险分析提供高效的数据服务，实现面向风险业务的实时数据反馈，最大程度上提升工作效率，降低几百万运营及人力成本投入。同时为信用卡审批提供交叉验证，有效识别欺诈虚假信息，结合数据分析技术有效识别信用卡欺诈事件，降低欺诈业务风险，每年降低了近千万的欺诈损失。