写点什么

头部保险公司国寿财核心系统采用 TiDB 实现信创替换并实现重大突破

  • 2024-08-09
    北京
  • 本文字数:2630 字

    阅读完需:约 9 分钟

作者: 数据源的 TiDB 学习之路原文来源:https://tidb.net/blog/2d391c67


注:本文总结自 TDBC 2024 可信数据库大会上中国人寿财产资深主管杨光内容分享


数据库作为保险公司最重要的 IT 基础设施之一,安全性、可靠性以及高性能一直是被关注的重点。在金融行业,很长时间数据库被欧美垄断,借着信创大势国寿财在国产数据库创新应用方面积极探索大胆尝试,特别是在核心业务系统上实现了数据库先进替换、安全可控,取得了很好的应用效果。

国寿财信创情况及国产数据库选型

国寿财,全称 中国人寿财产保险股份有限公司,坚决执行党和国家关于保险业改革发展的决策部署,根据自身情况因地制宜,结合公司高质量发展目标,深入开展信创实施改造工作,稳步走出具有自身特色的信创改造之路。



2021 年是国寿财的 “信创试点年”,累计实现了 2 个 全栈系统替换,实现了办公域的 100% 自主可控;2022 年是国寿财的 “信创提效年”,累计实现了 23 个 系统的全栈替换,并实现了中间件的 100% 自主可控;到了 2023 年,也就是 “信创推广年”, 国寿财总共实现了 53 个 系统的全栈替换,且核心系统具备完全自主可控的能力。


在基础软硬件方面,通过引入信创技术重构公司科技基础底座,形成安全可靠、动态可伸缩的企业级 IT 资源池,有效承载了三大中台、五大工程建设,实现赋能业务创造价值,体系化建强公司科技核心竞争力。操作系统主要使用国产 统信、麒麟、欧拉,中间件主要使用国产 东方通、宝兰德,数据库主要使用 TiDB、达梦、GaussDB



在数据库的选型上,国寿财从 2019 年就开展了相关选型试点工作。按照 “先行先试,应测尽测” 的选型原则,结合国产数据库产品类型较多、应用场景多样特点,采取了 “四步走” 的选型策略,包括公开招标、PoC 测试、上线试用、验收评审



  • 公开招标。针对国产数据库产品较多和应用场景复杂,积极开展技术评估和前期调研,经过公开招标,按照传统交易、数据分析、分布式交易三大分类入围多家国产数据库产品,并与相关伙伴签订框架合同。

  • POC 测试。经过 PoC 测试,包括性能测试、应用适配测试、价格比较,筛选出综合表现最优的产品。

  • 上线试用。上线试用期结束后,考虑核心业务系统最终选型的重要性,召开专题技术评审会对数据库选型进行充分认证。主要考虑:PoC 测试情况、试用实际表现、产品功能成熟度、生态成熟、产品可控度、已有案例情况、共同合作意愿、价格成本等。

  • 验收评审。按照上级相关要求结合应用系统特点提交年度信创实施方案,实施方案一次性通过上级组织的专家评审,选型数据库获得信创验收认可,符合信创标准。其中针对在线交易高负载类的核心类业务系统,采用 TiDB 进行有效支撑


国寿财核心系统替换案例及经验总结

在核心类系统替换上,国寿财全面梳理核心类系统非信创商用数据库、中间件及小型机、高端存储的使用情况,按照先易后难、积累经验,稳步推进的策略进行工作。2022 年,完成报价中心、承保支持系统国产数据库和中间件替换。2023 年,完成农险理赔中心、保单中心全栈信创替代。2024 年,目前已完成理赔中心全栈信创替换。



保单中心是公司最重要的核心系统之一,数据量近 69TB,支撑财产险、农险、信保、责任、意外、健康、水险以及特险合计 880 多款产品、2750 多款投保方案,覆盖投保、核保、缴费、批改、查询及打印全功能与流程环节,用户人数超过 5 万人,承载了财险公司出单交易处理。原有 IT 基础架构为 IBM 小型机 + Oracle 数据库 + 集中式存储,为集中式非信创架构,资源投入大、维护成本高、性能提升存在上限。


核心类业务系统属于在线交易高负载类型,基于上述信创选型替换原则,最终选择使用 TiDB 分布式数据库。实际上,在选型测试阶段,也考虑过了其他的分布式产品,如基于分库分表的方案。然而在充分调研后,国寿财认为更适合采用原生分布式方案。这是因为保险行业的团单等业务中,系统使用分库分表很难进行拆分,比如国寿财在 69T 的集中式数据库中有多张核心大表,单张大表达到 5.9 T,是整个业务的核心,所有业务都需要经过这张表,无法有效的分库分表



此外,分库分表方案还有很多其他的不足之处,比如成本高、经验难以复制,跨库事务、跨库关联能力不足,以及全局排序性能差、容易形成局部热点等问题,通常需要结合应用开发的适配改造工作。而原生分布式方案的 TiDB 数据库是一款原生分布式数据库,它相当于一款大号的 MySQL 数据库,在解决海量数据存储和计算的同时,数据均衡、全局授时等能力均由数据库内部机制自动完成,完全避免了分库分表对业务造成的复杂性。原生分布式方案是成本可控、经验可推广的更优方案。


TiDB 几乎完全保留了集中式数据库的开发使用习惯,因此,使用 TiDB 替换原有的 Oracle 数据库过程中对开发人员是相当友好的,不过这并不意味着应用层完全不需要改动。在保单中心项目的迁移过程中,涉及到语法适配、交叉销售改造、公共服务改造、MQ 拆分改造及数据交换平台改造等部分,如下图所示。



应用改造完成后,测试过程中发现 TiDB 数据库在执行计划选择算法上与 Oracle 有一定的区别。针对该问题,测试过程中采取如下措施,从而大幅减少系统切换后的性能问题:


  1. 将应用在原 Oracle 库里运行的 TOP 高消耗 SQL 通过 Oracle SPA 工具录像,提前在 TiDB 中进行回放验证。

  2. 通过 pinpoint、听云等应用端监控工具,将高消耗 SQL、热点表捕获,对热点表进行数据转储、SQL 场景优化。



在数据迁移过程中,国寿财保单中心系统中的数据具有存量大、增量大、单表大等特点。总共 911 张表,共计 69 T,增量数据 500G/ 天,其中有 7 张大表就占 18 T,单表数据量达到约 6 T。数据迁移过程中期望实现业务无感迁移及切换,即不停机、性能不下降。对此,国寿财在数据迁移过程中采取了相关的优化措施,使得全量数据迁移周期由 80 天压缩到 21 天内。


  • 对象分组。911 张表分组为 20 批次,合理规划执行顺序,保障导出、文件传输、导入三个阶段并行开展。

  • 昼夜分工。夜间业务低峰期,集中导出大表批次。日间根据业务运行负载,动态调整小表导出批次。

  • 大表分片。引入暂存库,实现单张大表多分片并行导出。



除了应用改造、数据迁移等方面,国寿财的核心系统替换还包括信创服务器性能优化、培训宣导、可观测性配置等优化与配置。


2023 年 10 月 29 日,保单中心核心系统顺利完成替换上线和验证工作,并顺利通过首个 “双十一” 业务高峰运行考验。保单中心的成功替换以下具有多方面的意义,首先实现了核心系统自主掌握实现重大突破,其次基础架构也实现了升级换代,另外整个业务支撑能力也得到大幅提升。



发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
头部保险公司国寿财核心系统采用 TiDB 实现信创替换并实现重大突破_实践案例_TiDB 社区干货传送门_InfoQ写作社区