首页 > 资讯 > 数字化

金融数据库的战场,太平洋保险和OceanBase打了场胜仗

2023/07/13 12:19      光锥智能   


  文丨刘雨琦

  “数据库的国产替代,必须经过严格的考虑,保证不会出错,所以大多数企业的领导层选择按兵不动或者简单扩容。因为不换就不会错,选了很久如果选错,还可能会出现重大事故。”

  某银行数据库技术人员曾对光锥智能一语道出了在数据库的国产替代中的核心难点。“真的要大刀阔斧的改革,需要领导层有魄力和决心,否则只能是边缘试探。”

  下定决心全面替换,一方面是企业对国产数据库有足够的开放程度,另一方面,也要国产数据库有超过Oracle等老牌数据库的性能。一次改革,不仅完成“平替”,更能升级,帮助企业降本增效。

  2022年,中国太平洋保险集团(以下简称:太保)面临着一样的十字路口,作为国内头部的综合性保险集团,太保核心业务系统的数据库要比其他的要求更高、更困难,但同时,也更具代表性,一旦拥有成功经验,也将为整个保险行业建立新的行业标准。

  太保集团科技管理部总经理马波勇曾公开分享过替换经历:“太保从业务场景出发,通过梳理保险业务的典型场景,选择了两类数据库。既有高并发、大数据量、具备互联网业务特征的场景,又有大量以内部用户为主的业务场景。比如在核心的P17客户服务系统中,我们经过两年多的调研、测试和评估,选择了之前服务过金融行业的蚂蚁集团数据库OceanBase,进行分布式转型。”

  “数据库的国产替代,正在从边缘的OA系统,深入到核心的业务系统。如今国产数据库占20%的市场份额,传统数据库占80%的份额,这样的‘二八’分布将在三年之内颠倒过来。”OceanBase副总裁王爽认为,国产数据库已经经历了磨砺产品性能、攻克替代难关的过程,将在三年内加速进入全面升级的阶段。

  据光锥智能了解到,很多企业制定了内部战略,要在2027年做到数据库的“应替尽替”。国内企业逐渐对国产数据库重新认知并抱有开放态度,尤其在数据库最核心的金融场景,也有更多企业愿意“押注”在国产数据库上。

  国产数据库,从金融行业里“杀”出了一条路。金融行业升级的三座大山

  “没有经历过金融行业历练的数据库,不算合格的数据库。”

  一直以来,金融场景都是数据库的最大练兵场,不仅是因为数据量庞大,同时,交易、分析、事故更加复杂,高频高并发是金融数据库的特性,更因为金融行业本身7×24小时不间断,对数据库安全性、稳定性都有更高要求,运维也更加复杂。

  王爽举了一个例子:“以前银行的交易来自于营业网点,存钱、取钱、转钱,但现在已经互联网化了,频率大大增加。以前一年去营业厅也就三五次,但现在用户每天都在交易,每天点外卖、坐公交/地铁,每刷一次都会产生数据。这就造成了爆炸性的数据量增长,传统数据库处理起来,成本非常巨大。所以,并不只是为了国产替代,更是为了升级。”

  此前,企业在选择国产数据库时,第一考虑的是与Oracle的适配和兼容关系,以降低应用和迁移成本。“2020年之前,几乎所有的国产数据库对企业宣传的核心价值就是兼容Oracle和MySQL。”一位数据库厂商对光锥智能讲道。

  但在真正落地时发现,兼容是不够的,在适配时必须要取舍。Oracle数据库垄断了近20年,有很多特性逐渐落后,国产数据库的单纯替代没有意义,底层架构发生改变之后,性能要做到更加优化。

  更重要的是,银行、保险、券商过去与Oracle进行了深度绑定,包括⾃定义锁、⾃治事务、嵌套表、索引组织表、PLSQL包、物化视图、DBlink、触发器、系统视图,改造难度极⼤,如何提升庞⼤存储过程中的识别效率⾄关重要。

  这不只依赖数据库厂商一家来完成,更需要使用方一起深度改造。太保集团与OceanBase打磨的过程中,马波勇总结了升级过程中的三大挑战:

  第一是国产数据库的性能,能否满足业务需求。“由于之前大部分系统使用传统数据库做支撑,在制定数据库的选型策略和升级方案方面,系统的兼容性、稳定性,数据迁移的便捷性、完整性是我们考虑的首要问题。第二,要考虑它在金融行业的应用案例是否广泛,是否具备足够的成熟度。第三个是在运维方面,需要具备较强的自主营运能力和支撑能力”,马波勇谈道。

  第二是数据库的安全性和弹性伸缩能力。银行保险业数据量大、私密性强、波峰波谷期动荡,本地部署的数据库能保证安全性,但是相应的成本也会更高,且弹性伸缩能力差,无法灵活应变银行互联网化后的高频和多发需求。

  第三是平滑迁移的能力。迁移的过程中保证业务不停,同时要高度兼容,节省调试时间。马波勇谈到:“太保集团作为32年的国企,数据量及业务量都很大,如何在有限的时间窗口,完成数据迁移,成为摆在太保集团面前的一大难题。”

  那么,这三座“大山”,太保和OceanBase是如何携手跨过的? 最难的P17系统,OceanBase如何搞定?

  OceanBase所升级的太保P17核心系统,同时面临着上述的三座大山。

  在太保的业务系统中,有P20的级别之分,P17是集团排名中的高级别,因此,该系统的成功升级具有标杆作用和里程碑意义。“P17客户服务系统”是太平洋保险产、寿、健康、长江等所有子公司客户服务系统的整合,为公司6地8个电话中心超过2000坐席提供系统服务。”太保集团数智研究院首席数据库专家林春介绍道。

  “与一般热线系统相比,‘P17客户服务系统’涵盖了太平洋保险几乎所有子公司业务的服务入口功能,包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等等,对接周边系统超过200个,是太平洋保险关联关系最为复杂的系统之一。”

  同时,作为太平洋保险的服务品牌,“P17客户服务系统”需要提供7*24⼩时的全天服务,系统可⽤性要求全年99.9%以上,对停机时间有着严苛的控制。因此,也是太平洋保险运维保障最⾼的核⼼系统之⼀。

  毫无疑问,对于P17的升级,是最为慎重的决定。2021年初,太保对国产分布式数据库,从功能、性能、易用性、完整性、可移植性、可靠性、扩展性、安全性等指标进行了全方位评估,最终选择了OceanBase升级传统数据库。

  2022年上半年,在不少项目暂停、放缓之时,太保和OceanBase正在紧锣密鼓的远程协作,加班加点,只为搞定P17。

  据林春回忆,2022年初启动项目到8月31号,核心业务场景就完成了数据功能的开发;12月18日,P17第一个子系统成功上线,并完成了全量数据库迁移;2023年5月6日,核心交易、相关的报表库迁移上线;5月13日核心系统中最难的核心交易库上线。至今,P17核心系统已经成功运行了200多天,确保交易成功率达到99.99%。

  “项目刚开始时,正是上海管控最紧张的时刻。大家没办法到场地,造成了很多困难,但是OB在产业侧和技术侧联合攻坚,把这块硬骨头啃了下来。”林春谈起到项目的全过程,仍然不禁感慨。

  整个升级的流程,可以分为四个阶段:

  第一阶段的重点,是通过OceanBase的分布式架构彻底升级传统商用的主备架构,破除传统数据库与操作系统、中间件的耦合。据了解,与Oracle配套的DS、Cognos等产品对于Oracle深度依赖,适配改造复杂度很⾼,将数据库分库分表,从集中式拆分成分布式,每个分片都能够独立执行读写,这个过程中需不断拆解中间件和操作系统之间的关系。

  第二阶段,OceanBase和太保并没有急着对业务进行升级,而是建立了迁移“标准”,一次次探索形成行业经验,破除替换升级的壁垒。

  OceanBase华东区金融技术服务总监郭文讲道:“厂商和用户侧的目标是希望效果稳定的与传统数据库兼容,标准化、流程化、制式化能够降低双方的人力投入,少走弯路,同时能够复制工具和经验。”

  郭文介绍道:“OceanBase通过制定33类标准规范和28类最佳实践,以及打磨了16款数据库转向工具,实现了标准化的Oracle兼容,这会极大程度破除迁移的不透明性,让企业更有信心,意识到升级不再是一件特别困难的事情。”

  比如创新研发的“指南针”工具,能够对传统数据库进⾏改造评估预扫描,包括近20个检查⼤类,近200多个检查项,评估项全⾯⾼效,极⼤提升项⽬组问题排查的效率,缩短项⽬周期从⽽降低应⽤改造成本。以“P17客户服务系统”为例,扫描出改造项约6000个,假设⼈⼯⽅式排查2个问题/⼩时,单个项⽬即节约⼈⼒成本12.6⼈/⽉。

  第三阶段,对P17中的业务场景进行逐个点测。对寿险保监会稽核接口系统、寿险营销员系统的佣金计算、智能决策服务平台和寿险统一承保平台等“一事一议”的替换。

  第四阶段,从点测到全面替换。这里的全面替换,并不只是P17系统的全面替换,而是太保秉持着“先难后易、应替尽替”的原则,以P17这套最复杂的系统为模版,对太保几百套系统进行分布式替换。

  在全面替换后,国产数据库的优异性能开始展现出来。据太保反馈数据,在保持了高运行性能、高可用能力的同时,数据库软件的运维费用大幅降低,每年可节省设备投入数亿元。特别是OceanBase的高级压缩技术,结合“数据库瘦身”,将存储容量节省80%以上。

  可以说,升级后的应⽤系统弹性扩缩容、处理速度、数据加⼯能⼒均实现⼤幅提升。 长于金融的数据库,更懂金融

  OceanBase与太保的探索经验,也带动着金融数据库发展进入下一个阶段。

  在整个实践的过程中能够明显发现,金融场景考验的不只是性能,更多还在于复杂业务中的灵活应变能力和适应能力。显然,诞生于金融场景的OceanBase更懂行业的需求和痛点,也有机会能将实验室的解决方案,搬到了业务中去。

  2013年,OceanBase开始应用于蚂蚁集团的支付业务,当时大部分互联网企业都在采买Oracle,但随着双十一交易量的瞬时爆发,成本高企压力之下,促使了云厂商们开始自研数据库。

  彼时OceanBase最核心的任务,是完成降本增效和弹性伸缩。在这两个方面的经验,也在太保案例中得以体现。

  正如前文所讲,之所以将存储容量节省至80%以上,来源于OceanBase独创的高压缩比的分布式存储引擎,在提升业务系统稳定性和安全性的前提下,存储成本为70%-90%,同时硬件和维保资源投入显著降低。

  林春就算过一笔账:“1TB的存储成本传统数据库要4500块钱,OceanBase压缩到了三分之一,成本会大幅减少。另外数据库加密之后,对场地成本要求就没有那么高,也能降低硬件成本。”

  2020年山东移动计费业务系统接入OceanBase,其计费业务详单处理时长缩短至5分钟,处理效率提升30%,数据由7T压缩至0.7T,存储投入成本降低90%。

  另一方面,OceanBase的单机一体化分布式架构也能够在硬件存储资源帮助企业控制成本和灵活扩缩容。顾名思义,单机一体化的数据库,既能够适应大型企业的系统逐步替换需求,在不需要分布式架构时,也可以作为一个完整的集中数据库提供,让企业能够部署更灵活。

  同时,HTAP集TP(交易)和AP(分析)于一体的数据库架构,也能够同时适应TP场景和AP场景,单一引擎支持高性能混合负载应用,通过基于时间片的混合负载调度技术,解决混合负载的资源隔离问题。一个典型案例是太保的寿险需要与保监会稽核系统接口,以前该系统夜间批处理占据整体计算资源的90%以上,现在,相同资源的批处理节省了时间62%,监管报送批量场景的性能提升了3倍。

  除此之外,全自研数据库也成为了OceanBase换道超车的关键。

  OceanBase数据库创始人、首席科学家阳振坤此前提到,“全自研是个苦活累活,OceanBase数据库是从第一行代码开始,到现在积累了几百万行代码量,但是好处也显而易见。”

  让林春印象最深刻的是OceanBase对Bug的修复速度非常震撼。常常很多问题,大致是第一天发现,第二天就能更新一个修复版本,这就体现了OceanBase全自研数据库,将内核代码都掌握在自己手中的特点。Bug修复速度是技术兜底的一个很好的验证,如果没有对核心代码的掌控,从排查问题到解决问题,就做不到闪电速度。

  也正是因为上述原因,让大型银行、保险业开始对国产数据库充满信心。

  但这也只是万里长征的第二阶段,数字化、智能化的车轮滚滚向前,国产数据库从金融场景“杀”出来之后,千行百业中还有更广阔的星辰大海。

  榜单收录、高管收录、融资收录、活动收录可发送邮件至news#citmt.cn(把#换成@)。

相关阅读

    无相关信息