hanfeng_twt
作者hanfeng_twt2022-05-11 13:43
数据库架构师, SphereEx

商业银行分布式数据库选型路径及实时分析场景实践

字数 4580阅读 8063评论 7赞 6

一.概述及背景

作为数据基础设施的重要组成部分,数据库在其中扮演着重要的角色。近些年来,数据库整体发展也呈现出较之以往很大的不同。其一、是开源数据库受到更为广泛的关注,从多家机构的最新报告来看,开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式,正成为未来数据库发展的主流。其二、是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境,包括云上数据库的发展速度也远高于非云环境。据乐观估计,在未来5~10年云数据库将占据整体数据库市场的七成以上。此外,对迁移到公有云、使用多云环境等问题,也普遍被企业所接受。其三、是数据融合趋势,针对数据多场景应用,使用融合技术简化访问,提升效率。

作为数据使用高地,金融行业一方面对数据库有着极高的要求,一方面又面临很多来自数据新的挑战,诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现,迎合这一发展趋势,对于金融企业解决上述问题带来新的解决思路。本文从金融用户角度入手,对如何选择分布式数据库及选型后的最优实践进行阐述。

1. 金融业数据库选型背景

随着企业数字化转型深入,对于数据使用场景也呈现多元化趋势,正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”,这一趋势表现更为明显。同时我们也看到,近些年来数据库领域也发展迅速,有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势,金融行业很多企业都在面临选择数据库的问题。

2. 选型技术层面要素分析

从技术角度来看,在数据库选型中有哪些要素需要考虑呢?下面以近期比较关注的分布式数据库的选型为例,说明下重点考量的技术要素。

• 分布式事务
分布式架构,自然会带来分布式事务的问题。由于需要跨节点的网络交互,因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加,数据库的并发性和扩展性也会受到影响。针对单笔事务来说,分布式事务执行效率是肯定会有降低的,分布式带来的更多是整体处理能力的提升。

• 性能
由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗,分布式数据库优势不是单个简单SQL的性能,而是大数据量的SQL查询,每个节点会将过滤之后的数据集进行返回,会提升性能,并且分布式数据库的优势是并发,大量的SQL并发也会比单机数据库强大,应用需要做分布式架构的适配,将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务,OLTP类的分布式数据库处理效率一般较差,事务处理时间会较长,事务期间的锁持有时间也会增加,数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的SQL语句(主要是多表关联)的事务。

• 数据备份
分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳,所有节点都会遵循该机制,所以备份恢复的增量也是基于全局时间戳,但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份,物理级的备份会比逻辑的备份性能吞吐大很多,还有就是是否支持一些分布式备份方案,比如S3协议接口,是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案,通常从备节点进行连续备份(全量+日志),恢复的时候指定节点进行恢复到指定时间点,整个过程可配置自动任务、自动执行。

• 高可用
分布式数据库大多都是基于多数派协议,同城双中心不适合多数派的要求,同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制,异地建议采用集群级的binlog异步复制,建议实例的主备节点设置在同城两个双活数据中心,仲裁节点三机房部署;异地灾备单独启实例与本地实例进行数据库间同步,也可以将本地备份文件T+1恢复到异地灾备。

• 数据一致性
分布式数据库大多都是通过获取全局时钟时间戳,采用二阶段提交,可以实现一致性的保证,分库分表架构对于事务的一致性,需要应用层考虑,比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致,对于全局一致性读,一般通过引入类似全局时间戳的组件统一管理全局事务,在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库,对于要依赖分布式事务“中间状态”的业务,优先进行业务改造进行规避,其次通过合理的数据分片设计让其在单节点内完成。

• 数据分析
分布式数据库,多采用存算分离架构。针对数据分析场景,需要对数据从下层存储节点上移到计算节点,这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术,减少需传输到计算节点的数量;一方面针对汇聚后的结果需要通过流式处理等方式,规避诸如OOM的问题;此外也可采用如MPP等并行处理技术,加速数据分析过程。

3. 分布式数据库选型过程问题痛点分析

在选型过程有,会遇到来自以下几方面的痛点。
• 一是由于分布式数据库整体架构还比较新,也是近十年来逐步发展完善的。针对新型架构的诸多特点,包括厂商和用户还都在不断摸索积累之中,还需要有个长期实践的过程。此外,新架构也需要有个逐步成熟完善的过程。
• 二是大量产品来自国内数据库厂商,其发展周期相对较短,还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说,一方面需面临产品多、技术栈多的现状;另一方面还需面对成熟度不足等问题,存在较多痛点。
• 三是近些年金融行业发展迅速,各种新的业态产品不断涌现,这些对作为底层数据基础的数据库也提出了更高的要求。
• 四是随着内外部环境的变化,自主可控等问题受到更多的关注。金融行业首当其冲,针对上述问题也需要引起足够的重视。在数据库选型问题上,也需要考虑这一因素。这无疑对用户选择带来一定困难。

二.选型技术架构

1. 分布式路线分析

针对分布式数据库的发展路线,大体可分为两种:

• 分布式中间件
这种架构是从中间件路线演进而来。其采用存储与计算分离架构,底层采用标准单机数据库,副本间基于数据库主从复制机制。上层承担计算,并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局MVCC等方面,往往存在一定难点,各厂商也有各自解决之道。

• 原生分布式
这种架构正是受到Google论文影响演进而来。其采用存储与计算分离架构,底层采用单机库(不一定是关系型),副本间采用分布式一致性协议完成复制,支持多数派提交。上层承担计算,并可将部分计算下推到存储节点执行。

2. 重点需求满足情况

针对上述遇到的痛点,两类产品实现逻辑也所有不同。

3. 路线场景分析

从数据使用场景来讲,可大致按下面进行划分:

针对不同的场景,不同分布式数据库路线产品各有所长。
• 针对事务类场景下,强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。
• 针对事务类及事务/分析混合类场景,既要满足常规联机交易场景的同时,还需满足分析类的一部分能力,这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库,用一个数据平台应对规模化交易和实时分析,提升业务决策的时效性,降低数据技术栈的复杂性,越来越多的混合负载需求推动了 HTAP 在金融场景的落地。

三.金融 HTAP 应用场景实践

1. 金融场景下 HTAP 的分析

在金融企业数字化转型的过程中,各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中,实时推荐、精准营销对实时处理能力是企业提升竞争力的一大因素。在企业风险控制场景中,实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失,HTAP正是基于上述背景诞生出的需求,为各类实时数据处理需求提供了解决方案。

2. 建信金科中 TiDB 的架构设计和实践

随着金融市场同业业务的蓬勃发展,业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式,已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求,迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点,在我们整个技术选型过程中,重点考察待选产品如下能力:包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过多轮测试,最终选择TiDB作为基础数据库平台。通过一段时间上线使用,很好地满足业务场景,基于 TiDB HTAP 的特性,打造金融市场实时数据平台,目前已投产了灵活报表和交易对手分析等功能。整个处理流程包括:
• Flink 消费交易系统产生的实时增量数据,对部分事实表进行拉宽处理并写入TiDB
• 维表和其他明细表直接写入 TiDB
• BI 工具直接连接 TiDB,提供秒级的实时计算和分析能力

金融市场实时数据平台的成功上线,构建了千万及以上数据规模、超过5张表的复杂关联实时查询能力,让业务人员在极短的时间内(大部分报表执行时间为几十到几百毫秒、个别报表秒级别)获得实时交易的详情。

业务的需求是不断变化的,我们也正逐步探索 TiDB HTAP 的适用场景,如手机银行发起的高并发明细查询等,为业务数据价值的加速释放提供助力,从而持续提升客户满意度。

3. 未来 HTAP 的场景发展

实时数据处理技术还以某一些具体的应用场景为主,从现状来看以事件驱动类、流式管道数据计算类为代表的场景,已经开始使用HTAP场景的。未来随着HTAP计算能力进一步的提升,实时全量数据的计算将带来更多场景。

四.面向未来的架构趋势

1. 云原生

从未来的发展趋势来看,云方向是一个大的趋势。

我们可从上图中看到,云数据库的发展经历了几个阶段,从云托管、云服务、云原生之路。
• 云托管,是最接近传统数据库系统的部署模式。本质是将原本部署于IDC机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下,云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL审计、性能优化和状态监测等企业级数据库管理能力,用户可减少运维投入即可享受之前同等的服务水平。
• 云服务,之前的托管架构中,受限于传统数据库架构的局限,未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面,均有不足。到了云服务时代,充分利用云基础设施的底层能力,提供定制化的数据库产品。
• 云原生,与之前的云服务架构不同,这一阶段产品将更为充分地利用云基础设施的能力,通过多层资源解耦,可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看,金融机构逐渐把业务和技术向云原生演进,实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持,提供高效、弹性调度能力,同时需要兼顾开发运维和敏捷度。

2. 多云方向

云作为未来主流的资源供给方式,多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构,满足在多云之间提供数据服务能力,摆脱单一供应商的弊端,是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8s 的部署、服务提供与统一运维能力等。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论7 条评论

hanfeng_twthanfeng_twt数据库架构师, SphereEx
2022-05-25 17:32
你好,感谢回复。你提到的两点:
ghl116ghl116软件开发工程师, 兴业数金
2022-05-25 10:10
感谢分享,数据库作为重要的基础设施,在选型和建设方面需要慎之又慎。本文对于银行进行分布式数据库的选型提供了非常好的参考。另外,目前数据库云原生方面,我了解到有些企业担心在生产环境通过K8s来部署管控数据库Mysql会有性能损失,所以都不建议数据库Mysql上K8s。 您对于这种情况怎么看?

ghl116@hanfeng_twt 好的,谢谢

2022-05-25 21:12

hanfeng_twt@ghl116 容器化对于数据库意义需要想清楚,对于部分金融业内的互联网业务是可以考虑的。

2022-05-25 17:30
匿名用户
2022-05-24 14:31
写得非常好,分布式数据库应用范围广,给分布式数据库应用提供了思路。谢谢!
匿名用户
2022-05-24 09:28
感谢分享,为我们数据库建设和规划提供了很好的思路,尤其是分布式数据库在金融行业的应用场景,对我们数据库选型很有参考意义,先收藏再仔细研究。
zy7227zy7227网络工程师, bank
2022-05-23 14:46
感谢分享,对于我们建设和规划提供了思路,有很好的借鉴意义,同时单从技术路线发展来看,也是未来要经历的事情,先学习一下。
wanggengwanggeng系统运维工程师, 某银行
2022-05-18 08:51
感谢感谢分享,可以很好的指导我们在选型分布式数据库如何选择,提供指导思想,收藏了!
zhmwangzhmwangPD, OceanBase
2022-05-15 16:31
韩老师,您好,关于您说的2个小点,我有不同的意见: 1 分布式架构,自然会带来分布式事务的问题 目前OceanBase通过表级别数据不打散,通过设置Primary Zone以及Table Group的方式,可以将事务固定到单台机器上,从而实现分布式框架下的非分布式事务,主要的消耗本质是在redo 日志的Recover。 2 分布式数据库,多采用存算分离架构 这个点确实如此,国内大部分使用分库分表方案和TIDB都使用了本方案,您可以考察一下OceanBase, 对于OLTP类型的应用,OB通过LSM Tree架构以及内存改造和优化,提升Transaction的响应速度,这个是Oracleh ADG /DB2 HADR架构都无法比拟的。另外OceanBase是MPP架构,根据以上所说,天生具体OLAP能力,您也可以一并考察一下。

zhmwang@hanfeng_twt 韩老师,关于第一点分布式事务: OB的数据分布策略是按照表分区来实现的(单表的话即为一个分区,因此对单表的操作不会产生分布式事务,目前OB建议单表数据量高于100G(OB自身通过压缩算法,大概压缩比为5-10倍,即再Oracle/DB2/MySQL上单表高于500G),再进行分区设计,客户可根据实际业务情况进行考量)。因此从设计角度来看,需要区分业务规模: 对于小业务(按照OB的设计理念),大中型企业内部 大概约70-80%的业务都可以使用单表实现。而对于分区表的场景,摘自官网:OceanBase 通过引入表格组(table group)来尽可能地减少分布式事务。表格组用于聚集经常一起访问的多张表格。例如,有用户基本信息表(user)和用户商品表(user_item),这两张表格都按照用户编号哈希分布,只需要将二者设置为相同的表格组,系统后台就会自动将同一个用户所在的 user 表分区和 user_item 表分区调度到同一台服务器。这样,即使操作某个用户的多张表格,也不会产生跨机事务。2 对于分片不均的问题,OB提供非模板化二级分区,即对发生了数据倾斜的分区单独进行分区。具体可以参考:https://www.oceanbase.com/docs/enterprise/oceanbase-database/oceanbase-database/V3.1.2/create-a-level-2-partition-table-1。同时OB也提供类似复制表功能(传统的小的维度表复制到所有分区的方式)来减少分布式事务。3 对于OLTP,OB基于LSM-Tree,属于准内存处理,性能上肯定是超过传统数据库的,这个在内外部客户的使用上已经证明过啦。4 对于OLAP,OB属于MPP架构,需要架构师对于业务有更深层次的理解,合理的进行分区设计,使用tablegroup以及复制表等,尽量减少分布式事务,目前类似的资料内部正在整理中,预计很快会对外公布。

2022-05-29 09:29

hanfeng_twt@zhmwang 感谢回复,您提到的两点: 1.分布式事务,如果OB能将数据分片固定到某一台机器上,减少网络开销,那是不错的实现。具体细节不了解,可提供说明。此外,这一方式当面临分片不均匀、分片过大的情况等,还是会带来跨服务器的处理吧。 2.对于OLTP和OLAP方面,OB的能力可以多介绍下,我也学习下

2022-05-25 17:35
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

X社区推广