【演讲内容】中国银行上海市分行信息科技部架构师周杰和我们分享了大数据在银行领域的应用与实践。演讲内容主要包括以下四个方面：
一、银行数据管理面临的困境及挑战
二、银行Hadoop分布式数据仓库实践
三、大数据应用的方向
四、银行大数据综合服务平台实践
各位业界的同仁和朋友，下午好。我是来自中国银行上海分行的周杰，很荣幸今天能跟在座的各位分享一下我们行大数据平台建设的心路历程，如有不当之处敬请指教。
首先，我得感谢星环科技，感谢星环科技给我们创造了这么好的一个交流平台，让大家有机会坐在一起,互相交流学习。同时也借机感谢星环的同志为我们行大数据平台建设付出的努力和汗水，谢谢。
今天我的演讲主要分为四个部分：第一部分是关于我们行为什么要建设大数据平台,当时遇到了什么样的一些问题，促使我们决然的走向了大数据之路；第二简单介绍一下我们分行的Hadoop分布式数据仓库的架构；第三跟大家探讨一下银行大数据应用的方向；最后再介绍我们行的几个大数据项目。
1
银行数据管理面临的困境及挑战
我们分行从2002年开始组建数据团队，从事以数据仓库为核心的数据类应用项目的开发建设，至今也有十多年的历史，我们的项目建设一直遵循着小机加存储的集中式架构。随着大数据时代的来临，我们发现，传统集中式架构下的数据管理系统面临着越来越多的问题和挑战，已经逐渐无法适应时代的发展了。问题主要体现在三个方面：数据结构单一与大数据营销支持的矛盾、传统存储技术与大数据快速增长的矛盾、大数据检索缓慢与需求快速响应的矛盾。
数据结构单一与大数据营销支持的矛盾。一直以来我们面对的通常都是行内相对静态零散的各交易系统数据，对内部、外部存储的诸如社交信息、位置信息、影像资料等非结构化和半结构化的数据的处理、存储和检索都缺乏很有效的处理方法和工具。
传统存储技术与大数据快速增长的矛盾。我们中行在2010至2012年期间进行了波澜壮阔的物理大集中，随之而来的是数据的爆发式增长，从旧线的GB级别一下子跃升到了TB级别。但我们SAN存储即使面对TB级别的数据，在应对数据的时候也显得捉襟见肘。而向系统团队申请存储资源的时候，经常会以各种理由被打折缩水，每次给我们分配的时候只有几百G。但同时系统团队也经常想我们倒苦水，SAN的成本较高，每年总行审批的资源就这么点，数据应用已经占用了超过80%的资源了。而且单台存储设备的存储能力也有一定上限，扩容困难。
大数据检索缓慢与需求快速响应的矛盾。面对海量数据，我们的响应速度太慢，体现在两个方面：第一，多业务的数据需求旺盛，科技部门手工跑数，效率低下。从业务提出需求，需求流转，需求分析，开发测试，再到投产，周期长。而且科技最终交付的成果经常与业务的初衷或者描述不匹配，还得返工，期间的交互成本也较高。第二，传统架构下，面对TB级别数据，分析和检索的效率较低。我们的用户已经被互联网时代极致的客户体验所宠坏，对我们数据类应用的检索相率也提出了更高的要求。
2
银行Hadoop分布式数据仓库实践
为了解决以上的这些问题，在2014年，我们开始进行了一些调研工作，寻求突破。经过一段时间的研究，我们认为基于分布式架构的Hadoop大数据平台能很好的解决我们在传统集中式架构下数据仓库面临的三大问题。很快我们成立了大数据小组，开始着手建立分行自己的Hadoop大数据平台。我们找了6台PC机，搭建了一个Apache开源版的Hadoop集群，并开发了一个基于Hbase的历史数据查询系统。
随着项目的开展，我们先后多次碰到了几个开源Hadoop的所谓的坑，并为此付出了较大的代价。我们逐步意识到，开源Hadoop之路布满了荆棘，需要付出较大的人力和时间成本，并不适合我们这样的传统金融机构。因此我们在2015年开始转向商业版的Hadoop平台。对比了包括星环在内的等多家国内外知名厂商的，较为成熟的商业版Hadoop产品，最终选择了最适合我们的TDH作为我们行的基础大数据平台。在做POC之前，我们最不看好的就是TDH，不管从公司的规模还是业界的名气，星环都不具备优势，但TDH在POC测试中的表现，让我们眼前一亮，据此选择星环作为合作伙伴。
我们认为传统集中式架构的数据仓库成为历史，基于Hadoop大数据技术的实时数据仓库在业务上的变现才是未来。因此依托Hadoop我们首先进行了数据仓库的迁移。
相信只要做数据仓库建设，大多都会有这样一张图，从业务系统采集数据，到数据缓冲层，ETL加工、数据集市、中间服务层，再到应用服务层。不一样的地方就是在数据的存储和计算层换成了Hadoop的各大组件。从系统架构上来说，我们的数据仓库还是有比较大的变化。在数据存储、处理的能力上有了较大的提升。主要体现在面对大数据时代数据的爆发式增长、多样化的数据、实时数据流时高效的存储和处理能力，这些能力都体现在Hadoop的各功能组件中。
Sqoop：以JDBC方式直接抽取数据，简化过程，避免中间环节，提升效率。
Kafka：接收实时数据流，为后续基于实时数据流的数据处理和加工奠定了基础。
Hdfs：分布式存储，提供了廉价的海量数据存储能力。
Inceptor：数据仓库的核心组件，强大的SQL和存储过程的支持度，分布式事务的支持，高效的执行效率。
分布式内存技术的Holodesk表，是基于TB级别数据的自助分析成为可能。
Hyperbase和Search:半结构化、非结构化数据处理能力，高并发的毫秒级数据存储和检索。
我行在2015年开发了大数据管理平台：包括IDE集成开发环境、ETL配置、作业调度、数据服务平台工具。
Hadoop平台数据模型设计相比DB2、ORACLE等传统架构下的数据仓库，相对复杂。数据的应用场景，使用场景决定了数据的设计模型，可以说是怎么用怎么存。传统架构下，数据模型较为单一，无非是多设计几个索引。这张图总结了我们在大数据平台上做数据模型设计时的一些心得。举个例子：历史数据查询系统和自助分析平台的使用。
在使用了Hadoop之后，分布式数据仓库效能的总体批处理效率提升了三倍，原有数据仓库日批处理由12小时提升至4小时，月批处理由20小时提升至6小时，数据集市批处理由20小时提升至8小时。
3
银行业大数据应用方向
银行业大数据应用方向主要在风险类、运营优化类以及产品类，我行在很多方面做了探讨，我就客户画像展开，客户画像是在传统客户360°视图基础上，引入大数据，整合客户重大事件，社交关系等信息，实现客户体画像。我们认为要把客户画像、标签权限开放给一线的工作人员，让他们自助的定义、管理标签。另外除了传统的事实类标签之外，我们还得加入背后包含了数据逻辑算法的模型标签，这就需要类似Sophon这样的大数据分析建模工具去建立背后的标签、分类等操作。
4
银行大数据综合服务平台实践
我行在大数据综合服务平台的实践主要集中在数据检索、营销服务、风控服务、采集服务四个方面。
历史数据检索相对是一个比较简单的大数据应用，较多的公司特别是银行在上马大数据平台时一般都会先开发历史数据查询系统。我们行客户交易数据，特别是2011年蓝图投产前的旧线数据，缺点是信息不全，核心账务系统交易全，但是没有交易对手等详细信息，外围系统信息较丰富，但数据分散不易集中，面对公检法等有权机关以及客户的数据查询需求，特别是要追踪资金的来源和去向时，大大增加了成本，通常拿到数据之后，要先从核心账户系统开始排查，根据线索，到相关外围逐个查询。我们刚入职的小朋友戏称我们的查询交易，就像是福尔摩斯破案一样。
基于此，我行开发了集中历史数据查询系统，集中核心的、外围的、对公的、对私的、旧线的、新线的各业务系统，整合了近12年的交易数据，通过客户一键快速查询，即可检索到该客户相关的所有数据。单次查询过程我们控制在了10秒以内，大大提高了查询效率。但这个系统效率太高，风险太大。因此我们结合行内业管平台，加入了简化的审批流程，单个查询需求无需分行介入，一天内即可完成。
数据查询看板，是基于流处理的一个创新项目，实时展现当日我行各支行、网点的资金流入流出情况。主要用到了流处理技术，架构是业务系统向Kafka推送实时交易流，Streaming实时消费Kafka数据流，并在时间窗口内统计分析数据流，汇总出结果再次推送Kafaka，并最终写入ORACLE数据库，前端Echarts组件刷新展示结果。
第二块是大数据营销服务，大数据营销服务平台主要包括可视化机器学习平台和用户自助分析两部分。自助分析模块实现了大量客户数据、账户数据和交易数据的自助分析功能。基于Inceptor内的Holodesk表，我们对接了BI报表工具，实现了在线的大表的关联、分析和检索，从IDEA到分析再到执行全部在业务部门就完成了，不用向信科提需求，大幅提升了业务数据提取效率。第二是可视化的机器学习平台，用户可以通过拖拉拽的方式实现数据的预处理，实现计算、结果展示等等，基于这样的因素，这几年来，我行也做了很多项目，包括信用卡套现、账单分析等。
现在简单介绍下中高端客户流失预警模型。模型原理是利用中高端客户短期资产流失与长期资产流失的高关联性，通过逻辑回归模型提前找出中高端客户群中的近期潜在流失客户，支撑客户经理的维护工作，定制差异化的产品、服务和营销策略来挽留客户，以防客户流失。这个模型的开发过程，和往常模型开发没有很大的区别，但是效率提高了，包括业务理解、数据准备、数据理解、模型构建、模型评估、模型应用，其中有一些环节会有循环反复。在模型的构成过程中，我们选择了逻辑回归，模型的效果是比较突出的，我们对客户按照流失率评分，训练集的评估数据显示，前10%客户的整体响应率为20.2%，提升度为3.4，前10%客户的覆盖度为34.2%。
第三部分是大数据风控服务平台中的对公信用风险预警项目。我们汇总了对公、对私、内部存贷款数据、工商、税务、法院、舆情等外部的结构化非结构化数据，基于Inceptor和Search整合如此海量的多样化数据，实现全方位内外部风险信息整合。依托强大的SQL支持能力，精准实现既定预警模型逻辑。爬虫程序从互联网上爬去我行客户相关数据，有结构化也有非结构化数据，以文本文件方式转入内网，通过大数据管理平台接入我行Hadoop大数据平台。由于数据仓库已经实现了内部数据的整体接入，本项目并未对这部分数据反复处理，节约了成本。对于非结构化和半结构化的数据存储在Hyperbase和Es中。基于此，利用大数据平台生成预警信号效率提升了三倍左右。
第四部分位大数据采集服务平台，功能分为采集和服务两部分。采集的是外部外部数据源，包括人行征信、公积金中心、卫诚征信、公共信息中心等机构的相关数据。当然这些数据的获取都是在客户授权的前提现通过专线接入的数据接口。以往这些数据的采集比较分散，现在由我们大数据采集服务平台统一接入。接入之后，采集不是目的，服务才最重要。我们的服务不局限于采集到的外部数据，还包括内部数据。也就是说，我们向外输出的是包含内部、外部、对公、对私、客户、账户、交易的全方位的高效数据服务。在对公开户流程项目中的企业信息服务，大幅减少对公开户录入字段，提高信息采集的准确度，使得对公开户时间由140分钟压缩至60分钟，节约大量人工验证、审批流程环节。
最后回顾一下，在我行的大数据项目应用当中，得到业务部门认可度最高的几个项目。第一是是历史数据检索，主要面对支行网点一线的业务查询人员;第二是自助分析平台，主要分行业务条线部门;第三个是采集服务平台，直接应用于各个项目，得益于大数据采集服务平台，我们的数据活了起来，不在局限于数据类的应用项目;第四是对公信用风险预警项目，项目给出的预警成功避免、挽回、化解大量银行潜在授信损失。
