摘要：中国农业银行(以下简称：农行)在信息化系统建设过程中，先是把关系型数据库作为联机交易型数据库使用，后来为满足分析型应用需要开始使用分析型数据库，近几年来随着应用场景细分，对基于 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 实时数据分布架构

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

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

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