《金融科技产业联盟:2023金融开放平台数据库转型白皮书(54页).pdf》由会员分享,可在线阅读,更多相关《金融科技产业联盟:2023金融开放平台数据库转型白皮书(54页).pdf(54页珍藏版)》请在三个皮匠报告上搜索。
1、金融开放平台数据库转型白皮书金融开放平台数据库转型白皮书金融科技产业联盟金融科技产业联盟2022023 3 年年 0 09 9 月月1主编单位主编单位金融科技产业联盟工行华为2前前言言“十四五”规划提出“加快数字化发展”的总体布局,金融开放平台业务系统数据库作为金融信息系统的关键基础设施,对于突破金融效率瓶颈、释放金融创新空间、提升金融服务水平、支撑金融行业数字化转型和高质量发展具有重要而深远的意义。为进一步推动数据库技术在金融行业的应用与发展,北京金融科技产业联盟联合工行等金融机构及华为,调研金融行业开发平台数据库技术应用现状、分析金融行业数据库架构转型中的重点和难点应用场景,编写了本报告,
2、希望可以为金融同业及相关领域从业者提供参考。本文主要聚焦于银行业为主的金融领域开放平台业务系统对关系型数据库的应用转型:对数据库的技术选型,提出以集中式+分布式双栈部署架构,满足不同业务场景需求。对于大部分的稳态业务,可以以集中式部署为主,满足快速原地平台的转型需求。对于部分敏态业务、有弹性扩缩容需求的场景,可以分布式部署。对涉及数据库转型各方面,包括同城双集群容灾、对象迁移、数据迁移、数据校验、测试验证、并行方案等,是一个整体解决方案的研究,是解决金融行业在分布式数据库迁移过程中的实际问题,提供整体迁移方案技术指导。目录一、金融开放平台业务系统现状调研 5 页.1(一)金融行业业务场景的数据
3、库部署情况.11、金融行业应用数据库技术发展历程.12、金融行业应用数据库现状.2(二)传统数据库在金融行业应用高可用架构.3(三)传统数据库在金融行业存量情况:存储过程,函数、类型.4(四)转型挑战.4二、转型目标和总体思路.6(一)转型目标.6(二)解决思路.7三、数据库架构技术路线及在金融行业的应用(庞毅、怎么选)5 页.8(一)典型核心应用场景数据库需求.81、时效性要求高的业务.82、业务流量变化大的业务.83、可用性要求高的业务.84、混合负载应用的业务.9(二)国产化数据库技术路线分析.91、集中式.102、分布式.12(三)选型建议.141、集中式/分布式.142、高可用容灾.
4、16四、开放平台应用转型(赵耀、怎么干)15 页.17(一)规划设计.171、业务与数据库适配规划设计.172、迁移步骤与迁移计划的规划设计.203、测试方案规划设计.244、运维方案规划设计.24(二)业务改造及测试.251、业务改造过程.252、业务测试过程.25(三)数据迁移.251、数据迁移设计.252、数据迁移执行过程.28(四)上线割接.281、割接演练.282、正式割接.29(五)运维实施.301、运维保障.302、异常处理情况.30(六)风险防范.311、实际及潜在风险的防范.312、路径上先外围后核心.313、漏洞及安全.31五、工行转型实践 庞毅 8 页.32(一)现状(G
5、RAM 应用?).32(二)挑战.32(三)路径选择.331.原位替换,平滑迁移.332.分布式改造.34(四)方案规划.341.精简模式性能、容量和高可用能力增强.342.部署架构选型.36(五)迁移和同步,单/并轨.371.构建自动化迁移工具,提升迁移转换成功率.372.提升异构数据库数据迁移工具能力.38(六)测试.381.自动化测试工具.382.比对测试工具.393.覆盖率统计工具.394.流量回放工具.39(七)运维.401.待工行补充实践.40(八)效果总结:迁移结果,运行多次时间,运行效果.401.提升 GaussDB 性能容量及高可用能力.412.提升异构数据库数据复制工具的数
6、据同步能力.413.提升 Oracle 数据库到 GaussDB 的自动化迁移成功率.414.自动化测试工具链建设.41(九)未来规划.42六、未来展望5 页.42(一)内存池化,全栈解耦,追求极致的弹性伸缩.42(二)基于内存池的 HTAP,释放软硬协同的潜能.43(三)智能弹性,实现更细粒度、更精准的资源调度.44(四)全场景智能数据库,发挥 AI 与数据库的融合价值.45(五)结合全密态和防篡改技术,保障云上数据安全.47参考文献.481一、一、金融开放平台业务系统现状调研金融开放平台业务系统现状调研(一)(一)金融行业业务场景的数据库部署情况金融行业业务场景的数据库部署情况1、金融行业
7、应用数据库技术发展历程、金融行业应用数据库技术发展历程改革开放后,我国金融行业面对信息技术革命滚滚大潮,积极学习和吸收世界金融行业技术革新成果,告别了手工记账时代,开启电子化、信息化建设进程,带来了金融行业工作方式和业务处理的巨大变革。随着金融体制改革不断深化,开始推动金融系统纵向统筹管控,金融行业走向数据大集中的发展道路。工行、农行、中行、建行等国有大行于世纪之交率先开启集中式金融信息系统技术体系建设,宣告中国大型金融机构步入集约化经营时代。1999 年,工商银行启动“9991”数据大集中工程,将全行 30000 多家下属机构经营数据全部集中到南北两个数据中心,实现数据共享大集中处理模式。这
8、一时期,商用集中式数据库以其高效的数据存取效率、优异的系统稳定性,很好地契合了金融行业对数据存储管理的需求,为金融行业实现信息集中统计处理、财务集中改革、风险集中控制、业务集中管理等奠定了坚实的技术基础。商业集中式数据库以其较强的功能黏性、优秀的系统稳定性、良好的软硬适配能力,目前集中式数据库在金融业总体占比仍高达 89%。尽管银行业数字化转型推进更快,分布式数据库应用更多,但集中式数据库应用占比仍接近 80%,证券和保险业占比均超过 90%。详细情况如图 3 所示:2图而 MySQL、PostgreSQL 等开源数据库近些年逐渐从金融外围系统向金融核心业务延伸。为应对数字化转型带来的高并发、
9、海量数据、超高峰值等挑战,近年来各金融机构纷纷开展分布式数据库的探索,多技术路线并行推进试点,分布式数据库在金融行业应用规模预计将有明显提升。2、金融行业应用数据库现状、金融行业应用数据库现状传统商业集中式数据库以其较强的功能黏性、优秀的系统稳定性、良好的软硬适配能力,目前在金融行业的存量应用仍占据较大的份额。而国产数据库和 MySQL、PostgreSQL 等开源数据库近些年逐渐3从金融外围系统向金融核心业务延伸。为应对数字化转型带来的高并发、海量数据、超高峰值等挑战,以及传统商业数据库迁移的难题(如 Oracle 部署规模大、存储过程复杂等),近年来各金融机构纷纷开始进行开展分布式数据库的
10、探索,多技术路线并行推进试点,分布式数据库在金融行业应用规模已经有明显提升。(二)(二)传统数据库传统数据库在金融行业应用高可用架构在金融行业应用高可用架构传统数据库具备多种高可用方案,满足金融客户不同业务场景需求。如 Oracle 的 RAC、ADG 和存储复制方案,满足多中心高可用需求。该方案采用基于 FC-SAN 外置存储的存算分离架构,底层以共享存储(Shared Storage)的模式对接企业级存储盘机保证数据的高可靠,计算层部署多个无状态 Oracle 实例(RAC),通过缓存融合技术(Cache Fusion)实现计算实例多读多写。本地高可用基于 RAC 实现故障快速切换,实现
11、RPO=0,RTO 秒级,同城通过 ADG(ActiveDataGuard)进行数据同步,通过集中存储磁盘复制同步日志确保同城故障切4换时数据完整性,实现 RPO=0,RTO=1030 分钟。目前 Oracle 方案的成熟度高,在金融行业应用广泛,内核稳定,各类技术方案经过充分生产验证,具备完善的监控告警、高可用容灾及配套工具等运维体系。随着信创转型工作的重要性和紧迫性逐渐加大,大量基于 Oracle 数据库的应用面临数据库国产化转型的压力日益增大,而大型业务应用的 Oracle 数据库具有请求峰值大、数据量大和存储过程体量大等特点,应用转型对数据库系统部署方案提出更高的性能容量、高可用和稳定
12、性的需求。(三)(三)传统数据库传统数据库在金融行业存量情况:存储过程,函数在金融行业存量情况:存储过程,函数、类型类型以工行为例,目前使用 Oracle 数据库的总行应用接近 200 个,其中 AB 类应用超过 90 个,合计使用了超过 36 类 Oracle 对象、24 类基础数据类型、166 个系统内置函数、67 个系统高级包和 168 个系统视图,存储过程总行数超过 2 亿,数据库对象总数量超过 3000千万,Oracle 数据库转型工作面临巨大挑战。(四)(四)转型挑战转型挑战缺少机制和指引保障,选型难(怎么选),迁移难(怎么干)目前,在国内政策和国际环境的双重作用下,国产数据库百花
13、齐放,起步较早的国产数据库厂商已经在稳定性和性能上可以与国际大厂持平,并且在金融、政府等重要行业得到多次验证。面对如此众多的数据库厂商及其技术发展路线和部署架构,金融行业亟需解决如何5进行数据库的选型。除了数据库的选型问题外,开放平台应用转型还需要回答这三个核心问题:一是解决高可用问题,如何打消客户对系统可用性可靠性的疑虑。在金融业务创新、应用逻辑重构的过程中,也在不断实现底层系统架构的迁移和迭代,随着金融行业数字化转型不断深入,存量的开放平台传统应用往往具有历史比较久远、业务长期稳定、关联应用较多等特点,必须有效控制迁移风险,保障迁移过程中应用服务平稳运行。二是解决性能问题,如何解决客户对数
14、据库、以及构建其上的应用性能的疑虑。开放平台传统应用与数据库高度耦合的优势就在于减少了系统组件之间的交互开销,此类应用的业务场景往往对系统性能有较高要求,需在满足业务性能指标要求的前提下开展数据库架构转型。三是业务的平滑迁移,如何降低整个过程的实施成本和风险。部分商业数据库产品的高级特性和软件包存在知识产权壁垒,国际化金融机构在数据库迁移过程中需更加重视目标数据库产品的知识产权风险,保障技术供应链的安全合规和稳定可靠。完全兼容商业数据库、无需应用层改造的迁移方案是否适合金融行业大规模推广使用,目前业界尚无定论。6二、二、转型目标和总体思路转型目标和总体思路(一)(一)转型目标转型目标(“两有两
15、不两有两不”目标)目标)安全有保障,容灾有提升,功能不受损,服务不降级一是安全有保障。金融级数据库通常用于存储各行业的核心数据,其任意一笔数据错乱、丢失将带来严重影响。转型过程要保证数据库软硬件系统的整体安全可信,即使在某些软件故障、硬件异常的情况下,数据库都应保证数据的强一致性。二是容灾有提升。金融级数据库为确保在异常情况下数据不丢失、不错乱,需要具备多地多中心的容灾快速恢复能力。转型过程可以通过数据库软硬件协同的系统工程,实现系统级灾备能力及指标提升,例如双中心双集群容灾 RPO=0,RTO60 秒等。三是功能不受损。金融级数据库经过近二十年应用和演进,已经有大量的存量数据库部署,需要充分
16、考虑当前已经使用的功能,尤其是应用开发使用的存储过程等特性,通过提升存储过程的兼容性,简化转型的工作量,可以加快转型的时间节奏。四是服务不降级。金融级分布式数据库服务于涉及国计民生的重要业务系统,其对运行连续性要求异常严格。数据库作为业务系统的基础,其通用的可用性要求在 5 个 9 以上。转型过程可以充分借鉴传统数据库的高可用设计,例如 Oracle 数据库的 RAC、ADG、存储复制等高可用特性。7(二)(二)解决思路解决思路(“四化四化”思路)思路)方案体系化,工艺标准化,工具链条化,经验资产化一是方案体系化。二是工艺标准化。三是工具链条化。四是经验资产化。对应挑战 逐步建立完善的机制和保
17、障体系(单/并轨,回退、测试),怎么选(按场景目标架构以集中式+分布式 集中式为主)对数据库的技术选型,提出以集中式+分布式双栈部署架构,满足不同业务场景需求。对于大部分的稳态业务,可以以集中式部署为主,满足快速原地平台的转型需求。对于部分敏态业务、有弹性扩缩容需求的场景,可以分布式部署。对涉及数据库转型各方面,包括同城双集群容灾、对象迁移、数据迁移、数据校验、测试验证、并行方案等,是一个整体解决方案的研究,是解决金融行业在分布式数据库迁移过程中的实际问题,提供整体迁移方案技术指导。8三、三、数据库架构技术路线及在金融行业的数据库架构技术路线及在金融行业的应用应用(一)(一)典型核心应用场景数
18、据库需求典型核心应用场景数据库需求1 1、时效性要求高的业务时效性要求高的业务高并发且多变的业务场景对数据库的时效性要求越来越高,当业务负载比较大的时候,以业务报表查询为例,高峰时段的业务量是平时业务的十倍左右。为了满足查询效率,需要数据库却可以快速扩容,满足业务高峰需求,很好地支持业务的快速变化。2 2、业务流量变化大的业务业务流量变化大的业务大多数传统行业业务增量相对稳定、容易规划所需要的资源容量,与之不同的是,互联网这类业务随时可能出现流量激增的情况,要求国产数据库具备很强的可扩展性,可以根据业务负载灵活调动资源,随时扩缩容,3 3、可用性要求高的业务可用性要求高的业务需要以下几个方式来
19、保证核心业务的可用性。一是同集群的故障节点主备切换。在提供高性能的同时保证了系统的高可用性和业务的连续性。二是跨可用区、跨地域部署的容灾能力。三是通过自动的全量增量备份、数据快速恢复、恢复到任意时间点等方式保障多层次备份恢复。94 4、混合负载应用的业务混合负载应用的业务由于金融业务发展而带来的复杂多样的业务变化,导致大量不同业务类型的数据存放在一起。例如交互系统和报表系统,一种是 OLTP 应用场景,一种是 OLAP 应用场景,如果数据存放在一起,就需要数据库既具备事务能力,又需要在分析时具备高效性。需满足用户多类数据存储及在不同业务场景下的处理需求。(二)(二)国产化数据库技术路线分析国产
20、化数据库技术路线分析数据库的架构分类维度很多,按数据操作的模式可分为集中式和分布式数据库(指数据分布而不是分布式技术),按计算和存储绑定关系分为 Shared Storage/Share Nothing/Share Everything,按数据存储方式分为存算一体和存算分离。数据库的技术架构非常复杂,各种维度相互交叉。比如集中式数据库这一概念为分布式数据库出现后,为进行区别而产生的人为归类。而集中式数据库在分布式数据库产生前后,或多或少都在使用分布式技术。比如 ORACLE RAC 的“网格计算”,MYSQL MGR 基于 Paxos 协议实现数据一致性保障等。对于数据库迁移替换,关注的“分布
21、”与集中重点在于数据的分布是否需要跨实例、需要采用分布式事务等方面。由于集中式和分布式数据库对数据库迁移影响巨大,因此在架构定义上,本文重点按数据操作方式的维度来将数据库分为“集中式”和“分布式”两大类,后续高可用部分的讨论中会设计其他一些分类维度。101、集中式集中式本文的集中式数据库的共同特点是,数据库访问同一份数据(或数据副本),数据集中存储在一起。从使用体验上看,应用看到的数据在逻辑上是可以统一访问的,可以做到不像分布式数据库那样要考虑分片、分布式事务等问题,因此可规避分布式事务的性能影响,更好支持存储过程、多表关联、复杂查询,应用开发、存量业务迁移,运维都相对容易。传统集中式数据库包
22、括主备 HA,主备多副本,共享存储多写等架构,在去 O 过程中,出现了一些引入分布式技术或从分布式数据库发展而来的分布式精简模式数据库也属于本文定义的集中式数据库。(1)传统集中式传统集中式一、主备 HA11此架构只有主实例工作,数据为一份,通过 HA 软件实现服务器高可用,通过外置存储实现数据持久化保障。二、共享存储多写此架构可实现多实例同时读写,性能、可靠性和扩展性有很大提升。常见的 ORACLE RAC 即属于此架构。三、主从多副本此架构采用数据库日志同步回放方式生成副本来实现高可用,实现简单,大量被开源数据库使用。备节点可作为只读节点使用。由于12日志回放受业务压力、网络抖动影响较大并
23、易出现脑裂问题。(2)精简模式精简模式针对集中式数据库的可靠性、性能、容量等方面问题,部分厂商进行了优化,以工行使用的 GaussDB 精简模式为例,通过分布式一致性协议解决了日志复制的可靠性问题,通过对服务器性能优化提升了单库性能,通过使用外置存储打破了容量限制,并通过与存储配合实现本地数据持久化增强和解决了同城双集群容灾 RPO 无法为 0 的难题。2、分布式分布式本文的分布式数据库的共同特点是:数据分散存储在不同的数据节点,通过分布式技术进行并行处理,提升数据库的并发性能和容量,并通过分布式事务实现事务强一致性。分布式数据库主要分为分布式中间件和原生分布式两大类。13(1)分布式中间件分
24、布式中间件分布式中间件架构由分布式中间件+单体数据库组成。分布式中间件实现数据的路由、分布式事务等操作,单体数据库多为单个集中式数据库。(2)原生分布式数据库原生分布式数据库原生分布式数据库由分布式事务调度管理和数据库引擎等组成,通过分布式一致性协议保障副本数据一致性。相对分布式路由架构对14分布式事务支持更好,存储引擎多为自主开发便于实现下推等特性提升能力。(三)(三)选型建议选型建议1、集中式集中式/分布式分布式与金融行业使用的商业集中式数据库相比,分布式数据库产品发展时间普遍较短,技术成熟度和产品稳定性有待金融行业生产环境长时间平稳运行的检验,目前还没有绝对优势产品出现,金融应用场景面临
25、多种数据库产品选择的局面还将持续。考察金融行业数据库技术应用发展历程,从商用数据库 DB2、Oracle、SQL Server 到开源数据库 MySQL、PostgreSQL,以及文档数据库、大数据平台的引入,再到近些年繁荣发展的各种分布式数据库产品,金融行业使用的数据库产品和技术日趋多样化,这是金融业务不断创新发展在技术层面的体现。随着金融行业数字化转型逐步深入开展,金融应用持续创新,金融服务不断优化,金融业务场景的广度和深度都大幅扩展,对金融数据的使用方式日益多样化,单一数据库产品已难以支撑金融行业所有应用场景。多种数据库产品并行发展的现状将在金融行业持续存在,需针对具体应用场景对数据库能
26、力的需求和侧重,选择合适的数据库产品。金融行业数据库架构转型的重点难点场景,使得分布式数据库成为业界关注的焦点,但集中式数据库的应用场景并未消失,集中式与15分布式数据库各有其适用的应用场景。分布式数据库解决了集中式数据库性能容量扩展能力不足的问题,相应地也在系统层和应用层付出了多方面的成本。在系统层面在系统层面:从专用大型机服务器迁移到通用服务器,单体设备可靠性降低,采用分布式架构可以实现更高的可用性和扩展性,同时也带来冗余备份、网络交互等方面的开销,硬件节点使用规模快速扩张为大型数据中心的节能减排和机房规划带来较大压力。大规模分布式集群的系统复杂度呈指数级上升,必须具备与之适配的运维管理能
27、力作为支撑,需要在运维管理配套的系统能力建设和人才储备方面加大投入。在应用层面在应用层面:根据业界实践,将分布式系统完全封装成一个逻辑单库的解决方案虽然能够简化应用开发模型,但系统性能开销太大,因此适用场景有限。为充分发挥分布式架构优势,应用层也需要投入更多的研发设计成本,一是需要进行合理的数据分片设计,通过高内聚低耦合的数据规划,尽可能减少跨节点访问;二是需要在系统架构设计中充分考虑节点故障的容错及柔性事务的处理。综合来看,集中式与分布式数据库的使用成本集中式与分布式数据库的使用成本可表示如下图:16图 6 数据库综合使用成本示意图因此,对于小型系统和业务规模稳定的应用对于小型系统和业务规模
28、稳定的应用,可优先考虑集中式可优先考虑集中式架构能否满足要求架构能否满足要求。基于同样原因,大多数分布式数据库产品都支持大多数分布式数据库产品都支持集中式单体部署模式,在业务规模较小时规避分布式架构的成本开集中式单体部署模式,在业务规模较小时规避分布式架构的成本开销,同时保留了随业务规模增长而横向扩展的灵活性。销,同时保留了随业务规模增长而横向扩展的灵活性。2、高可用容灾高可用容灾满足金融行业在高可用容灾、数据一致性、业务连续性和系统可扩展等方面的更高要求,提升分布式环境下对应用研发和系统运维的支持能力,是金融级数据库最核心的竞争力。例如,分布式数据库产品不仅需要提供金融级高可用能力,在节点级
29、/园区级异常故障场景下保证数据服务可用性,还需充分考虑新旧数据库系统迁移期间、数据库版本升级期间、云底座或网络等基础设施升级变更期间、应用版本数据库对象投产期间、大批量作业执行17期间等各类实际落地的应用场景,提供完整的业务连续性解决方案。四、四、开放平台应用转型开放平台应用转型(一)(一)规划设计规划设计1、业务与数据库适配规划设计业务与数据库适配规划设计(1)规划设计原则)规划设计原则分布式数据库集群设计的基本原则主要包括:高性能、高可用、高安全、易维护等,具体内容如下:高性能高性能:多版本并发控制、查询优化、多级缓存、存储过程缓存等;高可用:高可用:快速启动、双机同步、故障切换等;高安全
30、高安全:访问控制、密码策略、加密连接、数据加密、敏感数据处理、操作审计等;易维护易维护:一键安装和升级、低成本迁移、图形化管理工具、日志信息可定制、智能备份恢复等。(2)数据库规划)数据库规划开放平台业务系统数据库可以根据业务特征和支撑能力,选择集中式部署和分布式部署。集中式部署以稳态业务场景为主,具备架构18简单,易部署易运维,兼容存储过程,应用不需重构易迁移,减轻数据库中的网络交互,时延低等特点;分布式部署以敏态业务场景为主,具备并发高,适配业务量持续快速扩展,容量大,易水平扩展,需要应用做数据分区访问调优和改造等特点,建议优先选择集中式部署模式。集中式部署在不同园区部署独立数据库集群,同
31、城间通过磁盘级复制实现增量日志强同步,异地园区间通过异步方式实现增量日志同步,形成多中心多活的部署方案,实现同城园区级故障场景下 RPO=0、RTO10T 存储容量,具备承接大型业务系统能力。数据库事务性能呈现线性增长趋势,物理服务器 CPU 资源使用率为 60-70%时,TPMC60 万(TPS2 万)。通过多集群部署,不同集群可使用不同版本,具备业务不中断前提下版本灰度升级能力,同时支持大型业务系统停机投产时提供基本服务的轻量级解决方案。19分布式数据库为提升数据库版本升级和故障期间的服务连续性,可采用同城单集群方案,通过集群内部日志强同步,实现集群间切换RPO=0,RTO 60 秒。(3
32、)业务改造规划)业务改造规划业务改造主要是基于源数据库和目标数据库的 SQL 语法、接口驱动和数据库工具等差异,对业务进行适配改造。业务改造主要包括如下内容:20 提供源数据库和目标数据库的差异化列表;提供 SQL 录放工具,输出 SQL 回放报告。回放报告主要包含如下内容:慢 SQL 及异常 SQL,结合资源、性能给出慢 SQL 指标数据,SQL 兼容性;根据数据库的差异和 SQL 兼容性列表,梳理出业务的改造点;在数据库团队的支撑下,完成业务 SQL、驱动和数据库工具等的业务改造替换;完成改造后的业务系统的适配测试和性能测试等。(4)数据库与周边系统对接规划)数据库与周边系统对接规划除了业
33、务系统需要适配新数据库外,配套的周边系统和工具同样需要适配,比如监控、告警、备份、审计系统等。主要工作有:梳理原数据库与周边系统的对接列表;针对不同的周边系统,设别出需要替换的模块;数据库驱动(jdbc、python 等)替换、数据库工具(客户端、导入导出、数据迁移等数据库工具)原数据库和新数据库保持并存运行,业务逐步从源库切换到新库。2、迁移步骤与迁移计划的规划设计迁移步骤与迁移计划的规划设计迁移总体工作流程包括:21 迁移评估:通过对现有数据库对象和现有业务系统调研,整理分析调研结果,输出数据库迁移可行性评估报告等;迁移规划设计:组建数据库迁移团队、数据库迁移总体方案设计、数据库迁移计划制
34、定、数据库迁移实施方案设计等;迁移实施:结构迁移、数据迁移、数据校验、业务适配和测试、性能调优、迁移演练、上线割接等;迁移验收:试运行保障、项目验收等。(1)迁移评估)迁移评估根据项目需求,完成数据库迁移评估,完成数据库迁移可行性分析,确定数据迁移内容与范围,确认客户业务可接受的影响时间。数据库调研主要包括数据库信息调研、业务系统信息调研:数据库信息:数据库版本、实例个数、用户角色权限信息、数据总量、数据增量、表信息、业务 SQL 信息、数据库并发数、数据库容灾备份机制及要求、第三方系统对接(ETL)等;业务系统信息:业务系统架构、业务时延要求、业务系统并发要求、业务系统接口、业务系统数据加载
35、方式等;可行性评估:应用 SQL 评估、不支持的 SQL 如何改造;集群规模评估:并发量、IOPS。(2)迁移规划设计)迁移规划设计根据迁移调研和评估结果,完成数据库迁移总体方案设计。在保22障业务逻辑不变的情况下,需对数据库进行端到端的迁移,包含对数据库对象迁移、性能保障、数据同步、数据校验、源/目标差异及竞争力、运维保障等方面进行详细分析与阐述。数据库对象迁移关键功能包括:对象采集、预迁移评估(对象兼容性、SQL 兼容性、语法改造建议、目标库选型、目标库规格及成本、迁移工作量、源库风险、迁移风险)、迁移实施、测试验证、自动上线。性能保障关键功能包括:SQL 等价改写,SQL 诊断与优化、实
36、时性能监控。数据同步关键功能包括:数据全量迁移、数据增量同步。数据校验关键功能包括:全量离线数据校验、增量实时数据校验。源/目标差异及竞争力分析包括:目标库架构、关键技术分析、容灾方案分析、组网方案分析、数据库定义、数据类型差异、语法差异、数据库功能、性能、稳定性等多方位分析。运维保障关键功能包括:数据库巡检、数据库管理、数据库监控。根据以上各项细节,具体迁移规划设计如下:明确不同对象的迁移方式。通过使用 DRS 迁移工具完成从 Oracle 到 GaussDB 的数据迁移,存储过程等高级对象需要在业务适配阶段手工迁移;根据业务维护时间窗的长短,明确数据的迁移场景。全量迁移(停机)或全量+增量
37、(在线)。根据数据库迁移总体方案,完成数据库迁移实施方案设计和制定迁移计划。23 根据数据库迁移总体方案,细化操作步骤,输出可操作的数据库迁移实施方案;在华为实验室完成数据库迁移实施方案技术验证;结合客户业务规划,根据业务迁移的紧急程度及数据库迁移工作量大小,制定数据库迁移计划。(3)迁移实施)迁移实施根据数据库迁移实施方案,完成数据库迁移实施,主要工作内容如下:迁移工具和目标环境的安装配置;运行迁移工具完成结构迁移和数据迁移;手工适配迁移存储过程等高级对象;应用系统的业务适配;迁移后的性能调优;数据迁移测试,验证数据库迁移技术可行性和完整性。(4)迁移验收)迁移验收数据迁移完成初期,完成数据
38、库试运行保障,及时解决客户业务运行过程中出现的问题,保证数据库高效、平稳运行。数据库迁移完成后,配合客户完成数据迁移验收。验收主要关注点数据一致性验收:数据是否全部迁移到 GaussDB、迁移前后数据是否一致。243、测试方案规划设计测试方案规划设计为保障业务系统切换到新数据库后功能和性能满足现网生产运行,需要通过一系列的测试活动验证。主要的测试活动如下:功能测试、接口测试、数据库迁移测试、性能测试、UAT 验收测试。通过测试达成以下目标:功能测试:覆盖业务应用系统的全量功能。接口测试:针对业务系统所有相关的第三方进行 E2E 测试,与功能测试互补,完成真正的 E2E 测试。数据库迁移测试:完
39、成数据一致性和正确性验证。性能测试:验证应用系统是否能够达到客户提出的性能指标,同时发现系统中存在的性能瓶颈,优化系统。UAT 验收测试:功能测试覆盖和客户达成一致的交付范围,覆盖主要第三方系统。测试过程以客户为主导,验证结果主要以业务检查的方式进行测试。4、运维方案规划设计运维方案规划设计运维保障目标是系统上线到系统转维的过程,保证各个环节按照流程规范高效运作,支撑项目平稳上线,保障项目商用后系统健康稳定运行,问题快速清理,局点快速完成内部转维。25(二)(二)业务改造及测试业务改造及测试1、业务改造过程业务改造过程业务整体改造包含数据库改造及应用改造。数据库改造包含数据库采集、迁移评估、语
40、法转换、结构验证、性能调优、迁移上线等几个核心步骤;应用改造包含应用数据采集、迁移评估、语法转换、改造上线等核心步骤。2、业务测试过程业务测试过程业务测试过程可包含以下步骤:全量数据迁移,增量数据同步,数据一致性校验,业务语法迁移,业务性能调优,业务迁移文档,应用功能研发,业务功能测试,业务性能/压力测试,上线前方案模拟测试,版本交付,版本投产,业务试点上线,系统上线,原系统退库。(三)(三)数据迁移数据迁移1、数据数据迁移设计迁移设计数据的迁移根据不同的场景可分为,全量数据迁移、增量数据迁移和全量+增量同步迁移。(1)全量)全量数据迁移数据迁移全量数据迁移就是指将源数据库中的业务数据全部迁移
41、到目标库,这个过程一般采用批量的方式进行数据的同步,在同构数据库迁26移的场景中,可以采用数据库的备份和恢复功能,也可以采用数据库自带的数据导出和导入工具,如 Oracle 的数据泵,这种方式比较高效。在异构数据库的全量迁移场景中,因为不同数据库之间的数据类型、存储格式等各不相同,上述同构数据库的迁移方式不再适用,一般采用数据库特定接口或 SQL 接口的方式进行迁移。基本迁移流程如下图:不同数据库提供了不同的数据导出/导入接口,如 pg 的 copy接口可以把数据导出成 csv 格式,也可以把 csv 格式的数据导入到 pg 库。数据的导出和导入经过缓存层,可以采用内存和落盘文件的方式。数据的
42、导出和导入过程均可以设计为并发模式,可以通过按表并发和表内按记录并发的方式提高效率。(2)增量数据迁移)增量数据迁移增量迁移是将源数据库实时变化的数据同步到目标库,实现增量迁移的方式有很多种,如基于时间戳的定时同步、基于触发器的增量同步和基于日志解析的实时同步,对比各种方式,基于日志解析的同27步方式无论从对源库的影响还是实时性都是最优的。基于日志的增量同步架构如下图所示:数据的抽取阶段用来获取源库实时变化的日志数据。解析阶段对抽取的日志数据格式进行解析,整合等操作。转换阶段对异构同步过程中的转换规则进行适配,输出转换后的结果。应用阶段将最终的数据应用到目标库。(3)全量)全量+增量增量迁移迁
43、移在整个数据迁移的过程中,源端数据库往往业务是不能停止的,需要做到源库无感知的数据迁移,同时保证数据的准确性,这就对全量迁移和增量迁移提出了新的要求,如何解决在源库持续变化的过程中,完成全量迁移,并且使得增量迁移能够对接上全量迁移的数据位点,不重不漏。不同的数据库提供了不同的机制,可以实现全量+增量的无缝衔接,如 Oracle 数据库提供了 scn 点机制,可以在进行全量迁移的时候指定 scn,当全量迁移完成后,再指定 scn 去进行增量同步。282、数据迁移执行过程数据迁移执行过程数据迁移的过程从时间的先后主要分为 4 个过程,如下图所示:对象迁移:首先将源库的数据库对象(表、存储过程,视图
44、等)迁移到目标库。全量数据迁移:对源库的当前存量数据进行迁移。增量数据迁移:从全量迁移的完成点,进行增量实时数据同步。数据校验:当增量数据同步无延迟,达到实时的时候,对两端数据进行比对,确保数据迁移准确。(四)(四)上线割接上线割接1、割接演练割接演练(1)割接要求)割接要求1)割接过程中不能停止业务;2)割接时间不能超过两个小时;3)保证割接数据的正确性和割接脚本的健壮性。29(2)割接演练)割接演练建议选割接演练和正式割接采用完全一致的流程:1)先中断业务(如果业务负载非常轻,也可以尝试不中断业务)。2)在源数据库端执行简单语句,若在 1-5 分钟内无任何新会话执行 SQL,则可认为业务已
45、经完全停止。3)监控数据同步时延是否为 0,若为 0 则必须稳定保持一段时间;4)进行割接前数据级一致性校验,建议进行全部数据比对;5)确定系统割接时机,业务系统指向新数据库,业务对外恢复使用,迁移完成。2、正式割接正式割接正式割接过程可能会碰到很多场景,存在跟种各样的问题,需要综合考虑,随机应变,割接过程经验总结如下:1)割接一定要预留足够的时间窗,各业务逐个进行割接,且务必选择业务低峰期进行割接;2)割接前一定要做完整的数据库备份,做好割接失败的回切方案;3)加强割接过程监控,提前梳理需要监控的基础指标和业务指标。30(五)(五)运维实施运维实施1、运维保障运维保障(1)数据库巡检)数据库
46、巡检重点客户的重点实例可以在运维平台设置巡检告警,告警处理人员会及时处理。大客户重大活动保障的时候会安排专人进行巡检保障。(2)数据库管理)数据库管理运维平台集成了实例侧的管理功能,可以查看实例的信息和对实例进行日常运维所需的操作,如:重建备库,重试创建、扩容等失败流程的功能。(3)数据库监控)数据库监控实例上的 agent 会定时把监控指标上传到监控系统,运维平台上可以展示出实例的各项指标。运维人员可以根据指标来对客户实例的问题来进行分析。2、异常处理情况异常处理情况日常接到告警或者接到客户的报障,运维人员会及时进行处理。处理完成之后,如果确定为问题,则必须提问题单跟踪,最终版本解决。之后会
47、总结成案例,在组内分享推广,提高异常处理的效率。31定期从案例中总结成应急预案,并且每月进行相关故障场景的演练,继续总结、持续改进。(六)(六)风险防范风险防范1、实际及潜在风险的防范实际及潜在风险的防范XXXXX2、路径上先外围后核心路径上先外围后核心XXXXX3、漏洞及安全漏洞及安全XXXXX32五、五、工行转型实践工行转型实践(一)(一)现状现状(GRAM 应用?)应用?)工商银行目前使用 Oracle 数据库约 1000 套,节点 3000 个。涉及总行应用接近 200 个,涵盖核心业务、渠道、前置、外联、管理与支撑等多类业务系统,其中 AB 类应用超过 90 个。合计使用了超过36
48、类 Oracle 对象、24 类基础数据类型、166 个系统内置函数、67个系统高级包和 168 个系统视图,存储过程总行数超过 3 亿,数据库对象总数量超过 3000 千万。(二)(二)挑战挑战工行 ORACLE 使用时间长,范围广,在转型中主要面临的挑战包括:存量存储过程多:为优化性能,大量业务逻辑在存储过程中实现,重构成本高,特别是大型业务系统,普遍使用多个 Oracle 库,存储过程行数达到千万级,如果全面进行分布式改造的工作量和难度都是难以想象的。业务模型复杂:很多业务数据不能简单通过主键访问,查询条件复杂、多表查询复杂 SQL 多,分布式改造后性能影响极大。性能要求高:大型业务系统
49、高峰期 TPS6000 笔/秒,单库 41T,对信创基础设施及数据库的性能容量提出了较大的挑战。可靠性能力不足:大小机可靠性能力强,迁移后硬件可靠性下降,33容灾方案不满足原有业务多级容灾能力尤其是高等级应用需求。兼容性:Oracle 的语法和函数包比较复杂,完全兼容工作量大,前期工具自动化转换率只有 70%,改造改造成本非常高。数据同步挑战大:大型业务系统高峰期超过 300G/小时数据归档量,对新旧系统双库并行期间的数据同步效率要求极高。测试成本高:缺乏自动化测试工具,存储过程迁移后,功能测试、性能测试工作量巨大。针对以上挑战,工行联合厂商进行公关,采用原位替换平滑迁移与分布式改造双线并行、
50、优化数据库基本能力、构建高可用架构、实现工具化自动化等方式完成改造迁移目标。(三)(三)路径选择路径选择为降低迁移难度,加快替换改造进程,针对当前信创数据库能力,工行根据业务的特性选择两条路径实现迁移:1.原位替换,平滑迁移原位替换,平滑迁移对有存量存储过程的业务,优先采用 GaussDB 精简模式进行平移替换,对于当前信创数据库并发性能无法满足的巨石类业务,优先考虑进行数据库拆分,保留存储过程,减少应用架构和迁移改造工作量。从业务形态来看,业务量增长稳定,业务逻辑复杂,对一致性要求高的传统业务多选择原位替换。选择集中式数据库采用原位替换的业务占 70%以上。342.分布式改造分布式改造对业务
51、增长迅速,可通过分片较理想实现并发、容量提升且无存量存储过程、复杂查询的业务,可进行分布式改造,采用分布式数据库替换。从业务形态来看,业务量增长较快,高峰业务量巨大的互联网类业务如渠道类应用、快捷支付类应用、秒杀类应用多选择分布式改造,这类业务总量不到 30%。(四)(四)方案规划方案规划1.精简模式性能、容量和高可用能力增强精简模式性能、容量和高可用能力增强大型业务系统的 Oracle 数据库有存储容量大、交易并发高、可用性等级要求高等特点。GaussDB 基于本地盘部署方案,单节点存储容量在 10T 以内,无法满足大型业务系统 Oracle 数据库 10T 以上的存储需求,同时,单集群 G
52、aussDB 容灾方案无法实现故障隔离。因此,针对大型业务系统的 Oracle 数据库转型,对标原主机 AB 站点双活方案,对 GaussDB 承载大型业务系统 Oracle 数据库转型的多集群方案开展技术攻关,最终实现以下目标:351、基于华为云裸金属环境部署,在华为云不同园区 REGION 中部署独立的存算分离架构的 GaussDB 数据库集群,同城间通过存储级复制实现增量日志强同步,异地园区间通过异步方式实现增量日志同步,形成了 GaussDB 多中心多活的部署方案,实现了同城园区级和 Region 级故障场景下 RPO=0、RTO0,双集群故障隔离,两集群可使用不同数据库版本,支持业务
53、不中断灰度升级,用于 3-4 级业务本地盘单集群双中心架构:RPO=0,同城数据中心单集群双活,但不支持故障隔离和灰度升级,用于 3-4 级业务本地盘单集群单中心架构:无容灾能力,用于一般业务37(五)(五)迁移和同步,单迁移和同步,单/并轨并轨1.构建自动化迁移工具,提升迁移转换成功率构建自动化迁移工具,提升迁移转换成功率工行大型业务系统中使用了几十类 Oracle 对象、基础数据类型和系统高级包,使用了上百种系统内置函数和系统视图,存储过程总行数达亿级,按照目前自动化迁移工具 80%的转换成功率,转型过程中工作量巨大、技术难度和复杂度极高,工行与厂商联合针对 Oracle 兼容性从自动化迁
54、移工具和 GaussDB 内核两方面开展技术攻关,最终参与技术验证的 Gram 应用和平台核心的转换成功率均提升到 95%以上,具体如下:2.应用各类型应用各类型 OracleOracle 对象语法转换成功率平均为对象语法转换成功率平均为 96.69%96.69%3.应用各类型应用各类型 OracleOracle 对象平均编译通过率为对象平均编译通过率为 99%99%4.存储过程手工修改率为 1.25%,平台核心的数据库代码近 80 万行,涉及 1688 个修改点,每个修改点平均约修改 10 行。整体修改代码约 16880 行,修改率 2.11%。5.平台核心各类型 Oracle 对象语法转换
55、成功率平均为 99.05%6.平台核心各类型 Oracle 对象平均编译通过率为 98.23%,7.平台核心应用存储过程手工修改率为 1.65%,平台核心的数据库代码近 199 万行,涉及 1642 个修改点,每个修改点平均约修改 10 行。整体修改代码约 16420 行,修改率 0.83%。382.提升异构数据库数据迁移工具能力提升异构数据库数据迁移工具能力目前行内主要使用的数据库增量数据复制工具通过抓取 Oracle解析的日志,重构成目标数据库兼容的 SQL 语句,并在目标数据库回放实现准实时的数据同步,该工具增量数据同步性能无法满足大型业务系统投产后双库并行阶段 Oracle 数据库到
56、GaussDB 数据库的增量数据同步需求,通过与厂商对数据同步工具进行研究、测试,和持续优化,新工具具备 300G/小时的增量数据复制性能,可满足大型业务系统高峰期增量数据复制需求。(六)(六)测试测试目前针对 Oracle 数据库,采用配套工具完成日常的存储过程测试。由于目前业界国产数据库配套测试设施不完备,针对存储过程的测试工作需要依赖人工操作完成,工作量非常庞大。为降低测试人力投入,提升测试效率和测试覆盖率,保证上线后业务功能完备并稳定运行,工行建设了高效的国产数据库自动化测试工具集,具体如下:1.自动化测试工具自动化测试工具参照 Oracle 原有的 UT Plugin 自动化测试工具
57、,基于 Watchman 自动化测试框架,根据功能需求按照等价类、边界值等常规测试方法编写自动化测试案例,通过 jenkins 完成案例调度执行。共执行自动化案例 97 个(其中 35 个核心功能批量),案例执行率和通过率均为 100%,有效节约了测试人力投入。392.比对测试工具比对测试工具基于存储过程比对、存储过程分支比对和 SQL 语句对比研发自动化比对测试工具,针对 Gram 应用分别进行了三期测试:一期测试针对Gram应用所有存储过程,比对测试工具自动生成4594个案例执行,每个案例对应一个存过;二期测试针对 Gram 应用所有存储过程的所有分支,比对测试工具自动生成 57947 个
58、案例,每个案例对应一个分支;三期测试针对 Gram 应用中涉及到转换对象的 SQL 语句,比对测试工具自动生成 2754 个案例,每个案例对应一条 SQL 语句。通过 Gram应用的实际测试验证,比对测试工具可以有效的发现了 GaussDB 编译器无法发现的语法错误问题,弥补当前阶段高斯数据库的能力,节约测试人力,为 Oracle 应用迁移提供自动化验证方案。3.覆盖率统计工具覆盖率统计工具研发通过打桩方式统计存储过程测试覆盖率的工具,结合比对测试工具,Gram 应用存储过程的测试覆盖率 100%,分支覆盖率 75%,达到了预期的覆盖目标,有效解决了测试过程中测试覆盖率统计问题,起到全面了解测
59、试过程的作用,有效保证了测试质量。4.流量回放工具流量回放工具通过技术攻关研发了交易录放工具,通过抓取 Oracle 数据库的流量在 GaussDB 数据库回放,目前可实现:流量抓取:通过在交换机上配置端口镜像,使用旁路模式把 Ora40cle 端口上的流量复制到另一台服务器 B 上,并在服务器 B 上部署 Agent 获取 TCP 网络包,根据 Oracle 网络协议解析出业务执行的 SQL信息,以 json 格式存储到 ElasticSearch 中。一致性流量回放:把抓取到的 SQL 按源库的执行顺序以事务的形式回放,确保 Oracle 回放库和 GaussDB 回放库中 SQL 的执行
60、顺序完全一致,只要有一端执行失败两个库都会进行回滚操作,因此可以通过回放完成之后的数据对比,验证 GaussDB 对 SQL、存储过程的处理逻辑是否和 Oracle 一致。性能回放:抓取到的 SQL 按照源库执行的 SESSIONID 信息分发进行多线程并发回放,一端失败不影响另一端,这种回放方式能以接近实际生产业务压力的速度回放到目标库,从而对比 GaussDB 和 Oracle 在生产业务压力场景下的性能、可用性及可靠性表现。验证效果:选择 Gram 应用进行验证,共抓取 10W 条 SQL,全部回放成功,业务逻辑一致,无慢 SQL。(七)(七)运维运维1.待工行补充实践待工行补充实践(八
61、)(八)效果总结:迁移结果,运行多次时间,运行效果效果总结:迁移结果,运行多次时间,运行效果经过大量实践,工行形成了一套无需整体重构 Oracle 存储过程逻辑,低成本、高效可控的转型技术方案、配套工具和转型方法论,在确保大型 Oracle 应用转型的便捷性和稳定性、有序推进国产软硬41件产品替代和保障生产安全稳定方面具有重要的借鉴和指导意义,对金融同业的 Oracle 数据库转型工作有重要借鉴意义。1.提升提升 GaussDB 性能容量及高可用能力性能容量及高可用能力通过多集群部署版本,满足 5A 级应用同城双活+异地灾备的部署要求,实现同城 RPO=0,双集群故障隔离、灰度轮换升级提升了单
62、集群性能和容量规格2.提升异构数据库数据复制工具的数据同步能力提升异构数据库数据复制工具的数据同步能力通过技术攻关最终实现 300G/小时的增量数据同步,解决了大型业务系统 Oracle 数据库转型后的双向数据同步问题,降低了应用迁移难度。3.提升提升 Oracle 数据库到数据库到 GaussDB 的自动化迁移成功率的自动化迁移成功率通过工具自动转换+内核兼容的方式,将 Oracle 数据对象直接转成 GaussDB 数据库对象,转换正确率和编译通过均达到 95%以上,为存量的长期不动的老旧应用转型,提供了低成本、高效可控的转型方案。4.自动化测试工具链建设自动化测试工具链建设存储过程的自动
63、化试工具,和比对测试工具,实现基于代码的测试用例自动生成能力和快速的自动化测试覆盖;在性能测试和生产验证方面,研发流量回放工具,抓取 Oracle 数据库运行的 SQL 在 Gaus42sDB 数据库进行回放,进一步检验目标数据库的性能和稳定性;形成了覆盖功能测试、性能测试、生产验证和测试管理过程的自动化测试工具链,有效的降低了测试人力投入和测试复杂度,提升了测试效率和覆盖率,有效的保证了上线后业务功能的完备和系统的稳定运行。(九)(九)未来规划未来规划xxxxxxxxxxxxx。六、六、未来展望未来展望5 页页(一)(一)内存池化,全栈解耦,追求极致的弹性伸缩内存池化,全栈解耦,追求极致的弹
64、性伸缩在架构上云原生数据库要实现内存池化和全栈解耦。当前主流商用的云原生数据库都完成了计算层和存储层的解耦,接下来计算资源层中算力与内存也会解耦,计算能力池化、内存容量池化、存储能力池化,达到“计算-内存-外存”三层资源彻底解耦可分别进行弹性43热伸缩。基于存算分离三层解耦的云原生数据库,可以支持分钟级别的节点扩展能力,几分钟内就可以增加一个只读节点;秒级的高可用切换,在几秒内完成端到端的切换;秒级存储扩展能力,秒级资源释放回收能力,秒级快照备份能力。(二)(二)基于内存池的基于内存池的 HTAP,释放软硬协同的潜能,释放软硬协同的潜能内存池化后给云原生数据库也会带来一些新的挑战,比如内存池相
65、比本地内存时延是有差异的,数据库软件结构需要适配改造,减少这部分的影响;内存池化后的可靠性恢复如何保障;内存池化后数据库如何管理和判断存放哪些数据;不同业务使用内存池的隔离性问题等等。如何在技术上应对这些挑战并将内存池更好地用起来,是一个需要持续探索的领域。将内存池技术和 HTAP 结合是其中一个趋势。云原生数据库在 OLTP 和OLAP 能力融合的基础上,未来更进一步结合内存池软硬协同,44实现网络吞吐的大幅度缩减,同时也将内存池的性能优势发挥到极致。其中的关键技术包括:1)使用 SCM(Storage Class Memory)新介质,基于内存池对数据进行加速,提供 PB 级数据量、万级并
66、发、毫秒级访问时延;2)结合 AI 深度学习,根据应用负载和系统资源实现语句级自动弹性,自动确定分析节点数量,自动确定单个分析节点的资源;3)TP 侧通过 RDMA 直接写内存池中的 Delta Store,Delta Store 可立刻处理分析业务的读请求,不影响交易性能,又将 AP、TP 数据时延稳定控制在 1ms 以内;4)在行式存储引擎和列式存储引擎上建立全局的一致性事务视图,单条 SQL 可以横跨行存和列存;5)智能混合优化器,智能化判断 SQL 仅在 TP 引擎上执行、仅在 AP 引擎上执行、在 TP&AP 引擎上联合执行,实现语句级 TP&AP引擎协同执行。(三)(三)智能弹性,
67、实现更细粒度、更精准的资源调度智能弹性,实现更细粒度、更精准的资源调度Serverless 数据库未来还需要具备智能弹性的能力,能够根据用户的历史负载计算出用户特征描述,快速判断未来的负载曲线,提前为弹性伸缩准备好资源,避免负载冲击到资源规格上限,减少系统资源浪费,追求更极致的弹性。其中的关键技术包括:智能检测业务负载趋势,预测资源消耗,基于服务等级协议保障,动态调整数据库资源纵向扩展,加减实例横向扩展;数据库内核基于业务负载动态调整内核多种参数包括线程池45大小、连接数、等待时延等;基于分布式共享内存的扩展缓存池、锁、事务状态、以及元数据管理等,实现数据库全局状态管理;也可以采用轻量化容器技
68、术,提升系统的启动时间以及高密度部署。(四)(四)全场景智能数据库,发挥全场景智能数据库,发挥 AI 与数据库的融合价值与数据库的融合价值2019 年,华为首次发布了 GaussDB AI-Native 技术,并持续将AI 技术融入数据库内核、核心算法和数据结构,实现数据库自动优化和调优等功能。同时,GaussDB 还在分布列推荐、慢 SQL 发现与诊断、负载趋势预测与异常检测等领域,引入 AI 技术,大幅提升管理效率,让数据库管理更加智能高效。未来,云原生数据库将持续与 AI 内外协作,向全场景智能数据库迈进。全场景智能数据库包含两个方面:一是 AI for DB,让数据库管理更加智能高效。
69、具备自检测、自诊断、自调优、自运维及自安全的能力,覆盖数据库全生命周期的管理与优化。核心组件包括支撑平台及服务平台,支撑平台用于采集分析数据支持上层服务;服务平台提供智能化的运维管理服务。全场景智能 DB 在 AI for DB 上将从专家经验或者规则,走向全模块智能化。46二是 DB for AI,提供库内 AI 引擎。库内全流程 AI 框架,数据不出库,端到端完成数据清洗、特征工程、模型选择和模型训练,安全可靠、简单高效;库内原生支持常用 AI 算子,满足绝大部分机器学习使用场景。全场景智能 DB 在 DB for AI 上将从 SQL 扩展到原生 SQL,从单点功能调用到全流程自动处理。
70、47(五)(五)结合全密态和防篡改技术,保障云上数据安全结合全密态和防篡改技术,保障云上数据安全云原生数据库部署环境由封闭式私有环境向开放式公有云服务环境演变,数据库面临的威胁挑战也越来越多,数据安全隐私问题愈发凸显。针对传统的数据传输安全、数据存储安全、数据运维安全以及面向最终用户的数据显示安全等问题,当前云原生数据库产品提供了多种技术来保障数据的安全隐私,如安全传输通道、权限访问控制、数据存储加密及数据动态脱敏等。然而,数据运行态(查询计算)在缺乏有效保护手段的情况下,攻击者和恶意 DBA 仍然可以通过内存抓取来获取用户隐私数据,容易造成隐私泄露等安全问题。同时,可能存在恶意的篡改数据、擦
71、除痕迹、难以有效跟进的问题。未来,云原生数据库也将结合当下迅猛发展的全密态和防篡改技术,提升数据可信存储与可信维护能力,保障数据全流程的安全。全密态数据库通过支持密文形态下的数据查询和计算,使得攻击者在获取内存数据后仍然无法解析出有效的明文信息,更重要的是,数据加解密所需的密钥均由最终用户持有,可以有效地解决第三方信任问题。一种实现方式是构建纯软形态的全密态数据库解决方案,提供分布式密文数据处理能力,在服务侧实现多种密文数据查询纯软算法;另一种是结合云基础设施提供的可信硬件(TEE)实现软件和硬件结合的密态数据处理技术,密文数据每次依据查询要求将指定的密文“传送”至 TEE,然后在 TEE 内
72、完成数据解密和查询计算,充分提高系统整体效率,云原生数据库更适合第二种技术路线。防篡改数据库在技术层面通过去中心化的分布式账本数据库、分48布式数据存储、P2P 网络技术、共识机制、加密算法等,实现融合区块链特质的防篡改能力。第一阶段是做到单中心账本,对防篡改用户表进行操作,系统会在对应的用户历史表中记录行级数据变化,并通过密码学算法逐行生成校验码。通过校验码逐行验证用户历史表可保证用户表不被篡改;第二阶段是多方链上协同事务,多集群形成联盟链,每个集群均有全量数据,对防篡改用户表执行操作均需同步到链上所有集群,并使用公式算法校验执行结果。当前云原生数据库已初步具备第一阶段能力,将继续往第二阶段
73、探索。参考文献参考文献1 中国人民银行办公厅,中央网络安全与信息化委员会办公室秘书局,工业和信息化部办公厅,中国银行保险监督管理委员会办公厅,中国证券监督管理委员会办公厅.关于规范金融业开源技术应用与发展的意见.20212 王珊,萨师瑄.数据库系统概论(第 5 版).20143 中国信通院.数据库发展研究报告.20214 Sanjay Ghemawat,Howard Gobioff,and Shun-Tak Leung.The Google File System.5 DEAN,J.,AND GHEMAWAT,S.MapReduce:Simplified data p49rocessing o
74、n large clusters.In Proc.of the 6th OSDI(Dec.2004),pp.137150.6 Fay Chang,Jeffrey Dean,Sanjay Ghemawat,Wilson C.Hsieh,Deborah A.Wallach,Michael Burrows,Tushar Chandra,Andrew Fikes,Robert Gruber.Bigtable:A Distributed StorageSystem for Structured Data.OSDI 2006:205-218.7 J.C.Corbett,J.Dean,et al.Spann
75、er:Googles globally-distributed database.OSDI 2012.8 Alexandre Verbitski,Anurag Gupta,Debanjan Saha,Murali Brahmadesam,Kamal Gupta,Raman Mittal,Sailesh Krishnamurthy,Sandor Maurice,Tengiz Kharatishvili,Xiaofeng Bao.Amazon Aurora:Design Considerations for High Throughput Cloud-Native Relational Databases.SIGMOD 2017.