【揭秘】中国四大银行的大数据应用已到了哪个阶段？

1）银行压力越来越大

从十二五走到十三五期间，银行业面临的各方面的压力越来越大，从我们的年报数字可以看出去年四大行的利润增长基本上趋近于零增长。在这样的情况下，我们怎样通过IT的引领提升传统银行的竞争力，这是摆在我们面前的一个很重要的课题。

2）过去十多年期间，银行业务出现两个拐点

大数据怎么样能够在智慧银行的方向上起到更大的作用呢 ?

通过银行的历程佐证这样一个观点。过去十多年期间银行基本上有两个拐点， 第一个拐点就是发生在互联网银行慢慢取代柜员，IT支持从支持几万十几万的柜员到支持面向所有的互联网客户，这里面发生了一个根本性的变化，无论是服务的形态还是IT的支撑，都发生了很根本的变化，这是移动和云要在里面发挥作用。 下一个拐点是什么?银行要从原来做的账务性的、交易性的处理转向能够渗透到经济生活的方方面面，这是一个场景化，如果抓不住这个拐点，银行就要被互联网金融颠覆或者管道化。

3）三大互联网渠道已建立，具备大数据基础

这几年银行三大互联网渠道已经建立： 手机银行，已达到1.8亿多; 网上银行，我们有2亿; 微信银行，它占的客服服务总量已经超过了传统的客户服务。 这意味着我们的渠道、我们场景化的实践已经见到了效果，另外我们做大数据要具备的基础已经存在。

4）大数据要解决3大问题

谈大数据，对传统银行来讲，要解决3大问题： 怎么样提升对于客户的识别? 怎么样对于客户的营销? 怎么样提升对于风险的防范?

所以，无论是用传统的结构化的数据，还是用现在互联网形态下面非结构化的数据，要解决的问题都是这些，只不过我们现在有了更丰富的数据源，有了更好的对于数据处理的方法。 目前，建设银行已经成立了上海大数据分析中心，这不属于技术部门，属于信息管理部门。

5）建行大数据平台设计思路

从设计目标有这几条：

策略上架构先行，我们已经有很好的基础架构。1、基础能力上，我们在做一些基础的大数据分析工具的搭建。2、要想明白用数据做什么?我一直不太同意你先不要管你做什么，先把平台搭起来，我不太清楚有多少人从做数据仓库过来，当时提的很多的概念是垃圾进垃圾出，到了大数据时代没人提这个事情了，好像所有大数据都是质量很高的，但这方面要警惕。

功能架构设计，和大家都差不多，从采集、存储、分析、展现到应用。我要强调的是从这个结构来说，这是很完美的一个结构，但要能够实时或者及时地反映到你的业务流程当中去，反映到你的营销当中去。不要拘泥于一个结构。

数据设计，我们有一个演变过来的整体的结构。这里面我想强调一点，大数据是数据的一部分，结构化的数据是大数据的一部分，这两个东西不要割裂来看。

6）建行大数据成果

我们的大数据平台取得了一些成果： 实时的数据仓库上：我们能够对客户经理做实时的数据提供和交付，提供无论是并发的访问还是实时服务方面。 从数据的应用模式上：我们总结了六类数据应用模式，包括挖掘类、数据实验室、机器查询、仪表盘、固定报表、自动查询等等。

建立“模型实验室”：现在越来越发挥了更大的作用，我们能够基于结构化和非结构化的数据支持大数据模型的研发，这个模型研发出来我们能够很快地把它部署到生产当中去，能够为一些决策，未风先管理服务。

在非结构化大数据的应用方面，做探索：比如客户行为偏好的数据，录音文本、地理数据的应用、能耗数据的应用、媒体信息、员工行为数据等等。通过位置服务终端识别的新技术新数据的采用，拒绝可疑风险事件，上半年避免1.9万起，避免客户损失1.4亿，这种数据越来越大。

7）未来，场景化、标准化、平台化

刚才我提到了场景化，我们希望能够把金融数据的服务将来标准化和平台化，平台化之后能够在基础的大数据能力、基础数据的提供甚至一些分析数据的提供，基础应用，客户花香、征信评级的监测，为无论是内部的客户还是外部的客户提供更好的大数据技术，这是从技术方面来看大数据下一步做的工作。

1）工行大数据面临的挑战

如何处理数据量的快速增长?首先全行的数据量的快速增长，包括我们现在工行每天的交易量，外部互联网金融，工行的三大互联网平台造成用户的交易数据和行为数据有大幅的增长。 如何快速智能分析历史数据? 工行从2000年开始建立数据仓库以来，拥有了庞大的历史数据资产，在新的环境下怎么能够快速地智能分析，对我们提出了更高的挑战。 如何使用内外数据，描述客户特征?在数据源方面，除了本单位数据，也需要采纳外部的数据来配合进行分析。工行已经引入了征信数据、税务数据等，怎么做到比较全的数据去描绘我行的客户特征，这是作为我们的一个新的课题。

2）工行大数据战略思路

工行整个的战略思路是通过我们行的两库一司的建设来完善大数据体系。 两库是信息库和数据仓库，数据仓库在工行的建设和银行的建设中都是比较传统的，主要是应对我们之前的银行交易数据、账户数据，采用结构化的数据存储来进行相关的处理。前两年的时候工行启动了信息库的建设，主要指非结构的数据。 通过两库的建设，我们还建设了一支分析师队伍，能够对这些庞大的数据进行相关业务的加工处理和分析。

3）发展阶段

工行大数据的发展历程可以分几个阶段，从TB级已经进入了PB级的建设阶段，接下去在可预见的几年内会进入EB级的庞大体量。

最早工行是2000年初，那个时候大数据的领域更多的还是应用在一些报表的快速展现，所以那个时候我们是基于比较传统的Oracle和SaaS，做了T+1的动态报表，行领导和管理层能够在第二天上班前看到我们行昨天的经营数据，这是最早建立的。

2007年工行基于当时较先进的企业级的数据仓库的体系架构启动了工行的企业级数据体系的建设，做了全行统一的管理数据的大集中。

2010年基于我们的数据仓库的数据支持，我们推出了工行的MOVA管理会计系统，做了全行绩效考核的管理系统。 2013年随着外部形势的发展，大量数据爆发式的出现，我们引进了大数据领域在业界最流行的Hadoop技术，在Hadoop基础上搭建了信息库，发展是非常快的。

2014年工行基于大数据，原来的大数据采用连机异部批量的方式，通过文件存储的方式，不管是数据仓库还是信息库，在时效上相对来说比较慢，所以自主研发了一个流数据平台，能够提供实时或者准实时的流数据处理。 2015年下半年和今年正在推动分布式数据库的落地工作，会和企业级数据仓库做一个互补。这是大数据的主要技术演进。

4）大数据体系

在大数据平台上，我们可以把它抽象成如下几层：

第一层是数据采集，统一针对外部和内部的数据进行相关的数据收集，包括日志信息、行为信息和业务信息。

再上面一层计算层，是我们不单单提供了传统数据仓库的批量计算的能力，也通过一些流数据的技术提供了实时的计算能力。

再上面一层应用层，抽象了大数据相关的应用，包括用户可以自定义的查询功能。通过这些信息的服务，把这些服务抽象到我们的业务系统中，通过我们的管理会计系统，通过分析师平台、风险系统、营销系统，为我们在数据的运营、风险控制和营销方面都提供相关的支持，这就是主要的大数据分层体系。

5）分布式、开源、通用成为趋势

从大数据的起源开始，数据仓库到目前的大数据新形势下，数据仓库已经在做非常大的升级换代和变化。2014年工行从高成本封闭的专业系统(如：Teradata)，开始向高性价比、通用设备和开放技术的系统转变。

转型有两个原因：

第一是数据量太大了，原来只需要处理TB级已经转向需要处理PB级甚至以后EB级的数据量。如果是这么大的数据量，运用传统的设备没有办法进行相关的处理。

第二，性价比，我们做过测量，通过开放式的弹性可扩展的普通PC服务器的方式，比传统设备在成本上介绍十几分之一或者几十分之一。我们在新平台上一方面引进了Hadoop平台基于普通的PC服务器进行搭建，短短一两年的时间已经扩展到150个节点，存储空间已经超过1PB，超过建设了十几年二十年的Teradata的数据容量。

另外我们在研究也会尽快落地的分布数据库，会基于开源的底层架构，基于普通的PC服务器完成数据仓库体系的扩充。后续在大数据的处理加工方面会基于分布数据库进行处理。

从目前的分析角度来看，Teradata会保留，着重在高端的分析师分析挖掘的探索性的工作方面。后续工行的大数据体系会采用多种技术路线、多种技术平台共存的方式。

6）非结构化数据信息库，通过搜索

非结构化数据信息库的建设情况，建行已经介绍了，工行也有点像。信息库的建设原则，因为非结构化的数据的量是非常大的，所以我们的原则是信息库建设没有把非结构化建设进行物理存储的集中，我们只是通过统一的搜索引擎让用户能够快速地搜索找到他需要的非结构化的信息。

7）风险防控，是落地最快、最有成效的应用

工行在大数据应用方面主要侧重在风险方面。

工行通过大数据在事前、事中、事后三个环节的运用进行风险的柔性控制。简单地举一个例子，事前，比如银行卡的授信过程中，或者信贷要进行发放做净值调查中，数据能给它一个支撑。事中，比如银行卡最近比较多地发生盗刷行为，我们可以在事中通过大数据的方式发现银行卡的盗刷行为。事后，可以根据事后的交易或者发生的事件进行相关的分析，分析我们后续在业务的拓展或者风险控制方面有哪些需要进一步改进或者补救的工作。

这里举了几个简单的案例。非常好的大数据的应用场景：

第一 ，交易反欺诈，需要利用大数据流数据的技术，用户在做交易的过程中采用主机旁路技术，交易没有完成之前通过大数据在内存中进行一个判断。

第二 ，大数据怎么运用模型，通过比较好的用户特征的总结和模型做一个监控。通过标签信息，比如我们定义了两个标签，一个是用户开户的地区比较广泛，另一个他持有比较多的借记卡，我们可以认为他涉嫌倒卖银行卡的嫌疑，我们通过大数据的计算可以把这些人员抓出来，可以进行后续的业务处理和防空。这也是大数据应用的比较好的方面。

第三 ，现在各个银行业碰到的比较大的困境，信贷资产的质量问题。工行持续在推动运用大数据驱防控信贷风险，工行成立了信贷防控中心，运用大数据技术在进行相关的防控。

1）银行在技术选择上，相对保守

我们在2003年初开始搞大数据，当时有很多困惑，首先感觉到大数据到来了，现在各个行业，中央台什么东西都用大数据说话，我们在银行业我们能做什么呢?

早期在十几年前我们大家做数据仓库的时候，大家可能选择面都很窄，四大行除了我们没用TD其他都是用TD做的数据仓库。我们当时某系统也很痛苦，计算资源可以扩，但IO能力就在那里。当时觉得列存储带来很大的优势，处理通用的数据量减少了很多IO。平台选用什么?还用传统的吗?新型的怎么样?

金融在有些技术的选择上还是相对比较保守的，我们不会用的技术，不会用的版本，这也因为金融工委和国家人民银行对于我们的连续服务要求特别高，一旦出了事情领导交不了差。

2）自主可控，我们从几点入手

在自主可控上，基础硬件、基础软件、数据模型、工具平台和制度管理都是自主可控的。

硬件方面，采用华为的RH2288系列，2C、docore、256内存、12 4T硬盘，不同时期买的硬盘的容量是不一样的，后来是4T，之前是3T。

基础软件方面，我们引进了国产的南大通用做的MPP架构数据库，我们在原形试运行阶段从2013年圆形环境开始投产，采用28个数据节点，2014年3月份把它扩到56个节点。非结构化，结构化的数据上游生产数据基本都是放在MPV架构数据库里，使用起来技术上更流畅，效率更好。Hadoop方面，非结构方面目前使用的是CDH开源版，大概有100个左右的Datanode。

数据模型方面，我们结合先进的建模理论，我们融合了范式和维度的思路。我们在主库核心层面基本是范式建模减少重复。维度方面由业务驱动的方式建立维度模型为主。

基础的工具方面，大家知道有ETL、批量调度、源数据的管理，这些东西都是我们自主开发的。我们制定了一套比较完备的规范、制度、方法、标准。

3）整体逻辑架构

数据源层，上游的生产系统，几乎全行所有的生产系统的数据到今年底已经全部进来了，金融交易类百分之百都进来了，现在有60多个上游系统，通过一个交换平台，交换平台不仅仅为大数据服务，负责上游生产和下游数据消费系统总分行之间、总行各应用系统间数据交互的平台。

数据处理层，淡黄色指关系型的数据库，也就是MPP架构数据库。操作数据区、非结构化数据区、历史数据平台、流计算，流计算用Hadoop Stam架构。

下面是Hadoop的东西。我们在整个大数据平台的结构化主库里分了基础数据库、共性加工区和指标区，非结构化有操作数据区、非结构化处理和历史数据平台。影像那部分早期已经建好了，为了减少网络压力基本上存在分行。

跟传统不一样的是，大数据平台的日加工时间目前在七八个小时，早期批量一个是优化不到位，一个是处理的分层，所以用了Hadoop把ETL和操作数据区都放在Hadoop里，因为可以节点多、计算能力强，完成了ET的过程，上游来的全量数据在这里做了归类，生成了一个纯层量的数据，减少了一天的批量时间几个小时，提升33%的性能。

数据集市层，现在规划8个数据集市，跟其他行没有太多区别，客户营销、风险管控、外部监管，对分行服务的集市，各行服务的对象都是一样的。底下研了数据提取平台，外部监管和数据提取任务特别重，早期都得到生产去导带生成，现在我们通过单独建一个环境，把一些数据预加工好，基本以宽表的模式，以前做加法的事情变成了做减法，至少80%的提出需求都在我的环境里直接提取，大大减轻了人力。

底下是分析挖掘平台，ODM、SaaS都是农行已有的云，大数据只是它的用户而已，我们在Hadoop分装了应用，为全行的分期挖掘提供服务支撑。对上层应用的服务有直接访问，数据文件和外部服务和数据快速复制等技术和应用进行连接。应用主要是对资产负债领域、电子银行领域、信用卡和个人金融领域、风险和财务提供了一些支撑。

大数据平台和集市，我们建成了4个集市，有3个集市在建的过程中，今年分行下半年要搞分行集市的试点。应用，我们提供统一的数据展示和服务。展示服务一个是对所有全行业的用户，对所有行业监管的各种报送，因为各种报送比较零乱，点也比较多，趋向不同部署也不一样，底层做了统一调度、统一监控和ETL，对全行描述类数据进行了统一管理，包括我们的数据标准和数据质量管理都在这里统一进行。

4）硬件环境如何进行有效支撑?

在Gbase方面，56是生产环境，现在实现了56环境的双活，这两个56环境同时在工作，一个做T+1当天的数据加工，一个做隔一天的连级服务，这样的话连级服务的能力，按实侧的话会比以前做TD的测试中更强一点，另外个人客户集市、资产负债集市，还做了数据挖掘层次，Gbase集成了WODM和SaaS。Hadoop的生产环境是92个datanode和2个namenode。我们现在Gbase有236个节点，库内主副本的整个容量有5.2PB数据，Hadoop的集群是150个节点，容量是4.3PB。

56+8是56个数据计算环境，8个是加载机，56个环境每个节点是12块3T的硬盘，有2块做Read1，是存放操作系统和重要的参数信息和数据库环境，其他10个环境是Read5来存放数据，一个节点存放有效数据10几个T，56的环境里有效数据将近300个T，Gbase有5到10的压缩比，各个字段可以选择压缩去，300个TB的数据换算成仓外的文本量，就算简单乘以300T也是1.5PB以上，现在折算成1.8PB左右，是PB级的。

我们跟Gbase从这个时候开始合作，我们在八方面跟他们共同做了一些优化工作，跟Gbase做了大量优化，有近百个优化的细项。MPP数据库，我们搭建了双活机制，两个库之间的同步加验证现在每天大概是22TB的数据，仅需要3小时。早期在给主库做备份的时候，100TB的数据有小40个小时，后来我们用了Hadoop做备份，100TB用了不到10小时，大家用TB备份一直是比较难的事情，在Hadoop方面我们做了大量基础性的工作，非结构化的数据、文件的服务、数据的备份等等。

我们做了MPP和Hadoop的交互，有些应用要交互，我们做了非结构化MPP和HDFS之间的融合。后来启用了MPP和Hadoop之间的备份，大大提高了效率，300T也需要将近20个小时，所以我们做了双活，如果双活稳定的话我们就不用备份数据了。开发的基础工具包括ETL工具、批量调度、整个的监控和统一访问层，监控这块我们还做了健康检查，通过SaaS把半年的日志交过去，最后生成一些模型，给我预测整个系统运行的安全状况。数据混搭的模型设计，我们有一套完整的方法论，能保证数据的准确、稳定、完整和可用。同时我们在方法论、开发规范、数据规范和流程规范都积攒了一系列文档。整个模型是分层的，操作数据区、基础数据区、共性加工区、指标层和集市层，完成了客户的统一试图、产品的统一管理和客户的精准营销和风险管控等等。