「完整版」农业银行数据库使用实践和发展规划!

摘要:中国农业银行(以下简称:农行)在信息化系统建设过程中,先是把关系型数据库作为联机交易型数据库使用,后来为满足分析型应用需要开始使用分析型数据库,近几年来随着应用场景细分,对基于 Hadoop 的大数据生态和新兴起来的 NoSQL、NewSQL 等数据库也逐步开始了大量应用。在数据库的整个使用过程中,关系型数据库一直占据着最为重要的位置,市场上主流关系型数据库产品都有使用到,积累了较多的使用经验。随着这几年两地三中心工程建设,对关系型数据库的使用提升到了一个新的层次。为了适应业务和技术市场的不断进化,对分布式数据库、Spark SQL 等新兴数据库技术也有了深入的探索研究和实践,对数据架构管控、数据生命周期管理和数据库产品应用进行了整体规划。

作者:蔡仕志

编辑:张晓艺

蔡仕志,农行研发中心高级专家。理学学士,高级工程师,先后就职于中国农业银行福建省分行、总行软件开发中心、信息技术管理部、数据中心,现任中国农业银行研发中心高级专家。长期深耕系统技术领域,曾获国家机关优秀青年创新奖,工作成果先后获得人民银行、银监会各类奖项10余次。

本文根据蔡仕志老师在DTCC数据库大会分享内容整理而成,将介绍农行数据库使用实践和发展规划,主要包括数据库使用实践、数据管理体系建设、数据管理典型案例、数据库发展规划等。

数据库使用实践

1.1农行省域及数据大集中

2000年左右,农行开始启动省域数据集中,前后时间大约4年,之后进行数据大集中,时间也在4年左右。

省域集中即把各个地市的数据甚至包括手工网点的数据上收到省行,数据大集中是把所有数据上收到总行。在省域集中的过程中,由于各个省业务量有大有小,因此,采用的技术方案不同。业务量大的省会使用IBM的大型机,有些中等业务量省份会用IBM的中型机AS/400 ,有些中等业务量及小业务量省份会用开放平台的Unix小型机(IBM和HP)。

农行数据大集中先是将数据集中到北京,后来迁移到上海。数据上收后,各个省仍然有开放平台的数据库。无论是在省域集中还是数据大集中阶段,凡是用了IBM大型机和中型机的,都是使用IBM的DB2,凡是开放平台UNIX下,都用的是Sybase ASE。

农行曾经大规模使用了Sybase,后来随着数据体量的增加和Sybase自身的发展问题,Sybase逐渐无法满足农行的需求,这个问题我们后面再聊。

1.2农行数据库产品总览

农行数据库使用情况如下:

业务量较大、响应较高的系统最开始使用Sybase ASE,后来因为Sybase无法满足高并发下的业务处理需求,就引入了Oracle;

少量业务处理应用系统因特殊原因,使用了:SQL Sever、MySQL、DB2 PureScale等;

分析型领域:最开始使用Sybase IQ,后来也是无法满足大数据量下的处理效率,只好引入国产南大通用GBASE,结合Hadoop、HBASE等产品;

内存数据库:Redis、MemCache、MongoDB等。

1.3 关系数据库工具箱

除了数据库产品本身以外,还有一些相应的工具箱。

PowerDesigner:数据库建模工具。

DBArtisan:图形化数据库管理工具,能够支持多个数据库产品,能够在相同的界面运行非常简捷方便的数据库管理操作。

ProActive DBA:用于数据库性能分析优化的,在Sybase年代是最好用的,能看清楚很多服务器端运行的一些细节,对于排查问题,提升性能非常有帮助。

OEM: 在Oracle上基于Java型的综合性系统管理平台,目前应用范围较广。

OMEGA MON:在主机平台能实现对DB2和Z/OS的监控。

此外,农行还引入了IBM的QREP、IBM-CDC、Oracle GoldenGate用于异构数据库之间的实时复制数据,特别是在两地三中心和主机以及开放平台的一些数据同步上。

在商业工具之外,还有一些与应用结合相对紧密的需求,是商业监控和管理工具满足不了的,所以农行也自主开发了一些工具,比如MyAME、OCMS等。

1.4 关系数据库经验谈

除了工具之外,我们再来谈一下这十几年来农行使用关系型数据库的一些心得体会。

在OLTP领域首先不得不提的就是让大家既爱又恨的索引,索引对于查询很有帮助的,但是对于数据库维护其实是不利的。因为索引越多,运行的时候需要维护索引的开销就越大,所以,索引创建量要结合应用的实际需求来考虑。

复合索引建太多会影响数据维护,也会间接影响性能。根据农行的经验,一般复合索引的字段数不应该超过5个。

跟索引有关系的统计信息,对数据库来说也非常重要。如果统计信息不准确的话,索引可能不会被正确使用,肯定严重影响性能。要想让它准确的话,就需要进行定期的更新,如采用定时机制由系统级来更新。最好的是由应用人员结合具体应用设计好什么时候该更新,因为应用更清楚数据变化规律。

使用分区功能的时候,要注意选择合理的分区方式和分区分段。要注意对于分区的数据处理,有可能导致全局索引失效。农行在使用Oracle的时候,曾出现过类似问题。有些情况下,如果更新局部索引的话,可能需要同步更新全局索引,不然会导致性能问题。

此外还有一个常用技术叫分表,分表其实不算是数据库的计术,算是应用的设计方面的。我们经常在应用设计上按周期分表。比如可能一个星期一天一个表,在写日志的时候用不同的表,这样的话有很多的好处,比如能够快速进行应用切换和数据清理更安全和方便。

数据库还提供了并行功能,这也是跟刚才提到的索引一样,属于让人是既爱又恨的功能。一般不太敢在联机的时候启用并行技术,因为并行技术虽然能够把所有的计算资源同时利用起来,但如果联机运行,可能某一个查询一下就因为并行,把资源耗光了。那并行功能应该用到什么地方呢?并行功能在做批量、数据备份、索引以及数据导入的时候使用是最合适的。

数据库产品还提供很多的诊断工具,有一些是字符型的,有一些是图形的,我们经常用这些工具来检查服务器的查询计划、执行时间、物理和逻辑IO、网络通讯,等待时间等等。

这些都是我觉得可以借此机会跟大家分享的我们近一二十年来使用数据库的一些经验。

当然除了数据库本身产品设计能力以外,我们觉得还是应用本身的数据结构和模型的设计,其实是对性能影响最大的。

此外,在SQL方面,通过合理地设计,控制事务颗粒度大小,这对于总体性能以及合理控制应用的资源消耗是非常重要的。如果适当地采用组合SQL,也能够避免一些数据库服务器和客户端的反复交互,对性能是有利的。

在运维方面,农行制定了一些针对不同数据库产品的标准配制规范,来指导维持数据库运行环境。因为不同的人运维会有不同习惯、误操作等问题,这需要通过规范来解决。还可以适当的把一些小的数据库进行适度整合到一个大的数据库服务器,避免数据运维的复杂度和工作量。

在OLAP领域,前面提到农行最开始使用的是Sybase IQ,后来使用GBASE。使用GBASE的过程也是农行与它共同成长的过程。GBASE是使用列存储的数据库,列存储天生占存储空间比较节省,相应地减少了IO,进而对性能有所帮助。另一个,它采用MPP架构,可以对多节点进行并行处理,自然能够大大提高性能。最开始农行使用的GBASE是无Master架构,最多支持64个节点。当数据量越来越大、节点数据越来越多时,无法满足需求了,就升级成了当前的联邦架构,能支持最多300个节点。

农行使用OLAP的经验有4个,首先是维度模型。在分析型数据领域,大多数都使用维度模型。通过合理的设计,虽然增加了数据冗余,但是提升了性能,这实际上是一种以空间换时间的方法。

第2个是数据分布,对于大的表,通过合理的哈希分布,合理地选择哈希列以便使得所有的数据在不同的节点上均匀分布。这样的话能够让同一个查询在多个节点同时跑起来。对于小的表格、维度表的话,我们会建一些复制表,存在不同的节点上。目的是减少一些跨节点的查询从而提高性能。

第3个是值得一提的GBASE索引。GBASE本身是粗粒度的智能索引,所以如果不必要的话,一般是不需要自建索引的。

第4就是,GBASE不支持分区,所以,前面提到的分表,其实也就变得很有使用的必要了。

数据管理体系建设

2.1 企业级数据模型

农行的企业级数据模型分两部分,其一是数据模型管理,其二是数据模型设计的方法。数据模型管理分为企业型、应用级两个层次。

企业型分成三个层次。A是业务概念等级,B是业务概念的细化分类,C是对这些细分的业务概念按照业务功能需要进行抽象为实体,然后提取所需的属性,寻找实体间的关系,形成关系图,也就是我们常说的ER图。

应用级的数据模型分成C’和D两个层次,C’是对企业级逻辑数据模型在具体应用系统里面的细化和落地,D是应用系统实际用到数据库中的物理数据模型。

数据模型的定义规范,这里的主题域对应企业级数据模型的A级,就是对业务概念按照不同的模型进行分类。

实体特征对应C级逻辑数据模型,是对实体的不同组成部分进行分类。

属性分类是对实体的属性进行分类抽象。

数据类型应用规范是对具体的属性分类进行进一步的描述,限制该属性的取值范围和精度等。

2.2 数据管理制度和规范

数据管理制度和规范共有三阶,包括战略层、规章制度层和技术标准层。

通过一体化的制度设计来规范系统研发与运维流程中的数据生成与消费,然后再配以专业的数据管理团队和流程化的改进机制,来落实系统研发运维和生命周期的架构管控。同时我们建立了两种管控机制,包括数据架构管控和数据质量管控。接下来就数据质量保障机制详加说明。

2.3 数据质量保证机制

农行的数据分布于消费领域和生产领域,一般数据在使用过程当中,就可能会发现它存在问题。发现数据问题后,我们会把这些问题整理形成相应的问题清单。这些清单由业务部门牵头进行分析原因。分析完以后会形成数据质量报告和数据问题报告,这些报告会按季度来提交到行里面,通过专题会来进行研究。

同时也会生成相应定期发布的全行监测报告。然后形成相应的系统建设需求或者系统控制需求。最后要对这些数据问题进行整改,整改的过程中,通常会采用高层协调联合治理方式,包括把它纳入到考核绩效挂钩等加强力度。

最后,会把整改结果反馈到消费领域,然后在消费领域再建立相应的监测规则,以便发现可能在这个运行中产生的新的数据问题。新的问题发现以后,会在这个闭环里面进行循环往复的修正,这就是农行的数据质量保证机制,通过这个机制能够实现数据标准管理和元数据管理的一个不断地持续改进。

2.4 数据管理技术平台

为了落实前面对应的各项制度和规范,农行还建立了一整套的数据管理技术平台,实际对应了DOTA、元数据管理系统、接口管理系统等一些系统。这些系统把数据模型、质量、元数据等这些管理流程,实现了线上化、管理提供了可视化视图以便于使用。

2.5 OLTP数据管理实践

农行从2008年开始,花了几年的时间研究,形成了自己的11步OLTP的建模方法和建模流程。之后在几年的时间结合BoEing数据模型进行反复实践并把它落地。

2016年开始,农行进一步总结形成了DOTA数据管理框架。从2017年开始,农行又选取了典型OLTP项目进行进一步的再实践。就是经过了研究、实践、总结、再实践的过程,实践了整个OLTP数据管理。

2.6 OLAP数据管理实践

与OLTP有所不同,农行的OLAP最开始是独立建设的。能够满足部分业务领域的需求。基于不同的标准,逐步形成了系统孤岛,系统间的数据共享程度相对较低。

为了更好地把数据组织起来,我们通过内部统一的数据交换平台,把来自不同源系统的数据统一汇总到新构建的操作数据区,再进行初步的清洗加工。然后在数据整合加工区进行进一步的整合加工,再把结果放到数据集市区以进行使用,形成了一个重新设计的共享多层次的OLAP系统。这套主题化、共享可复用、多层次的OLAP系统,可以直接提供给OLTP的应用来使用。

OLAP数据管理实践也有类似前面OLTP的四步走的过程。

数据管理典型案例

3.1 核心系统下移成效

我们的核心系统是基于DB2。随着这几年国家自主可控的要求,所以农行应用就需要离开主机。怎么离开主机呢?往开放平台下移。最先下移的是查询交易,把历史明细交易先移到开放平台的Hadoop上去,同时建立开放平台的一个核心总控。

查询交易下移之后,还有批量。我们先利用前面提到的QREP,把它从DB2同步到Oracle,建立起相应的批量执行平台,实现批量的下移。

下移之后空间就节省了很多,近几年都没有扩容,而且随着下移幅度进一步加大,虽然总业务量还是节节攀升,而且越来越快,但是主机的消耗并没有增加,甚至相对来说还有所下降。

3.2 银行卡受理中心系统

银行卡受理中心属于典型的高并发,响应速度要求和可用性要求也很高的应用系统,靠数据库本身来实现的话很困难。

所以农行采用数据分库、数据分表、短事务以及多种切换方式,经过比较复杂的应用级的设计,最终来满足高可用系统的要求。

3.3 分布式缓存云

在互联网金融业的高并发、高可用的业务场景下,农行基于内存数据库,建立了自己的磐云缓存平台,这个平台现在已经支持电子商务、快捷支付等8个应用系统,运行效果也很好。

3.3 大数据实践


农行的大数据实践是基于GBASE和Hadoop,结合自己设计的各种各样的数据处理平台、数据清洗平台等等,建了自主可控的大数据体系。该项目还在2018年人民银行科技发展奖中得到了一等奖。

3.4 两地三中心建设

关于主机平台上的两地三中心:早些年农行使用存储层技术来实现异地复制,但最近几年,存储层技术只是用来保留数据备份。农行采用了DB2 Qrep异步复制技术,取得了很好的效果。

关于异地数据传输、切换:异地数据传输、切换的时候,Qrep本身会有5分钟的数据丢失。为了应对这个问题,农行通过网络级报文进行数据补偿,以避免数据丢失。

关于开放平台:在开放平台方面,农行对于没有数据依赖的应用能够支持A-A模式,有数据依赖的应用只能用A-Q和A-S。开放平台的两地三中心我们正在逐步的建设过程中。

3.5 快捷支付系统

快捷支付系统是非常重要的一个应用系统。节日、促销活动(如春节和双十一)时,支付宝、微信红包等等都在快捷支付系统上面运行,这是压力非常大的一个应用系统。


为了满足需求,我们设计了高达24个RAC的庞大集群。


为了减少数据库访问压力,农行通过把静态数据及变化频率低的数据缓存到Redis中,对客户限额也进行缓存,应用对于限额的访问和回写都只访问Redis,缩短交易耗时。

为进一步提升系统高可用性,农行计划新增Redis同步功能,日终将月限额写回至数据库,实现限额数据持久化。当Redis出现故障时,可以通过访问数据库实现限额控制。

数据库产品本身的支撑能力有限,包括Oracle,虽然它已经是业界公认的成熟产品,但是业务场景的需求依然很庞大,导致我们需要对应用进行复杂的设计。这是我们需要考虑引入分布式数据库产品的一个动机。

数据库发展规划

4.1 数据库产品战略

主流数据库DB2和Oracle,以及Sybase会持续使用。

在分布式数据上有引入考虑。

农行预计在一些小规模的应用会使用MySQL,分析型数据库、历史交易查询、历史交易数据和内存数据库方面还沿用现有产品。

值得一提的是,我们正在选择图数据库和文档数据库,并对这方面有一定的了解。

数据库产品的选择其实只是第一步,如何把这些产品结合业务需要进行合理的使用规划,是一个持续时间更长、影响更为广泛的过程。

4.2 批量数据分布架构

农行通常会结合数据架构的设计选择数据库产品,农行内部主要有两套数据架构,一个是批量数据分布架构,它是满足T+1以及时间更长的数据使用,另外一套是实时的数据架构。

实时的数据架构业内称为大数据架构,农行已经完成大部分的架构(绿色部分),黄色部分目前还正在建设过程中。为了更好地促进大数据平台的数据能够快速的提供给需求方,农行还大力建设全流程的数据开发平台,以方便各个应用系统的使用方快速地进行开发数据与消费使用。

4.3 实时数据分布架构

农行实时数据的分布架构,是通过数据复制工具、网络旁路工具、日志采集工具等工具把不同的元数据汇总到实时数据交换层。实时数据交换层可以直接提供最上面的应用系统使用,也可以提供给实时计算层,进行进一步的加工。加工完以后提供给待消费的应用系统使用。

农行目前建设的实时数据总线,主要是数据传递的高速通道,当需要对数据进行加工处理的时候,就会交给大数据平台的流计算平台进行加工,然后再由实时数据总线交给对应的应用系统来使用。

以上就是我今天想跟大家分享的内容。数据库是可靠和稳定性要求的典范,农业银行为广大用户提供银行金融服务,同样也要求高可靠、高一致,我们相信,稳健才能行远,我的分享就是这些,谢谢!

Image placeholder
GalaxyNo_1
未设置
  78人点赞

没有讨论,发表一下自己的看法吧

推荐文章
耗时6年生成代码1.6亿行,农业银行大数据平台打造攻略!

摘要: 耗时6年,135个项目,8000页需求,累计投入11000多人月,生成的代码行1.6亿行,支持了8大业务领域,33条业务线,120多个应用场景,这就是中国农业银行大数据平台。近日,中国人民银行

平安科技数据库总经理汪洋:开源数据库在平安的应用实践

本文转自| 平安科技数据库产品团队2019年5月9日,平安科技数据库产品及存储产品部总经理在第十届数据库技术大会DTCC上分享了《开源数据库在平安的应用实践》,本文根据演讲内容整理,围绕以下几个方面进

中信银行信用卡业务数据库实现国产替换,湖北银行新核心系统项目正式验收,阿里云与MongoDB达成战略合作

中信银行信用卡业务数据库实现国产替换10月31日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京召开。会上,中信银行软件开发中心/技术平台开发处副处长

实践和思考的重要意义(论软件代码设计)

感触 最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思

实践和思考的重要意义(论软件代码设计)

感触最近这段时间,包括以前,经常听到,程序员们大谈设计模式,这个话题并不陌生,面试必问的问题,活了这么多年,我就一直没搞清楚,为啥面试官喜欢问这个问题。如果一个面试官喜欢问这种问题,我觉得也没啥意思。

做银行家里的数据专家:ING探索大数据时代下的金融最佳实践

大数据文摘出品记者:高延6月18-21日,O’ReillyAIConference在北京召开。大会上,来自荷兰的金融公司ING的IT主管BasGeerdink带来了《关于数字驱动企业》的主题分享。进入

MySQL 亿级数据数据库优化方案测试-银行交易流水记录的查询

作者:逸宸a链接:https://www.jianshu.com/p/cbdef47fb837对MySQL的性能和亿级数据的处理方法思考,以及分库分表到底该如何做,在什么场景比较合适?比如银行交易流水

从关系型数据库到分布式机器学习,揭秘腾讯大数据十年发展历程

大数据技术在过去10多年中极大改变了企业对数据的存储、处理和分析方式。如今,大数据技术逐渐成熟,涵盖了计算、存储、数仓、数据集成、可视化、NOSQL、OLAP分析、机器学习等丰富领域。在未来,大数据技

GoldenDB ,一个已经全面支撑银行核心系统的国产数据库

摘要:沿用、并存还是替代,一直是银行核心系统数据库转型重点思考的问题。四大行目前主要采用的是沿用与并存的数据库产品战略,在确保稳定的大前提下对新兴数据库技术进行探索研究和实践。相对而言,股份制银行在这

工商银行MySQL数据库架构解密

本文根据DTCC数据库大会分享内容整理而成,将介绍工行IT架构转型中传统OLTP数据库架构面临的挑战和诉求,构建基于MySQL分布式企业级解决方案实践历程,包括技术选择、高可用设计、两地三中心容灾、运

Laravel 服务提供者业务使用实例

开始动工吧 改动之前 在正式开始之前,我觉得有必要稍微花一点点时间看一下改动之前的调用方式,以便可以全面的了解一下,如果不感兴趣的可以直接跳过~ publicfunctiontranscodeVide

一文读懂数据库70年发展史

作者:常垒资本 冯斯基顾问:云和恩墨、戴工玖、周家晶零1949-19791956年,周恩来总理亲自领导了“科学技术发展十二年规划”,标志着我国计算机事业的开始。而那时,几乎没有人知道计算技术是怎么回事

GoWeb教程_13.1. 项目规划

做任何事情都需要做好规划,那么我们在开发博客系统之前,同样需要做好项目的规划,如何设置目录结构,如何理解整个项目的流程图,当我们理解了应用的执行过程,那么接下来的设计编码就会变得相对容易了 gopat

IT行业35岁后的职业规划建议

关于每一个IT人来说,35岁后是一个需求认真思索职业开展出路的新阶段。到了这个阶段,大家也不用过于焦虑,固然随着年岁的增长,30多岁的程序员在膂力和工作效率上,可能会比不上年轻的新人,但是经历的积聚关

职业规划指南:怎样才能成为软件工程师?

如果你想从事软件工程师方面的工作,但又不确定从何开始,这里有一些关于薪资、就业市场、技能和该领域常见面试问题的信息。美国“千禧一代”刚刚进入职场,他们中年龄最大的人进入职场时,美国的就业市场正好,雇主

职业规划指南:如何开启你的ML/AI 职业生涯?

无论什么行业,只有不断自我进步的人才有可能保持行业领先地位。技术行业面临着时代变迁的时候更应该如此。随着技术和相关业务的发展,在该领域工作的人必须在必要时更新技能甚至转变职业。在人工智能(AI)机器学

开曼国家银行已证实被黑客入侵:2.21 TB数据惨遭泄露

“或许这只是冰山一角,其背后还隐匿着更多的深海冰川。”开曼群岛——一个吸引人的财政天堂。近日,据外媒报道,匿名黑客入侵了开曼国家银行,并泄露了2.21TB数据,此外,他还向其他黑客提供100,000美

InnoDB一棵B+树可以存放多少行数据?

一个问题?InnoDB一棵B+树可以存放多少行数据?这个问题的简单回答是:约2千万。为什么是这么多呢?因为这是可以算出来的,要搞清楚这个问题,我们先从InnoDB索引数据结构、数据组织方式说起。我们都

美国银行Capital One承认被黑客攻击,超1亿个人数据遭窃

大数据文摘出品作者:易琬玉美国最大的银行之一CapitalOne客户信息服务器被黑,导致超过1亿人的个人数据被窃取。根据法庭文件,嫌疑犯是33岁的女工程师PaigeThompson,Thompson曾

海量数据时代,金融行业数据库实践难题如何解决?

随着数字经济时代的到来,大数据、人工智能技术得到了快速发展与应用,可以说,各行各业都已全情投入到这一波数字化转型浪潮中,把握新的发展机遇,获取数字红利。其中,金融行业可以说是走在转型之路最前沿的行业之

大数据推动教育产业创新发展

《大数据时代》作者维克托•迈尔-舍恩伯格教授著作《与大数据同行:学习和教育的未来》一书指出:当下大数据正悄悄影响到教育体系的每个层面,对于全世界的学习与教育活动,都会产生极为深远的影响。AI辅助教学,

当前政府发展大数据产业思路分享

笔者认为大数据发展大体会经历三个阶段,一、业务的数据化;二、数据的业务化;三、业务的智能化。2018年,各地方政府包括企业通过这几年的大数据建设,基本完成了业务的数据化、和数据开放共享的第一阶段,20

【系列】股份制银行在职员工有多少?其中研发又有多少人?

本篇为系列文章第一篇,下一篇, 2018年,股份制银行在IT方面都花了多少钱,做了哪些事?摘要:虽然做过些与银行相关选题,比如《四大行、股份制银行、城商行都在使用什么数据库?》《银行数据库选型之秘》《

杭州银行批量交易平台(HZBAT)技术内幕

1 概述杭州银行批量交易平台(HZBAT)是我基于DC4C自研的面向批量交易的技术平台。DC4C是我在2015年完全独立自研的分布式批量计算框架。目前HZBAT已用于综合积分系统(2015年投产)、E

K8s有多热?传统银行转型拥抱Kubernetes案例

Kubernetes已经成为标准的基础设施API,像RedHat、Mesosphere(现在的D2IQ)和Pivotal等供应商都无法避免。如果您希望使企业能够合理构建应用程序,那么Kubernete