超大型金融机构国产数据库全面迁移成功实践
刘伟光
阿里巴巴集团副总裁
阿里云智能新金融&互联网事业部
总经理
导语
2021年9月,某超大型金融机构圆满实现后一个规模高达20TB+核心数据库的全面迁移改造工作,也为后续向云原生多活架构演进打下了坚实的基础。该核心系统数据库全量迁移项目的成功上线,树立了金融行业践行科技强国的标杆实践。将历时一年的迁移全过程完整步骤及技术攻略做提炼梳理,便完整沉淀成了独一无二的干货、本文的全部内容。“实践出真知”,阿里云走出了助力超大型金融机构国产数据库全面迁移坚实的一步,积累了弥足珍贵的经验。因此,本文不是对于数据库替换的分析和畅想,而是真正从实际面对实际的大规模复杂的核心应用系统的技术平台替换的技术指南,过程中存在各种“分析”文章中想不到的问题,尤其对于现有运行的环境的各种适配和兼容,对应用的友好性等,关于这些问题到底该如何解决,这篇文章均一一给出了详细解法。
前言
突破一、迁移时间短。从2020年9月到2021年9月,仅用时一年即完成迁移, 而传统金融机构还没有实现过如此大规模的核心系统全量迁移。
突破二、迁移规模破纪录。一年内完成了包括传统核心、互联网核心、个险销售、团险销售、经营管理、客服管理、大数据在内的近百个业务系统近在线Oracle数据库的全量搬迁工作,迁移数据规模超400TB、数据量超千亿,单库数据规模超20TB。
突破三、迁移全程同时保障了业务连续性和数据准确性。整个迁移过程无一例回切,上线后近一年来,系统稳定运行,并历经2021年完整周期的“业务大考”,经受住了开门红高峰TPS 5万+、QPS 21万+和包括精算在内的所有业务环节的严苛考验,完全满足生产需要,实现国产数据库从可用到好用的跨越。
突破四、迁移后实现技术自主创新。基于完全自研创新的国产数据库,迁移过程中版本升级持续发版共计50余次,长需求解决时间2个月(Pro*C+Tuxedo)。同时通过系统培训与交流实现累计超过500位员工的数据库专业考试认证,实现了数据库的全面自主掌控能力。
当我们回顾这一段历程,过程虽然艰辛,但积累了宝贵的大型金融机构国产数据库迁移实践经验。
国产金融级数据库迁移实践
1.1 前期准备工作
是否能满足业务的平滑迁移和未来架构的演进。
是否具备分层解耦能力,重点解除数据库与底层硬件、操作系统、中间件之间的耦合。
是否有足够人才储备、资金投入,保证产品的长期演进和商业兜底。
是否有广泛的行业实践案例。
是否能做到完全自主研发。
是否能兼容原有开发运维体系,自有技术人员能否快速掌握。
该保险公司核心业务系统原先共计使用超过60多台IBM和HP高端小型机,超过70多台高端存储,传统集中式架构耦合性强,难以实现规模和性能的线性扩展。本次国产数据库采用机架式服务器和本地存储全面替代进口小型机及传统SAN存储架构,以满足核心系统全量迁移的云原生分布式架构改造。同时为了避免基础设施变动过大导致业务系统不稳定,采用Intel+海光+鲲鹏服务器混合部署的架构。前期仍以Intel X86为主,逐步过度到海光、鲲鹏芯片国产服务器。实现在线调整不同型号机器,解除了基础设施供应依赖。2020年9月,正式启动国产数据库迁移项目之后,从硬件环境的型号选择,到选出目标系统,进行容量规划,不到两个月的时间,从开始完成国产数据库的硬件和操作系统适配、以及整个服务器集群的搭建。
1.1.3 迁移策略制定
该保险公司的业务经过多年的发展,业务范围覆盖,特色鲜明、种类繁多、关联关系错综繁杂,核心数据库迁移需要广泛调研和充分的科学论证——既要求数据库产品比照原有生产数据库的高性能和安全可靠,也需要快速实现多套系统的平滑迁移,同时解决资源弹性和数据库横向扩展的能力。因此,建立了数据库迁移实施的统一规范和标准,总体遵循评估-实现-控制-分析改进的科学方法论,开展有序迁移,并定下三大迁移策略:
先平迁再做业务和架构改造升级,避免多个变量同时发生,影响业务的连续性。原有数据模型不做改造,主体改造工作由新数据库来承担。
迁移批次以业务系统为粒度,从低负载到高负载,从外围到核心。
用1年时间完成所有业务系统的数据库全量迁移改造,所有系统数据库迁移动作时间窗口只给周六、周日凌晨0点到早上6点,周末小流量验证,周一重点保障,不影响正常业务开展。
1.2 互联网核心迁移
1.2.1 业务背景
该保险公司核心虽然涉及系统众多,但总结下来主要分为:互联网核心和传统核心,中间通过类似ESB的总线机制实现异步解耦。
核心系统分类
数据库系统已实现物理集中、逻辑集中,数据库对接的关联系统较多。
虽然做了微服务拆分,数据库仍有一定量的存储过程,另外触发器、自定义类型、函数、外键、分区表等功能均有使用。
因为业务特点,要服务好100多万代理人,对数据库资源弹性和性能要求更高。
集中式部署下单点故障会影响到。
主数据系统作为核心业务链路中的整个保险开-户入口,内部对接43个关联系统,数据规模超20TB,大单表超50亿条数据,每天接口调用量超2000万次,是该公司单体数据库日均请求量大的系统,因为关联系统多,且处在业务链路的核心位置,因此对数据库SQL的效率要求非常高,迁移过程不能影响原有生产系统。
迁移到新的数据库平台要具备实时同步到Kafka的能力,并兼容原有格式,供下游大数据系统消费。
原有大数据消费链路
1.2.2 技术方案
整体选型
针对以上技术挑战,选择了和原有Oracle RAC架构更接近的PolarDB作为互联网核心数据库的替换,PolarDB作为新一代云原生数据库主要特点如下:
计算与存储分离,使用共享分布式存储,满足业务弹性扩展的需求。极大降低用户的存储成本。
读写分离,一写多读,PolarDB引擎采用多节点集群的架构,集群中有一个主节点(可读可写)和至少一个只读节点(大支持15个只读节点)。写操作发送到主节点,读操作均衡地分发到多个只读节点,实现自动的读写分离。
基于K8S形态部署,提供分钟级的配置升降级,秒级的故障恢复,全局数据一致性和完整的数据备份容灾服务。
集中式架构,不需要进行分布式架构相关考虑设计,和原有使用习惯保持一致,性能不低于原有Oracle数据库。
高度兼容Oracle,应用基本上不需要做SQL语法调整。
迁移方法
互联网核心整体迁移技术方案
大数据同步链路改造方案
增加PolarDB到Oracle的反向实时同步,原有Oracle到Kafka同步链路不变,避免数据库切换带来太大的变动 ; 参考SharePlex的格式对DTS进行定制化开发改造,待验证充分后,直接替换掉SharePlex原有同步链路。
主要挑战
统一管控:通过PolarStack将多台机器组成的集群进行统一管控,提供DBaaS服务; 资源弹性:实例由原来的物理机部署,变为K8S Pod部署,更为灵活和弹性; 读写分离:通过智能代理服务实现自动的读写分离,实现分钟级扩容,故障场景下自动切换,应用不需要做任何调整。
PolarDB技术架构
迁移历程
1.3 传统核心迁移
1.3.1 业务背景
该大型保险公司的传统核心系统历史悠久,既有1998年之前建成的,也有2004到2008年间建成的,时间跨度长,数据量异常庞大,单个数据库的数据规模甚至超过20TB。更具挑战的是,很多老核心按省市做了拆分,要分省市分别进行迁移,单一老核心系统需要迁移的数据库可能就要多达36个。传统核心总体来说可以分为三类系统:
类:2016、2017年基于Java技术栈开发的新核心系统,大概有13个。
第二类:分别在1998年之前,2004到2008年间建成的老核心系统,大概有6个。
这些传统核心的数据库当时面临的主要技术挑战是:
系统关联关系庞杂,既有保单平台管理系统也有资金类系统,系统间关系难以梳理。
既有物理和逻辑集中的新核心,也有物理集中,逻辑分离的老核心,其中老核心分省部署,每个省都会有一套数据库,迁移工作量巨大。
对Oracle专有特性依赖较多,大量使用存储过程、触发器、自定义类型、函数、外键等。更为挑战的是老核心大量使用Pro*C(SQL嵌入式C程序)和Tuxedo(Oracle中间件做分布式事务处理)做保单过程处理,仅某年金系统涉及到的Pro*C程序就有1500多个,约140万行代码,业务短时间难以改造。
单库体量非常大,超过10TB的就有6个,大单库规模有超20TB,停机窗口短暂。
交易量大,每天数据库调用几十亿次,还有大量复杂集合类精算和结算类交易。
1.3.2 技术方案
选型方案
针对以上技术挑战,选择了分布式数据库OceanBase作为传统核心的替换,OceanBase数据库主要特点如下:
采用基于无共享(Shared-Nothing)的多副本架构,整个系统没有任何单点故障,保证系统的持续可用。 基于LSM存储引擎技术,结合新硬件的能力,采用可扩展的分布式架构,提供高性能和扩展性。 数据库针对 Oracle、MySQL 等应用为广泛的数据库生态都给予了非常高的应用兼容性支持。 虽然为分布式架构,一般也不需要应用层做相应的重新设计如指定分布键等,与原有Oracle使用习惯基本一致。 OceanBase 数据库完全自主研发,不依赖外部开源代码,真正做到自主研发。
迁移方法
针对传统核心复杂的数据库情况进行全面验证,终形成了140页的迁移操作手册和详细的割接行事历,为后续系统的迁移和大面积推广积累了宝贵的经验,并形成了标准的迁移割接方案。整体迁移方法过程如下,从基础环境准备-迁移过程演练-正式割接-监控运维等四大环节进行逐项拆解,落实到人,到分。
数据库整体迁移割接流程
-
冷热数据分离 一般的业务库数据中,数据具有自己的生命周期,数据的高频访问具有冷热特点。比如,流水表历史数据,日志表历史数据除了在审计回查场景之外,访问很少甚至不访问,但是通常这部分数据都会比较大,数据迁移的开销会比较高,造成数据迁移时间的延长。针对该部分数据,我们可以预先对这部分数据进行归档备份,然后采用静态迁移或者利用OMS工具全量迁移单独迁移。 -
LOB类型数据 Oracle数据表行 LOB 类型空间占用较大,每一批次的数据拉取大小会在原始行的基础上有显著增加。相比无LOB数据类型,对OMS端内存需求有数倍的需求,因此,优化的策略是单独对LOB类型的表建立新的链路,采用较小的并发,防范JVM OOM的风险,同时,为了提高整体迁移的速度,进行多链路并行迁移。
-
无LOB类型数据 相对于LOB类型数据,无LOB数据类型的表的迁移,单位迁移批次的大小较小且稳定,内存需求可控,并发度可适度加大,提高迁移速度。所以,对该部分数据可使用较高的并发度单链路或多链路迁移。
-
多个大库迁移链路通过不同OMS并发迁移 单台OMS可以支持多个迁移任务,但是共享数据网络出口。鉴于大库数据的持续拉取,可以将大库的迁移分散至不同OMS节点,减少大数据网络流量的争用。
主要挑战
而Tuxedo(Transactions for Unix, Extended for Distributed Operations)作为是早的分布式事务产品,是AT&T在20世纪80年代推出的。传统老核心业务中,大量使用Tuxedo调用相关的Pro*C程序来做保单业务流程处理来保证跨库事务的一致性。
为了根本上解决该问题,实现应用的平滑迁移,阿里成立项目攻坚团队,用1个月时间,从头开发Pro*C兼容预编译程序和运行时库,2020年国庆节前,预编译程序成功编译了某年金业务的全部1000多个Pro*C程序,并正确跑通了两个典型批处理作业,通过了该公司的验收,进展大大超出该公司预期,也因此在赛马中成功胜出赢得了该公司对OceanBase产品研发能力的信心。
始终坚持自主研发,研发人员有的个人能力,清楚产品每一行代码的来龙去脉,能够快速和高质量地新增和修改代码,真正做到了自主研发。
全链路打通的研发模式,Pro*C只是外在交互模式,底层还要依赖数据库的内核能力,从SQL模式、优化器、服务端等做到了全链路打通,比如研发在批处理作业现场联调时发现SQL对to_date函数的'J'参数尚未支持时,快速反映给SQL模块,后端仅用一天完成了开发测试和发布。
敏捷开发模式,攻坚小组的研发和测试大家坐到一起,每日随着项目进展和变化快速确定和调整当日的目标。打破研发和测试边界,研发一边在开发,测试同学已经把单测和集成测试案例写好,开发侧有一点小的进展就立即验证测试,使得开发和测试能接近同步完成。
迁移历程
2020年10月,传统新核心理赔系统顺利上线。
2021年3月,完成传统老核心小省份的迁移上线。
2021年4月,完成13个传统新核心的迁移上线。
2021年8月,完成传统老核心后一个大省迁移上线。
1.4 全面体系化迁移
OMS数据迁移工具在底层链路上从技术层面支持多schema合并操作,从而可以将同一个省份的二十多条链路合并到一条迁移链路中。
在产品层面将数据迁移工具的底层能力进行拆解,将原来无法自动化的步骤做了自动化,并通过API的方式暴露出来,使得前线交付同学可以根据用户的实际情况像搭积木一样进行组装使用。
交付同学基于暴露的API和140多页的迁移操作手册,用一个月时间开发出简化迁移链路配置的快捷迁移工具。
一键自动迁移过程图
在对快捷迁移工具迭代了四个版本后,投入使用。需要人工干预的工作量减少了80%。同时一起建立了数据库迁移实施的统一规范和标准,开展有序迁移。上线实施标准流程包括8大环节,98个步骤,5倍峰值压测,体系化迁移8大环节如下:
兼容性评估:明确改动范围,进行适配改造工作量评估并合理安排工作任务。 负载评估:从原数据库获取SQL负载信息并在新数据库测试环境回放,验证新数据库应用后的性能。 测试迁移、适配改造:进行适配改造、全量回归测试、性能测试。有条件的系统(微服务化较好、重构等),可以分批改造和实施迁移。其中,性能测试可根据迁移前的关键业务容量基线,确定测试准出标准。 生产库存量、增量式迁移:对于业务连续性要求不高的系统,一般操作一次性存量方式完成数据迁移;对于业务连续性要求高的系统,采取全量+增量迁移方式,待增量数据追平后实施切换,仅需在切换时点暂停业务(分钟级)。 反向回流:对于关键应用,可实施数据同步回原数据库应对未知风险。 数据验证:迁移完成后进行数据准确性验证及应用验证。 持续监控:对可能遇到的问题进行监控、详细评估分析。 在线压测:迁移完成后,定期开展在线压测,基于实际生产场景进行业务全链路压力测试,持续保障应用容量和性能。
正式迁移割接步骤
紧接着完成了东北三省+内蒙古总共四个省份的数据,过程中解决了Oracle源端出现不可见控制字符脏数据的问题,确保了数据准确无误。
2021年8月,历经前面11次的迁移后,终于完成了后一个、重要省份,也是数据规模大的的数据库迁移。
2021年9月,在解决了所有技术难题,完成了所有核心数据库的迁移,经历了开门红大促的考验后,要完成一个保险公司一个完整的业务周期,只剩下后一关,就是保险精算。
保险精算是保险公司业务经营的特色,指运用数学、统计学、金融学、保险学及人口学等学科的知识与原理,去解决商业保险与各种社会保障业务中需要计算的项目。一般会在季度末和年末进行,以衡量企业的经营状况,并制定更有市场竞争力的保险产品,是保险业务开展不可或缺的关键一环。
1.5 主要问题总结
当然迁移过程并不是完全一帆风顺,虽然未产生重大生产事故,但过程中也出了几次故障。而这些故障背后既反映了国产数据库在面对复杂场景上能力的提升,也反映了分布式架构带来的根本性变化。
以云原生容器形式部署的数据库服务节点,除了受本身数据库相关的内存参数限制外,还受cgroup指定的CPU和内存限制。当时连接池打满后,由于内存超出限制,引起实例的多次高可用切换重建。云原生数据库基于容器部署需要在稳定性和自保能力方面做诸多增强,为了解决相关问题,后续的版本中增加了global plan cache、resource manager、并行日志回放、global index等功能,数据库的内核参数也针对金融场景逐一做了定制化优化。
增加AWR功能,定期收集AWR报告对性能和可用性进行分析。
增加GAWR功能,对主机、Dockers、RW/RO进行全量数据采集。
新增online promote功能,优化在线切换,进一步缩短切换时间。
增加Idle状态Session超时自动断开连接功能,减少后台进程数,及时释放回收Idle Session的内存资源。
优化元信息缓存功能,Session级别元信息缓存优化为全局元信息缓存,降低后台进程的内存使用。增加内存总量资源管理控制,设置一定的阈值,到达阈值后开始Cancel Query、Kill Idle Session、Kill Active Session、拒绝新用户Session连接,增强数据库的自保能力。
2.5.2 SAN交换机故障导致数据库进入无主状态
由于原有Oracle数据库都是基于SAN存储部署,在2020年9月份启动数据库迁移工作之时,针对OceanBase部署建议的本地SSD盘硬件还没有采购到位。为了快速启动相关的迁移工作,开始OceanBase传统新核心集群还是部署在SAN存储上,这也为个生产问题埋下了隐患。
OceanBase QPS监控截图
问题现象时间轴分析
经过深入分析,发现是SAN存储交换机到核心交换机连接的一个端口出现了故障。虽然配置了多路径转发,但由于操作系统内核的超时时间OceanBase切主时间不匹配,触发了OceanBase的自动选主操作。而选主过程中,另外一台物理机也走的同样端口也出现了IO阻塞的问题,终导致OceanBase进入无主状态,当多路径软件成功切换后,OceanBase未经过任何干预就完成了自动恢复。本质上是因为软件超时参数与硬件超时参数不匹配所导致,也是软硬件系统磨合不够充分的表现,通过相关参数的调整能减少RTO的时间。
1.5.3 执行计划跳变导致业务卡顿
如果一个数据库厂商说兼容Oracle,保证迁移过程不出任何问题,那一定是自吹。即便做到了事前压测充分,且尽量覆盖完所有业务场景。但对于割接上线后的系统稳定性、兼容性还是要画问号。关键在于是否有及时有效的监控,以及出现问题后的快速应急手段。毕竟已经投产的应用,应急还是优先级。
在11月份某个周末,理赔系统出现慢SQL,导致理赔应用系统票-据汇总操作卡顿超时。为什么系统已经稳定运行了半个多月,没有任何的业务变更,反而在周末业务低峰期出现问题?现场交付专家经过分析很快定位到原因,OceanBase的执行计划发生了跳变,导致执行计划走错。
经过深入分析,OceanBase和其他数据库一样,通过使用执行计划缓存 (Plan Cache),对于相同的SQL(参数不同),跳过解析阶段,避免重新生成执行计划,以提升SQL的性能。但是实际场景中传入的参数往往是不同的,就像淘宝双11有热点库存,在保险行业也有大小机构号。虽然SQL看起来一样,但因为传入的参数不同,优化的手段和执行的路径也不一样。传统数据库(比如 Oracle)为了选择优的执行计划,会定期进行数据对象统计信息的收集(如每天夜间的维护窗口(maintenance window)),淘汰旧的执行计划,使新的执行计划能够按照实际的数据统计信息生成更准确更优的执行计划。OceanBase采用类似的方法,但由于OceanBase 每天进行数据冻结合并,增量数据落盘,数据库对象的实际数据信息(行,列,平均值等)会发生较大的变化。因此合并以后,计划缓存会进行清理,并根据次传入的参数生成执行计划进行缓存,默认情况下,只会保留一个执行计划。由于周末当时次传入的参数不具备普遍代表性,导致后续执行计划走错,产生了性能问题。
1.6 整体效果
历时一年,近100个业务系统全面实现国产数据库迁移,成为完成核心业务系统国产数据库迁移的大型金融企业,数据库OceanBase和PolarDB用量占比超过97%。
数据库技术栈的安全可控,摆脱对Oracle数据库的依赖。 摆脱对小型机和高端存储的依赖。 促进云原生和分布式数据库应用成熟,从可用到好用并取得性能提升。 数据库服务集中管控,显著降低硬件及整体运维成本。 真正的实时扩缩容和高可用能力,轻松应对大促活动。
从完全封闭的体系架构到逐步开放再到全面开放,真正实现了对数据库核心技术的自主掌控。得益于云原生架构和分布式架构的弹性和资源池化能力,也自此能实现“一库多芯”,只需一条命令就可以把租户切换到海光服务器节点,实现了国产硬件的平滑替换。
迁移后由于分布式数据库提供的高效压缩能力,存储容量的大小只有原来的1/3,加上高端小型机迁移到国产机架式服务器,设备投入节省近2亿元。
数据库服务器及存储机柜数量利用率提高了300%。设备功率下降至原有1/3。经测算,全年可节约电力约近千万度,为该公司数字化转型提供了源源不断的绿色动能,有力践行了国家双碳战略,减少公司由于自建数据中心带来的碳排放增量。
总结
今天国内大部分金融机构的核心业务仍然运行在国外的数据库上,这是一个我们无法回避的现实,数据库的替换不仅是一个产品的替换,替换的目的不单纯为了“国产”两个字,更重要的是:技术必须进步;替换后的新系统必须具备老系统和国外产品不具备的能力,不仅是性能和稳定,更多是对业务的敏捷支撑能力,和面对海量业务和不确定性的业务高峰时刻的处理能力,以及更上一层楼的金融级高可用能力。
这些年我们看过很多的文章都是对于数据库替换的分析和畅想,但是面对实际的大规模复杂的核心应用系统的技术平台替换,过程中还有很多在各种“分析”文章中想不到的问题,尤其对于现有运行的环境的各种适配和兼容,对应用的友好性等很多,关于这些,阿里走出了坚实的一步,积累了弥足珍贵的经验,这些都为今后的国产进程给出了很好的示范效应。
原文链接:https://mp.weixin.qq.com/s/P1H8GFvKglD_089IQXMDCw
相关文章