基于MongoDB的事后风险控制应用的研究与实现.doc

摘要第三方电子支付对风险控制的有效性有很高的要求。传统的风险控制系统使用关系型数据库存储业务数据，当交易模式或欺诈形式发生变化时，对事后风险控制模式的优化调整将产生很大开销，降低了风险控制的有效性。利用MongoDB模式自由的特性则可以有效地解决这一问题。本文主要研究事后风险控制在MongoDB上的有效实现方式, 包括引入外部文档对数据模式进行规范，和采用批处理与流式处理相结合的数据处理机制，分类完成数据分析，以及使用复制集搭配分片的数据库架构实现高可用性支持。并最后通过一个项目实例，从系统整体的横向可扩展性、数据处理方式、数据可用性等方面，详细描述MongoDB下事后风险控制的具体实现。关键词：第三方电子支付；事后风险控制；MongoDB AbstractThird-party e-payment is a high-risk commercial activity, and generally, a risk control system will be necessary for mitigating its fraud risks. Most risk control systems are RDBMS-based, changing the risk control model means changing every service module that coupling with its structured data. Since MongoDB is a schema-free database, MongoDB will be more suitable for this kind of situation.This paper focuses on the realization of MongoDB-based ex-post risk control system, which based on the importing of external dtd, multiple data processing mode, and Replica Sets plus Sharding cluster. and finally, introduces this systems extensibility, data analysis methods and its system performance.Key words: E-Payment; Ex-Post Risk Control; MongoDB22第1章 引言风险控制系统，是第三方电子支付风险管理解决方案的关键组成部分。其主要完成对交易事前、事中和事后三个侧重的风险控制，实现对交易的准确监测、风险评估、欺诈预警、规则管理、案例分析等操作，从而尽可能地规避潜在的欺诈风险，降低风险成本。事后风险控制主要负责对案例库中数据的分析，并将分析结果反馈到监测模块，使监测模块可以更准确地判断欺诈风险的存在，从而增强风险控制系统整体的风险监测与识别能力。同时，当交易模式或者欺诈形式发生变化时，事后风险控制的案例模型也需要进行相应的调整，这包括对底层数据结构到案例分析方式等一系列环节的调整。在传统的风险控制系统中，业务数据多在关系型数据库中存储。在调整交易模式或增加新的欺诈模型时，由于数据结构的模式化，数据结构与事后风险控制业务模块的耦合度较大，优化调整将产生很大的开销。根据MongoDB模式自由的特性，当事后风险控制的案例模型发生变化时，数据存储结构可以根据实际需求实时地进行调整，增减或是修改相应的数据分析项，并通过外部文档加以规范。相对于关系型数据库而言，利用MongoDB的模式自由特性，可以更加有效地适应欺诈形式变化。同时，在案例数据分析过程中，可以通过MapReduce与流式处理相结合的数据处理方式，提升事后风险控制模块的响应速度。而在系统架构上，则可使用复制集加分片数据库集群架构，在配合MapReduce进行批处理操作的同时，可以显著地提高数据库的可用性。文中应用实例的全套开发，系在指导老师引导下独立完成。部分技术规范参考上海华腾软件系统有限公司所有风险交易及反洗钱监控系统开发采购项目-技术建议书（已授权）。第2章 风险控制系统2.1 管理架构第三方电子支付的风险控制解决方案包含三个组成，风险的总体应对战略、风险管理者的组织架构以及风险管理的操作流程。风险应对战略是风险控制系统的设计依据；组织架构明确各部门、人员在风险控制中的职责和分工；操作流程是对风险控制运作流程的标准化。基本的风险控制管理平台包括监测、分析、案件管理三个模块。监测模块负责对交易信息的全面风险监测。交易数据产生时，监测模块按照监测模型将可疑交易信息发送分析模块进行分析，预警可能存在的风险交易，并将详细信息发送至案例管理模块。分析模块则是风险控制的业务主体，负责对风险交易的行为特征进行定义和判定，制定监测规则。案例管理模块最终将案例处理结果反馈给监测模块，提升监测能力。图1风险控制系统管理框架2.2事后风险控制的业务组成事后风险控制是对已经生成的交易数据进行分析处理、并反馈监测系统的业务总体。包括历史交易数据获取、业务对象构造、规则项参数统计、交易风险评定、欺诈风险反馈等业务模块。其基本业务流程如图2所示。图2 事后风险控制基本业务流程第3章 MongoDB下的事后风险控制3.1 MongoDB 3.1.1 MongoDB的优势MongoDB作为一款较为成熟的NoSQL数据库产品，其模式自由、面向文档的特性，使其在很多领域都得到了广泛的应用。在事后风险控制中，常需要对大量的交易数据进行聚合运算，而MongoDB对MapReduce数据处理范型的有效支持，使得MongoDB可以有效地完成对复杂聚合对象的分析和处理。MongoDB模式自由的特性，也降低了数据结构变化所带来的开销，相比于关系型数据库而言，更符合事后风控系统在应对新的欺诈形式时，快速调整风险控制模式的需求。3.1.2 MongoDB的横向可扩展性在一般的Web应用中，Web Server在需要性能扩展时，只需简单地增加硬件设备或是服务节点，而要在关系型数据库中实现这样的效率是不太现实的。升级数据库系统往往需要进行停机维护和数据迁移。而MongoDB对分片（Sharding）技术的支持，使数据库可以很好地实现横向扩展。如图3所示，MongoDB中的分片实现，是通过将大量的数据分块存储在个分片节点上，每个分片节点仅存储部分的数据。在需要扩展数据库容量或性能时，则只需要简单的增加新的分片节点或是分片集合，并在配置服务器中标明即可，这相当于一个近似线性的扩展架构。同时，MapReduce支持在分片集合中进行操作。处理数据时，MapReduce会将工作平行地分发给各个分片节点，处理完成后，再将各分片的处理结果汇总。这样既降低了服务器的负载，又加快了数据的处理速度。图3 MongoDB分片3.2 历史交易数据处理策略3.2.1 批处理对实时性要求不高的交易数据处理，采用批处理方式。批处理是对硬盘中静态存储的数据进行集中处理。如图4所示，业务数据进入系统后，首先存储到硬盘，之后按照一定的处理范围划分数据，分配到各个MapReduce运算逻辑进行计算。图4 批处理3.2.2 流式处理对实效性要求较高的交易数据处理，采用流式处理方式。流式处理是一种软实时的处理方式。如图5所示，待处理数据的出现时间和出现顺序无法确定，数据出现后则直接进入内存中，进行实时地分析处理，并生成处理结果。相较于批处理方式，流式处理的响应速度更快。但流式处理并非硬实时的处理方式。硬实时的系统逻辑要求操作务必在既定的时间内完成，软实时则只需要任务在规定优先级下尽快完成便可。具体到事后风险控制系统中，则表现为采用流式处理工作方式的业务模块，并不需要对调用逻辑产生实时的应答，而是允许存在一定的延迟。图5 流式处理3.3 数据库架构风险控制数据库可采用复制集与分片搭配的混合架构（如图6）。图6 Replica Sets+Sharding架构分片（Sharding）架构将数据水平扩展到服务器集合上，每个数据库服务器（即分片节点）只存储部分数据。一个数据库当机时只影响该数据库上存储的数据，数据可用性高而且易于维护管理。数据分布存储的同时，MapReduce的处理逻辑也相应的分配到了各个分片节点上。分片架构包括三种角色：Shard服务器、配置服务器和路由进程。Shard服务器是数据存储的实际物理位置。配置服务器中存储了数据集合在Shard节点上的分布信息，为每条记录提供到具体存储地址的指引。路由进程则是一个前端路由，拦截客户端请求并询问配置服务器请求的目标分片，连接到目标分片后完成用户请求的操作。为了进一步提高数据库的可用性。分片架构中的每一个角色都可以是一个复制集的应用。如图7，复制集相当于MongoDB主从模式的升级。主数据库的数据将会同步到一个或者多个从服务器中，当主服务器发生故障时，从服务器组将自动通过竞选机制选举出一个新的主服务器，替代故障机实现功能。复制集对数据库容灾、恢复和负载均衡都有极大的帮助。图7 Replica Set3.4 模式调整策略为数据库中的每一个集合项提供外部文档，外部文档内，存储数据的结构规范定义。当交易模式或欺诈形式发生变化时，根据风险控制模式的调整，修改数据的物理存储结构，同时，相应地修改外部文档的数据规范，提供更好的可维护性。第4章 应用的具体实现4.1 应用介绍4.1.1 开发环境应用基于Struts2 MVC框架、MongoDB搭建，并使用Eclipse开发。4.1.2 开发工具 Eclipse Kepler Release 1、Apache Tomcat 7.0.50、Struts 2.3.16、MongoDB 2.6.0。4.1.3 主要功能模拟具有用户权限控制的在线电子支付平台，并完成对交易的事后风险控制。4.2 系统架构 系统采用BS架构，操作人员可通过浏览器登录后直接进行操作。系统整体分层次设计，并在JavaEE架构上进行实现。逻辑上可以将系统划分为表现层、领域模型层、服务层和数据访问层四个层次。如图8所示。图8 系统架构4.2.1 表现层（Web层）Web层承担系统的页面显示，主要分为客户端脚本和服务器引擎脚本两部分。客户端脚本使用JavaScript对页面显示进行调整，提高用户的体验。服务器端采用Struts2框架，实现对视图、数据模型和控制器的进行分离。4.2.2领域模型层（Domain层）Domain层定义了系统内部使用的数据对象的领域模型，是系统内部Service业务对象各种逻辑操作的载体。所有领域模型均使用POJO定义（对象具有的属性以setXXX和getXXX的形式进行访问和修改），其实例的状态（属性）保存在内存中，供各层之间传递。4.2.3 服务层（Service层）Service层通过调用DAO层对象实现对数据库的操作，完成复杂的业务逻辑。Struts框架中，Service层被Action直接调用，完成各项业务操作，避免对数据库的直接操作，降低代码耦合度。另外，Service层包括公共业务操作可能调用的辅助类组件，辅助类组件统一定义在Util包中。4.2.4 数据访问层（DAO层）DAO层是数据的访问层，承担对数据库操作的封装并对上层接口提供固定的调用接口。4.3 数据库架构数据库采用分片（Sharding）架构，如图9所示。包含一个路由进程、一个虚拟配置服务器和两个虚拟分片服务器，所有四台虚拟服务器运行在一台物理机器上。图9 分片数据库架构各进程的端口分配信息如表1所示。表1 进程端口分配表进程端口Shard Server 120000Shard Server 220001Config Server30000Route Process400004.4 功能模块4.4.1 用户权限管理模块用户权限管理模块主要实现对用户的注册和登录、用户角色的分配以及基于角色的访问控制等功能。该模块定义了用户、角色、授权信息三种数据模型，并分别提供相应的业务逻辑。用户权限管理模块相关组件定义在“rbac.*”包下。4.4.2 交易管理模块交易管理模块负责处理客户的支付请求，当用户有新的支付请求时，交易管理模块将对交易信息进行采集，生成交易数据，并将交易数据发送风险控制模块进行分析，最后将交易状态和欺诈分析结果录入交易数据库。交易管理模块相关组件定义在“tp.*”包下。4.4.3 规则管理模块规则管理模块负责对系统交易规则的管理，实现对规则参数的配置、修改，和对规则启用与禁用状态的支持。对规则项的修改操作将关联用户权限管理模块，只有管理员权限才能进行这一操作。规则管理模块相关组件定义在“rule.*”包下。规则定义与规则数据项定义详见附录一。4.4.4 风险控制模块风险控制模块分为交易监测和反欺诈检测两个功能模块。交易监测模块承担对交易数据的分析和分析结果反馈。当交易管理模块发送的交易数据到来时，交易监测模块依据规则表数据对数据进行违规检测和风险分析，预警风险交易，并将处理结果反馈给交易管理模块，最终生成交易记录。交易监测模块的相关组件定义在“rc.exante.*”包下。反欺诈检测模块是事后风险控制业务逻辑的整合。实现包括历史交易数据获取、业务对象构造、规则项参数统计、交易风险评定、欺诈风险反馈等功能。规则项数据中的静态统计项，将采用MapReduce批处理方式，动态统计项则采用流式处理方式。同时应用中只对存在欺诈风险的交易进行标记并反馈交易监测模块，而不进行欺诈案件的生成与审查操作。反欺诈检测模块相关组件定义在“rc.expost.*”包下。4.5 代码示例详见附录二第5章 总结事后风险控制可以在MongoDB上得到有效的实现。交易形式与欺诈形式的变化在MongoDB模式自由的特性下，开销得到了有效地控制，而且使用外部文档定义数据模式的方法，规范了数据集合的存储结构，有利于后续的维护和开发。采用MapReduce和流式处理方式结合的历史交易数据处理方式，在降低服务器负载的同时，最大化的实现了不同业务逻辑操作对数据实时性的需求。而在数据库的横向可扩展性方面，通过实现分片的架构策略，实现了数据的水平分布，并可以通过增加分片服务器的方式，提高数据库整体的容量和性能。基于MongoDB事后风险控制应用的运行结果表明，使用MongoDB替代关系型数据库完成事后风险控制具有较高的可行性，并提供了比使用关系型数据库更好的横向可扩展性与数据可用性。参考文献1 Kyle Banker. MongoDB实战M. 人民邮电出版社，20122 Pramod J.Sadalage. NoSql精粹M. 机械工业出版社，20133 红丸等著. MongoDB管理与开发精要M. 机械工业出版社，20124 王铁栋. 电子支付风险责任划分与管理M. 北京：对外经济贸易大学出版社，20045 曹红辉等著. 中国电子支付发展研究M. 北京：经济管理出版社，20086 刘圻. 现金流管理:风险控制与价值创造M. 昆明：云南大学出版社,20107 王周伟. 风险管理计算与建模M. 上海：上海交通大学出版社,20118 顾孟迪, 雷鹏. 风险管理M. 北京：清华大学出版社,20099 Khristina Chodorow，Michael Dirolf. MongoDB权威指南M. 人民邮电出版社，201110 孙大为，张广艳，郑纬民. 大数据流式计算:关键技术及系统实例J. 软件学报，2014，25(4)：839-862附 录附录一数据项表：名称上级项值类型统计阶段默认值来源商户单日交易金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日失败交易金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户相同卡号交易金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日不成功交易金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日交易笔数日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日失败交易笔数日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户相同卡号交易笔数日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日不成功交易笔数日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日交易最大金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户单日成功交易金额日汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本周交易金额周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本周失败交易金额周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户相同卡号交易金额周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本周不成功交易金额周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本周交易笔数周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本周失败交易笔数周汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月交易金额月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月失败交易金额月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月不成功交易金额月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月交易笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月失败交易笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户相同IP交易总笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项相同IP相同卡号交易笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户相同卡号交易笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项商户本月不成功交易笔数月汇总统计浮点(double)统计数据项(静态统计)1统计数据项相同卡号*分钟交易笔数动态统计项浮点(double)规则项数据(动态统计)1规则项数据相同卡号*小时交易笔数动态统计项浮点(double)规则项数据(动态统计)1规则项数据相同卡号*分钟交易金额动态统计项浮点(double)规则项数据(动态统计)1规则项数据相同卡号*小时交易金额动态统计项浮点(double)规则项数据(动态统计)1规则项数据规则表：名称描述概览状态当日交易金额大于等于100万商户单日交易金额 = 1000000正常商户单笔交易商户单日交易最大金额 = 100正常发现商户风险等级高的商户商户风险等级为指定等级的商户商户风险等级 = 4正常商户日失败交易金额/日总交易金额商户日失败交易金额/日总交易金额 超过设置值商户单日失败交易金额 商户单日交易金额 = 100正常商户日失败交易笔数/日总交易笔数商户日失败交易笔数/日总交易笔数 超过设置值商户单日失败交易笔数 商户单日交易笔数 = 100正常相同卡号一定时期内于同商户交易笔数相同卡号一定时期内于同商户交易笔数 超过设置值相同卡号*分钟交易笔数 = 3正常相同卡号一定时期内于同商户交易金额相同卡号一定时期内于同商户交易金额 超过设置值相同卡号*小时交易笔数 商户单日交易金额 = 100正常附录二Web.xml配置文件：Struts2org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter Struts2/* tm.rc.expost.util.StatListener loginForm.jsp Struts.xml配置文件： errorForm.jsp loginForm.jsp indexForm.jsp indexForm.jsp loginForm.jsp loginForm.jsp registForm.jsp indexForm.jsp permissionForm.jsp indexForm.jsp indexForm.jsp ruleForm.jsp 流式处理代码：package rc.expost.util;import rc.exante.util.Monitor;import rc.expost.service.StatService;import rule.service.RuleService;import tp.domain.Log;public class StreamProcessing public void process(Log log) TradesPerMinute(log.getUser(), 1);cardTradesPerMinute(log.getCard(), 1);if(log.getStatus().equals(success)maxAmountPerDayStat(log.getUser(),log.getAmount();else FlaiedTradesPerMinute(log.getUser(), 1);cardFlaiedTradesPerMinute(log.getCard(), 1);String errMsg=new RuleService().isSafe(log.getUser(), log.getCard(), log.getAmount();if(!errMsg.equals(ok)new Monitor().informViolation(log, errMsg);public void maxAmountPerDayStat(String userId,float amount) StatService ss=new StatService();float sum=ss.getMaxAmountPerDay(userId);if(sum=0)ss.insertStat(max_amount_per_day,userId,amount);else ss.updateStatValue(max_amount_per_day,userId, sum+amount);public void TradesPerMinute(String userId,float amount) StatService ss=new StatService();float sum=ss.getTradesPerMinute(userId);if(sum=0)ss.insertStat(trades_per_minute,userId,amount);else ss.updateStatValue(trades_per_minute,userId, sum+amount);public void FlaiedTradesPerMinute(String userId,float amount) StatService ss=new StatService();float sum=ss.getFailedTradesPerMinute(userId);if(sum=0)ss.insertStat(failed_trades_per_minute,userId,amount);else ss.updateStatValue(failed_trades_per_minute,userId, sum+amount);public void cardTradesPerMinute(String card,float amount) StatService ss=new StatService();float sum=ss.getCardTradesPerMinute(card);if(sum=0)ss.insertStat(card_trades_per_minute,card,amount);else ss.updateStatValue(card_trades_per_minute,card, sum+amount);public void cardFlaiedTradesPerMinute(String card,float amount) StatService ss=new StatService();float sum=ss.getCardFailedTradesPerMinute(card);if(sum=0)ss.insertStat(card_failed_trades_per_minute,card,amount);else ss.updateStatValue(card_failed_trades_per_minute,card, sum+amount);public String clearDailyStat() StatService ss=new StatService();ss.clearStat(max_amount_per_day);return cleared;public String clearMinutelyStat() StatService ss=new StatService();ss.clearStat(trades_per_minute);ss.clearStat(failed_t