序言

随着银行对于数据的需求量越来越高，各类数据分析、应用体系逐步完善，各应用项目对数据质量与数据存储要求不断提高，与之而来的就是数据库空间不足、数据口径差异以及跑批时耗不停增长等问题。因此，如何合理地使用数据库以及如何合理的使用数据成为了解决问题的关键。

数据库的发展与需要

除了采购和DBA之外，后台应用研发同样会关注稳定性、性能、扩展性等问题，同时也非常关注数据库接口是否便于开发，是否便于修改数据库 schema 等问题。

银行类项目由于其特殊性与一致性要求，通常在应用初期采用Oracle、DB2等关系型数据库，传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中。

在大数据没有普及的初期，银行类项目的知识库和批处理大多都在Oracle中处理，但随着业务量与存储量的激增，关系型数据库的瓶颈也逐渐暴露出来：

1.     高并发读写需求，对于传统关系型数据库而言，硬盘I/O是一个很大的瓶颈。

2.     海量数据的高效率读写，随着历史数据的不断增多，查询一张大表的效率是非常低的，即使创建分区和索引，每次加工的成本也很高。

3.     高扩展性和可用性，在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移。

站在数据管理的角度上，科技人员与业务人员对数据的宽容度是不一样的，科技人员考虑的是如何在当前资源下存储更多的有效数据，而业务人员则考虑到未来需求的不确定性要尽可能多的保留历史。尤其是科技话语权不高的今天，考虑数据库存储扩展与升级变得尤为重要，传统的关系数据库已经不能满足银行对数据的基本要求。

数据库选择

如今数据库种类还是很多的，这会造成业务开发的朋友可能不太清楚在他的业务场景下应该选用哪种数据库系统。

那么，我们先对这些数据库按照接口（SQL、NoSQL）和面向的业务场景（OLTP、OLAP）这两位维度进行一个简单非严谨的分类。

下图中，左上角是面向 OLTP、支持 SQL 的这样一类系统，例如 MySQL，一般支持事务不同的隔离级别， QPS 要求比较高，延时比较低，主要用于交易信息和关键数据的存储，比如订单、VIP 信息等。

左下角是 NoSQL 数据库，是一类针对特殊场景做优化的系统，schema 一般比较简单，吞吐量较高、延迟较低，一般用作缓存或者 KV 数据库。

整个右侧都是 OLAP 的大数据分析系统，包括 Clickhouse、Impala等，一般支持SQL、不支持事务，扩展性比较好，可以通过加机器增加数据的存储量，响应延迟较长。

在实施过程中则需要根据应用的实际情况选择适合自己的数据库，就目前的业内解决方案而言，大多采用的还是关系型+分布式结合的形式，借助关系型数据库的事务一致性与读写实时性处理应用系统日常数据的增删改查；借助MPP架构分部式数据库高效的检索与读写能力作为OLTP决策计算库进行批处理；借助Hbase、Hive这类结构相对简单，拓展性强的数据库作为OLAP数据分析数据库，对外提供数据存储以及数据支持。随着企业的科技化逐渐发展，数据湖的产生也一定程度上解决了开发与数据库之间的矛盾，帮助用户更轻易的操作数据。

集群的分布

如今的数据库五花八门，从来没有说哪个数据库好用就只用哪个，大家始终贯彻的理念就是适者生存，于此同时出现的就是集群的选择与分布。同上所述，针对数据的使用情况及业务属性，规划不同的数据库集群，也可以一定程度上提高不同作业的执行效率，降低彼此间的相互依赖。

例如数仓及ODS作为应用们的前置系统，可以和其他数据消费者共用集群提高整体的跑批连贯性，也可以单独部署集群保证基础数据加工的时效性。在数据量规模不算大的中小型城商行采用单一集群的案例会多一些，单独为数仓规划集群的项目则主要集中在大行。

除跑批集群之外，为最大限度提高跑批效率，还有银行会将批处理和历史数据分开存储，保证离线集群数据最小可用，提高批处理读写效率。此外还会根据项目需要专门规划核实的OLAP库供前台数据访问，实现读写分离，保证批处理过程的稳定运行。

数据库资源利用

除了集群分部之外，随着行内科技化逐渐深入，历史数据越来越多，大量批处理中不曾用到的历史数据会被用来分析建模，对数据存储的要求以及批处理时间的要求也越来越高，如何充分利用优化项目内外的资源将成批处理高效稳定的制胜法宝。

首先是对项目中资源的管理，无非是表创建、数据存储、数据生命周期管理、存储过程开发与跑批以及数据倾斜的纠正等。

1.     在开发之前针对所用的数据库制定好适合的语法规范，禁止各种导致节点不下推的低效语法，充分利用分布式数据库的机能。有经验的可以查看执行计划验证执行顺序是否符合预期，如果没有合适的规范，除了制定规范之外还要定期对代码进行审查。

2.     表创建时充分分析业务场景需要，花费最少的资源做更多的事，例如活用各种临时表处理复杂业务的处理过程，采用合适的字符类型减少数据库转换的时间消耗，根据检索场景设置离散规则以及按需创建分区等。对于数据量较大的表也可以根据实际跑批情况将历史数据和批处理剥离开，减少执行成本。

3.     合理优化数据表单生命周期，数据库资源毕竟有限，虽然分布式数据库的硬盘易于扩展，但时间成本和金钱消耗并不算低，随着上线时间增长，表的数据历史会越来越多，在充分考虑到应用可能的基础上设置清理规则，保留尽量少的数据，使数据库的执行效率始终在一个高效的状态，如果数据量过大将可能会导致资源分配不均匀，甚至是磁盘损坏等，这些都将严重影响日常批处理的正常进行。当然，如果客户现场有条件的话，可以引入数据湖或历史数据平台，在根本上将读写解耦，充分利用OLTP集群的执行效率。

4.     定期确认数据表的数据倾斜情况，根据实际项目需要针对倾斜量过大的表进行分布键重构，保证各节点的数据始终处于一个均衡的状态。

5.     除日常开发工作之外，对项目内的数据模型定期维护也将直接影响批处理的执行效率。定期对经常做更新的表做ANALYZE更新统计信息，生成最有效的查询执行计划，提高查询性能，并对有DELETE操作的表做VACUUM FULL，大量的更新和删除操作，会产生大量的磁盘页面碎片，从而逐渐降低查询的效率。VACUUM FULL可以将磁盘页面碎片恢复并交还操作系统。

其次是项目间的优化，很多行批处理时间久一方面是因为项目自身优化不充分，另一方面则是项目间跑批依赖没有得到充分的优化。正常如果要做全局批处理优化主要从以下几方面出发：

1.     确定项目内跑批脚本性能优化充分

2.     确定项目内资源依赖关系优化充分

3.     确定项目间资源依赖关系优化充分

只要能保证你程序该跑的时候正常调起来，调起来的时候跑的是正常水平，那基本上就已经算是优化充分了，但往往因为行内数据环境等问题导致它快不起来，但这也是未来的优化空间。将分散的数据统一到离线集群中去跑，去分析，去校验，生产数据的同时分析数据，促进整体协调全面的发展。

工欲善其事必先利其器，每个不同的数据库都是有自己的优劣势的，勤查资料，理性选择的同时尽可能的发挥其所有的价值，不足的地方拿其他更适合的解决方案去代替，将使我们事半功倍。无论是做数据开发还是功能开发，都离不开数据库，也都离不开需求，但不管怎样，只有知识储备得足够丰富才能做到因地制宜。