金融行业正面临前所未有的变局。近年来，数字化转型已从头部金融机构引领下的“选择题”变为所有金融机构必须面对的“必答题”。随着数字经济时代的全面到来，数据量正从TB级跃升至PB级，甚至ZB级。传统数据架构已经难以承载如此庞大的数据量，数字化转型需要现代数据架构的有力支撑。数据库作为数据架构的“根基”，其质量决定了数字化转型的效果。传统数据库已无法满足现代数据架构的需求，金融机构急需彻底重构其“根基”。
OceanBase诞生于金融场景，项目于2010年启动，经过完全自主研发，从写下第一行代码到2017年完全承载整个集团的核心系统数据库，经历了7年的金融级场景考验与打磨。也正是在这一年，凭借对金融场景的深刻理解，OceanBase赢得了第一批外部金融客户的信任。随着2020年OceanBase商业化的加速推进，目前我们已经覆盖了70%的资产规模千亿银行、75%的头部证券公司、65%的头部保险公司和45%的头部基金公司。根据赛迪顾问《2022-2023年中国平台软件市场研究年度报告》显示，OceanBase在金融行业的国产分布式数据库市场占有率位列第一。
正因为有越来越多的金融客户选择与OceanBase同行，我们对金融行业的理解不断加深，对金融场景实践的沉淀和思考也在不断深入。深耕金融领域14载，“根自研”是OceanBase支撑关键业务系统、满足金融客户需求的最大底气。我们与上百家金融客户携手沉淀了许多最佳实践。此次总结一方面希望收到更多金融机构的反馈和建议，让“根自研”数据库OceanBase再进一步；另一方面，希望更多金融机构能在选型阶段结合数据库技术发展趋势，选择更具前瞻性的技术路线；在迁移阶段选择合适的升级路径，以更低的改造成本平滑迁移；在应用阶段贴合创新场景，充分发挥分布式数据库的效用。
一、金融数字化转型行至关键期
谈及数字化转型，如果说过去还只是头部金融机构带动效应下的“选择题”。那么现在，数字化转型已经成为不论大、中、小型金融机构都需要面对的“必答题”。
一方面是来自政策的推动。金融业一直是数字化转型“排头兵”。近年来，人民银行、原银保监会、证监会不断出台金融数字化转型相关政策，多方位加快推进金融数字化转型。其中，人民银行印发的《金融科技发展规划（2022—2025 年）》明确金融数字化转型的总体思路、发展目标、重点任务和实施保障，到 2025 年力争实现整体水平与核心竞争力跨越式提升。
另一方面是整体战略逐步向“以客户为中心”转变的加速。过去，金融机构侧重销售产品和服务，是典型的“以产品为中心”，随着消费者需求的不断变化，以及内外部竞争加剧，全面转向“以客户为中心”已经逐步成为金融机构的战略共识。这也就意味着，金融机构需要具备足够强大、足够敏捷的数字化技术，为客户打造个性化、精准化、智能化的体验，这关乎未来可持续发展。
二、走向现代数据架构，数据库成为金融数字化转型关键环节
数字化转型的本质是利用数据重塑传统业务与组织模式，构建企业的新型竞争力。随着数字经济时代的到来，数据量正在从 TB 级跃升至 PB 级，甚至 ZB 级。根据 IDC 测算，我国数据总量预计 2025 年将高达 48.6ZB，占全球总量的 27.8%。如今数据总量的 “大”已经和过去不是一个级别，而在 IT 领域“旧瓶”是装不了“新酒”的，金融机构亟需一套现代化的数据架构来作为数字化转型的支撑。
站在技术体系的发展角度看数字化转型，宏观上，海量数据的爆发来自于互联网的发展，业务的信息化、线上化爆点先从 SaaS 层开始，很快就触碰到了 IaaS 层计算网络等基础设施的瓶颈，从而推动云计算和大数据平台的发展。当 IaaS 层和 SaaS 层发展起来后，PaaS 层这种中间层的技术开始慢慢收敛、标准化，形成云原生、流/批计算平台、分布式数据库等配套的标准件。随着第二波 AI、WEB3 等革命的到来，SaaS 层又往下开始推动 IaaS 层实现新突破，比如算力、带宽、存储，进而促成新的 PaaS 层迭代。IaaS、PaaS、SaaS 层的演进关系如图 1 所示。
图 1 IaaS、PaaS、SaaS 层的演进关系
从微观上看，也是更偏技术架构的角度，其演进过程基本都是从最容易的、相对无状态的 SaaS 层开始。因为瓶颈出现后，SaaS 层是最容易改造的，面对更多的需求、更多的数据、更快的迭代速度，SaaS 层的解题思路就是从单体应用走向服务化拆分，再慢慢向云原生化演进。由于应用大部分是无状态的，整个演进的风险相对可控。
随后，来自业务和架构的压力很快从 SaaS 层传导到 IaaS 层，这一层虽然是有状态的，存储着关键数据，但离业务比较远，与应用间的关系更加弱耦合，基本都是通过标准接口进行交互。而且，云和新的存储、芯片以及网络层的发展并没有太多标准的改变。所以，在数字化转型过程中，IaaS 层基本能够相对“透明无感”，在不影响业务的情况下升级为国产芯片、存储、服务器等，为上层提供更强大的弹性算力和更高资源利用率的虚拟化能力。
当 SaaS 层改变，IaaS 层也紧跟着升级，剩下“最难啃的骨头”就在 PaaS 层了，这一层既与业务相关又有状态，往上需要承接 SaaS 层分拆后的分布式化的数据通信和运维管控，往下需要向与云底座相适配的云原生方向发展。而 PaaS 层中最难升级的又是数据库，无论是与应用的耦合度还是状态数据的重要性，都给数据库升级带来了巨大挑战。例如，金融机构的互联网业务经常面对脉冲业务的冲击，应用架构通过服务化架构和容器技术具备了更强大的数据处理能力和弹性伸缩能力，从而间接要求数据库具备海量数据处理能力和弹性伸缩能力，同时业务的分布式和垂直拆分要求数据库也是分布式的，但分布式有状态数据如何保证一致性，又如何应对大量数据库实例管理的复杂度……
这仅仅是数据库升级挑战中的冰山一角，我们已经无法用传统的数据架构来解决这些新问题。如果还是治标不治本，通过外挂或者各种外部软件与数据库软件拼装组合的方式来应对，只会让问题更复杂、风险变得更高。现代 SaaS 层应用架构和 IaaS 层基础架构的演进，都需要数据架构的根本改变，才能解决深层次的矛盾，才能应对现代业务场景的各种挑战。
三、金融行业面临的数据库升级挑战
（一）从边缘到核心，数据库升级全面提速
金融行业自 20 世纪 70 年代开启信息化建设以来便着手搭建核心系统，其作为金融机构的交易中枢，经过数十年的发展，在沉淀大量数据资产的同时，更是与周边系统盘根错节，可以说是“牵一发而动全身”。因此，大多数金融机构在开展信息化系统数据库新技术升级时，通常采取循序渐进、风险可控的策略，即先边缘系统再核心系统，不仅是为了逐步掌握新数据库技术，更是为了业务的风险可控。
“根自研“ OceanBase 自 2010 年立项以来，已经累计服务了数百家金融机构，覆盖 70%资产规模千亿元以上的银行，在证券、保险、基金行业的 Top20 资产规模企业中，覆盖率也分别为 75%、65%、45%。其中大部分涉及核心系统数据库升级，尤其以头部银行、头部保险公司为代表的金融机构开始涉足“无人区”，率先进行核心系统数据库的分布式升级，并取得了不错的成绩。
以某国有大行为例，国内首个贷记卡核心系统“大机下移”分布式已经稳定运行一年有余，目前已有 ECIF、对公网银等几十套系统数据库升级至 OceanBase，传统核心也在基于 OceanBase 进行大机下移和单元化改造；以中国太平洋保险公司（以下简称“中国太保”）为例，其采取“先难后易”策略，自关联关系最为复杂、商业数据库绑定程度最深、业务影响最多的核心系统——“P17 核心客户服务系统”（以下简称“P17”）投产上线以来，持续平稳运行，广泛服务于数千名柜面人员、百万业务人员和亿级外部客户，并将升级经验复制至其他系统，陆续有近 80 套系统数据库完成分布式升级。
从核心系统开始升级，有助于彻底抛弃原有的陈旧数据架构，更快地使用新数据库技术满足现代金融业务发展。当然，核心系统数据库在升级改造的同时，也伴随着边缘系统的数据库升级改造，并且得益于核心系统的经验积累，部分边缘系统上线更快。
这些先行者的尝试，已经验证了金融核心系统数据库新技术升级的可行性，并积累了大量的升级方法论。根据我们的经验，核心系统（含数据库）的整体升级大概需要持续 2～3 年。金融信息技术应用创新产业已经从边缘系统试点验证阶段向核心系统全面提速。加之时间窗口有限，核心系统数据库的新技术升级已经到了必须提上日程的时期。
（二）不同规模金融机构数据库升级需求各不相同
我们在服务客户时发现，不同规模金融机构结合自身 IT 水平、数字化能力以及人才组织配置等，在数据库升级时需求各异、各有侧重（如图 2 所示）。
首先，大型金融机构基础设施较好，对 TPS、响应时间等各方面的要求较高，所以关注点不仅包括分布式，还包括完整的单元化分布式整体解决方案以及在分布式架构下如何构建高可用的技术风险体系。
其次，大型金融机构需要整体升级的系统较多，迁移的数据量也较大，所以重点关注整套迁移方案的安全性和改造成本，数据库针对原数据库的高度兼容以及完整的迁移工具是大型金融机构最关心的能力之一。
最后，一般大型金融机构的基础设施也比较复杂和多样化，要求数据库厂商能基本兼容所有主流的国产芯片，同时可以多芯片混部，服务器上也是一样，可以在不同的云厂商中部署数据库服务器，进行跨云协同。
而对于中小型金融机构而言，其首先需要数据库具备分布式能力，但在使用上其根本不希望对此有感知，而是希望像集中式数据库一样使用数据库。所以原生的分布式能力尤为重要，这种架构避免了分布式的复杂性侵入应用，避免了分库分表改造和后期使用及运维上的限制。
其次，中小型金融机构更关注分布式数据库与应用厂商的适配，希望有应用厂商的兜底和大量案例，避免为升级底座而承担不必要的风险。要求数据库厂商与神码、长亮、中电金信等核心系统 ISV，以及宇信、天阳、赞同、易诚互动等应用 ISV 完成适配。
再次，中小型金融机构非常关心服务和培训，以确保有足够的服务人员可以保障后续的日常服务。
最后，中小型金融机构期望在硬件条件比较苛刻甚至受限的情况下，提供成本可控的高可用方案。
（三）不同用户数据库升级关注点各异
我们调研了若干家金融机构的科技总经理/CIO/开发人员/架构师/DBA/运维人员等，对于数据库产品，大家的关注点也各有侧重。总的来说，无论是架构升级还是自身能力迭代演进，首要目标都是确保稳定可靠，数据库升级过程要平滑，且可分层解耦、风险可控。
同时，作为基础软件的数据库，对应用系统的影响要尽可能做到最小，除了自身要提供完善的功能，还要对应用系统屏蔽自身的架构复杂度，让应用简单地使用数据库。比较一致的是，数据库要具备独立演进能力，保证技术栈的可持续发展和自主掌控。
（1）科技总经理/CIO 的主要关注点：数据库是否成熟稳定，且能否带来额外效益
作为数字化转型的关键环节，数据库要支撑业务系统长期稳定运行，可靠且不丢数据。对于金融业务，尤其是核心业务，稳定性和可靠性是第一位的，做不到稳定可靠的“1”，再多创新的“0”也没有意义。
因此，数据库是否做到真正意义的自主掌控，保证供应链安全和产品生态基础的可持续发展，对于关系国计民生的金融业务系统尤为重要，应确保长期无“断供”等相关风险，不会因为停止供应或者服务影响业务连续性。
此外，数据库作为数据安全防护的最后屏障，所涉及的组件会不会带来新的安全问题，这些都是金融机构的 IT 管理者、科技部门领军人非常关注的问题。在保证整体架构安全、稳定的同时，如果还能带来额外的效益，则更佳。比如做到性能不回退且成本不增加、支持业务未来的可持续发展、降低后续开发运维复杂度等。
（2）运维人员/DBA 的主要关注点：数据库维护是否操作简单，且具备更高的业务连续性
数字经济时代的到来，金融的数据量持续快速增长，原有集中式共享架构的部署模式，一旦发生故障难以快速自愈则需要大量人工操作，业务连续性将受到影响，因此数据库需要具备更高阶的可用能力和容灾能力。
大多数金融机构系统数量多、结构复杂，但大部分系统的业务量、数据量其实并不大。加上创新金融业务的迭代及发展速度远超预期，分散的集中式集群运维成本较高，同时容易遇到并发量、扩展性等瓶颈，将导致数据库的扩展成本、运维成本和管理复杂度的大幅提升。
因此，金融机构的运维人员/DBA 会更关注数据库维护是否简单易用，数据库升级后是否能有效提升资源利用率、降低整体运维成本、兼顾复杂度和维护难度、保证业务系统的连续稳定运行。
（3）开发人员/架构师的主要关注点：数据库升级是否平滑兼容，且满足未来架构长远演进要求
作为金融机构的开发人员或者架构师，数据库整体架构的可演进性是其首要关注点，而且要确保在满足业务需求的前提下，数据库做到平滑迁移。因为原数据库的兼容性稍差，就会导致业务改造整体成本非常高，而在此期间业务发展不等人，各类新增业务需求还会层出不穷，开发人员通常需要同时面对以下事项：
一是重写应用系统，包括新系统的设计、开发、测试等工作；
二是进行新数据库的迁移和替换，期间可能新老业务并跑，维护新老两套应用系统和数据库；
三是对接新业务需求开发；
四是解决上述问题叠加，可能会带来各类潜在风险和隐患。
因此，数据库需要具备较高的语法以及用法的兼容性，才能在极大程度上避免以上问题的发生，保证业务平稳上线运行。此外，数据库升级过程中一旦出现问题，需要支持回退、支持逐步替换升级或者长期并行验证。
四、金融行业需要怎样的数据库
（一）金融行业数据库技术架构演进
回溯 IT 技术的发展史，金融行业的 IT 应用基本走在行业前列。以银行业为例，其 IT 技术应用大致经历了三个阶段的发展：
第一个阶段，会计电算化时代，每个网点是一个账本，没有网络互联；
第二个阶段，网点互联时代，增加了网络互联，实现了省市级网点的互联；
第三个阶段，全国大集中时期，将数据库、应用、服务器等 IT 技术设施集中起来，由集中的数据中心提供数据和业务的处理，“IOE”架构成为首选。
互联网催生了电子商务的发展，诞生了网购和第三方支付业务，电子商务借鉴金融行业信息技术的先进应用经验，“IOE”架构以其稳定性、易用性成为当时的主流。随着电子商务业务飞速发展，以及“秒杀”“大促”等业务模式的出现，海量数据、高并发下，集中式数据库的性能出现瓶颈，而且“IOE”架构的成本越来越高。
为解决扩展性不足和成本问题，“中间件架构的分布式”架构诞生，基于国外开源数据库包一层分库分表等中间件，使用 PC 服务器替代小机和高端存储，并省去了数据库授权费用。业务模型简单的互联网交易场景获得快速发展。
然而，随着中间件架构的推广使用，其诸多缺陷开始显现。由于分库分表架构需要按照分片键查询，难以支撑无分片键的访问请求、难以增加不包含分片键的二级索引、难以支撑跨分片的分布式事务等。为解决这些问题，中间件架构大幅提升了应用层的复杂度，例如，双写业务表和索引表这两张表，而当这两张表跨越不同数据库实例时，又需要引入应用事务中间件等。
正是因为这些中间件架构分布式的缺陷，互联网的去“IOE”浪潮没能推广到更多的行业，而金融行业的业务模型复杂度以及对数据一致性的要求远高于互联网。
到了移动互联网时代，金融机构纷纷开启加速数字化转型。柜面交易量逐步被替代，由智能手机承载的金融服务方便随身携带。这些金融服务在业务类型上包括银行、保险、证券、基金、期货等金融领域，并且在业务范围上延伸金融行业服务客户的范围，开放金融、供应链金融、全场景金融等不断涌现。
传统的集中式数据库依赖单机的处理能力，因而存在架构上的单点。随着摩尔定律的失效，依靠垂直扩展的集中式走到了尽头，而金融业务的发展要求数据库具备海量数据下的高并发的事务处理能力。部分金融机构在架构转型中尝试中间件架构的分布式，在国外开源数据库上做二次开发，并取得一定效果，但随着深入应用依然出现瓶颈。为彻底解决海量数据、高并发场景的数据库的问题，原生分布式数据库架构诞生。
中国信息通信研究院在《大数据白皮书（2018 年）》中给出了数据库架构的发展方向，阐述了一致性协议 Paxos 的诞生为分布式数据库的发展铺平了道路，是对数据库发展历程的高度概括，也为数据库的发展指明了方向。这包含两重含义，一方面，分布式替代集中式是发展的必然，而原生分布式数据库是数据库发展的方向；另一方面，中间件架构的分布式只是过渡态。数据库架构演进过程如图 3 所示。
注：资料来源于中国信息通信研究院《大数据白皮书（2018 年）》
图 3 数据库架构演进过程
（二）中国场景驱动数据库技术创新，新一代数据库需要具备四大核心能力
自关系模型有了完善的理论支撑后，从 Oracle、DB2 到 SQL Server，商业数据库迎来第一波高速发展。当关系数据足够流行，上下游生态软件和应用软件的适配足够完善，以及在全球有足够广泛的开发者群体时。MySQL、PostgreSQL 等数据库以开源、免费版和简化版的形态推动了数据库历史上第二波更加广泛而影响深远的发展，但直到 1996 年后，OLTP 领域再也没有新的主流数据库出现（如图 4 所示）。
图 4 OLTP 领域主流数据库诞生时间点
这是什么原因呢？因为在使用场景上并没有实现代际跃迁，也就无法对现有数据库的能力和架构产生太大的推动力。直到以中国、美国为代表的区域迎来第一波 PC 互联网到移动互联网的高速爆发，在这之后，数据库领域慢慢开始有了新的变化，而比较有意思的是，这波移动互联网的变革，中国比美国更快、更彻底，也更快地推动了大量技术的发展甚至是变革。
2000 年左右，基础架构还没有反应过来，从应用层到中间件层开始解决集中式解决不了的问题，以 Cobar，MyCAT 为代表的中间件方案的分布式架构出现。一直到 2010 年左右，以 Google Spanner、OceanBase 等为代表的原生分布式架构出现，陪伴互联网高速发展了十余年，产品逐渐打磨成熟并开始商业化。
Forrester 相关报告指出，传统数据库在数字经济时代面临技术架构复杂、使用成本高以及安全性等严峻的挑战，企业迫切需要采用新一代数据库来处理海量数据，利用架构升级来消弭高昂的软硬件成本，并需要加强数据分析能力以推动企业洞察驱动的决策模式，从而进一步加速数字化转型，进而推动全社会数字经济的发展。新一代数据库需要具备低成本的极致性能、全维度的弹性灵活、洞察驱动的融合分析，以及全方位的安全可靠性四大核心能力（如图 5 所示）。
注：资料来源于 Forrester《OceanBase 总体经济影响 TM (TEI) 研究报告》
图 5 新一代数据库需要具备的能力
数据库是用出来的。OceanBase 过去十多年的发展，得益于飞速发展的移动互联网。这些年，从互联网支付核心到全场景金融核心，再到政企民生、运营商核心场景，以及新零售、新制造、互联网海量场景，OceanBase 参与并支持了一次又一次的关键业务负载，在千行百业的关键业务负载中不断深度完善、快速迭代。也正是因为这些，倒逼了分布式数据库技术的再次突破、创新和成熟。
对基础软件的发展而言，这是一条极为特殊的成长路径，也是最好的成长路径，在全球都很难复制，这是我们的幸运，身上也不由有了一种时代的使命感。
回看 14 年一路走来的历程，今天的我们得益于最初的决定——走“根自研”路线；得益于中国独特的场景——移动互联网爆发，带来前所未有的对海量数据、高并发的数据处理需求，以及这几年大量企业的核心系统升级，带来复杂业务场景下处理海量数据的需求。这些独特的场景使得 OceanBase 能够始终坚持创新探索，穿越“无人区”。借助中国场景，能够推动分布式数据库的四项新标准（如图 6 所示）。
图 6 中国场景推动分布式数据库的新标准
性能新标准：OceanBase 用一个引擎刷新了 TPC-C、TPC-H 两个榜单。高并发场景下可按需实现不停机、不改应用的弹性扩缩容；实现一份数据同时支持事务处理和实时分析。
容灾新标准：建立首个“三地五中心”城市级自动无损容灾新标准，保障城市级业务持续高可用。
高可用新标准：相比传统数据库，OceanBase 的高可用是自动切换的。与此同时，继 RTO 小于 30 秒后，进一步将 RTO 降低到小于 8 秒，故障恢复进入秒级时代，这也是目前业内 RTO 的最高水准。
架构新标准：“单机分布式一体化”在业内首次突破分布式数据库的单机性能瓶颈，使得数据库可以在现代数据架构下适应企业成长的全生命周期，其研究成果论文入选国际顶级数据库学术会议 VLDB2023，业界权威机构都非常认同这是分布式数据库架构的未来发展趋势。
（三）一体化数据库：支持不同规模金融机构/业务系统
我们在不断解决各种场景问题，尤其是关键业务的数据存储、处理、使用过程中，摸索出分布式架构数据库的最佳实践，逐步形成了“一体化”的解决思路。
从 2010 年至今，OceanBase 专注于 OLTP 场景，开始逐步打造满足现代数据架构需求的 TP&AP 一体化、多模、云上云下一体化、单机分布式一体化等核心能力，推出一体化数据库，支持不同规模金融机构/系统的关键业务负载。其中，“一体化”的理念包含以下两个方面（如图 7 所示）。
图 7 OceanBase 一体化数据库
第一，“一体化”的体验。在实际的应用中，数据库是解决数据存储、处理问题的手段，应用系统真正关心的、要解决的是业务需求问题，而不应该花太多精力在关心分布式带来的成本复杂度问题、处理各种数据结构带来的存储的差异性、不同数据库操作语法带来的好处、不同的负载或者基础设施带来的差异性等。我们用“一体化”设计来打造产品，让用户回归到关注业务，让数据库使用尽可能简单。
五、OceanBase如何应对金融行业面临的数据库升级挑战
（一）深度强化稳定可靠，保障服务不中断、数据不丢失
随着移动互联网和互联网金融的进一步普及，金融机构需要为客户提供无所不在、触手可及的全天候金融服务，双活、多活也成为金融科技的基本要求。随身化、实时化的金融服务要求 IT 系统提供 7×24 小时不间断服务，即使面临天灾、地震等自然灾害也需要保证业务的连续性。
我们在稳定可靠性方面投入最多，首创的“三地五中心”城市级故障自动无损容灾新标准（如图 8 所示），在高可靠性上不断升级，也一直在推动行业的发展。OceanBase 最早提出 RPO=0，RTO＜30 秒，目前已经是行业标配，这个还是数据库层面的自动切换时间，为了给连续性要求更高的业务系统留出更多时间，经过努力，我们将其降到了 8 秒内。
图 8 OceanBase 支持丰富、灵活的容灾模式
该架构底层采用 Paxos 协议实现将 Redo 日志在本服务器持久化，同时主副本在确认多数派副本 Redo 日志都持久化成功后，确认数据库事务提交成功，从副本利用 Redo 日志的内容实时回放，保证自己的状态与主副本一致，这种多数派同步机制也保证了少数副本发生不可用或者网络抖动时，业务系统也能够平稳运行，影响做到最小。
在金融行业比较常用的“两地三中心”部署架构中，OceanBase 可以通过仲裁副本的机制实现数据一致的真正双活，在双机房主备架构下，OceanBase 可以支持更细的容灾颗粒度，包括租户级主备库和备份恢复，实现更灵活的容灾部署和容灾切换，满足各个维度的业务容灾和业务切换需求。
以深圳农商银行为例，基于 OceanBase 采用“两地三中心”部署架构。2023 年 9 月，深圳因台风“海葵”出现超历史极值的罕见强降水，深圳农商银行部分系统可用性受到影响，OceanBase 顺利完成了异地 switchover 无损切换，支撑业务在异地成功运行，在真实场景中稳定应对危机，服务无中断，数据零丢失，有力保障了深圳农商银行的业务连续性与客户数据安全。
（二）持续平衡性能与成本，助力性能不下降、成本不增加
性能一直是 OceanBase 的强项，以前我们更多强调分布式的扩展性，并且用 TPC-C 7.07 亿 tpmC 这样极端的场景，验证了 OceanBase 无限的扩展能力。
分布式的强项是解决扩展性和容灾的问题，但冗余的多副本设计带来最大的副作用就是成本比较高。在这方面，OceanBase 的 LSM-Tree 存储架构和高效的 SQL 优化器，极大地平衡了多副本和并发处理能力，因此可以在性能和成本上达到很好的平衡。
（1）降低成本：降低数据存储相关的软硬件成本
当一个数据库承载的业务量变大、规模变大、系统数变多后，如何高效利用好每一份资源成为非常重要的目标。数据高压缩的同时性能无损，在基于传统 B+树的数据库中几乎是不可能的，但在 LSM-Tree 架构下经过设计使其成为现实。
凭借高压缩比的分布式存储引擎，在同一业务的数据存储量下，OceanBase 能显著节约存储空间，降低存储成本。对于数据量大、数据生命周期长的业务场景来说，可以极大地满足业务需求。比如，某国有特大型保险机构保险公司核心系统上线后，数据库压缩比高达 8 倍，业务数据库容量瘦身 78%，数据库软硬件成本缩减 75%。
（2）提升性能：提升业务系统的各项性能
金融核心交易系统的特点是事务交易链路长，涉及的 SQL 比较多，一笔交易可能包含上百个 SQL，同时核心交易场景对高并发，低延时，数据一致性是基本要求。
OceanBase 的分布式 SQL 优化器，全面支持 HTAP 能力，保障业务性能。比如，金华银行新一代核心系统采用长亮 V8 核心系统，完成从“小型机+集中式数据库+高端存储”到“PC 机+OceanBase 分布式数据库+普通磁盘”的升级，仅使用 18 台物理机，而在浙江同规模的某商业银行使用基于 MySQL 二次开发的数据库需要 40 台，并且新一代核心系统的性能也得到显著提升，日终批处理能力提升 5 倍以上、业务峰值处理能力提升 12 倍，批量代发时效提升 120 倍、季度结息效率提升了 8 倍。
（三）不断降低运维复杂度，以集中式体验享受分布式性能
OceanBase 在数据库内核、周边工具层面不断降低运维复杂度，期望运维人员/DBA 能以集中式产品的使用体验，享受分布式的性能。
（1）数据库内核层面：原生多租户架构，私有云上也可以做到 Serverless
随着金融转型，应用分布式/微服务改造等，金融业客户内部数据库数量剧增。多个微服务使用的数据库一般通过 schema 隔离，多个 schema 之间无法实现各自所需的资源的隔离，因此，资源碎片化、管理复杂、资源浪费、扩展性差等问题逐渐暴露出来。在这种情况下，数据库将会成为微服务体系框架中性能与扩展性的最大制约瓶颈。
加上基于 IaaS 提供大量数据库会带来巨大的运维成本和投资成本，以及难以快速供给等问题，数据库即服务（DBaaS）成为刚需。OceanBase 通过数据库内核实现原生多租户模式，提供数据隔离、资源隔离、故障隔离、弹性资源。
OceanBase 中的租户是一个逻辑概念，是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于金融核心分布式数据库的运维有着重要的影响，租户在一定程度上相当于传统数据库的“实例”概念。
有些客户希望通过多租户把很多单实例合并到一个大集群；有些客户希望租户的隔离性不要那么强，这样可以实现超卖；有些客户则把它用在各个省份的业务单元或者多法人机构，希望在运维上是同一套集群，但在隔离性上希望和物理机、虚拟机一样。
如图 9 所示，我们将业务系统不同微服务所需的数据库实例进行资源池化，提供不同规格的实例，在一套分布式数据库架构中实现多个数据库租户（实例）的资源池化能力，在保证资源隔离性的同时显著降低资源和管理成本，还依然能够保持优秀的性能和可运维性，将多个零散的数据库实例集中统一在 OceanBase 集群后，运维管理复杂度大大降低，负载、告警、调优全部统一至集群级别，常规故障能够自动恢复。
图 9 OceanBase 多租户资源池化
多租户可以应用于金融行业的不同场景，降低运维复杂度。
大型金融机构，比如，国有大型商业银行、股份制商业银行以及头部保险、证券等机构，可以按照地域分组、客户分组等方式，进行多租户划分，在一套分布式数据库环境中统一纳管，同时这种架构还具备业务灰度、流量调拨等能力。
省级农信机构，按照多法人主体进行划分。
银行、证券等机构，业务种类多，数据量和并发量相对不大的场景，按照多个小业务（多租户）大集中（一套分布式数据库环境）统一部署管理。
保险机构，按照不同业务流程的微服务进行划分，如收单、核保、保全、理赔等。金融业务中台，按照不同的中心划分，如用户中心、合约中心、产品中心、认证中心、支付中心、交易中心等。
（2）周边工具层面：“OCP+OAS”
分布式数据库同时运维多个节点，更需要集中式的管理工具统一管理。我们从 OceanBase 运维管理工具（OceanBase Control Platform,OCP）和 OceanBase 自治服务工具（OceanBase Autonomy Service,OAS）两个周边工具层为运维/DBA 提供可管理的手段，助力用户真正去解决实践中遇到的问题。相比于传统的分布式数据库产品，可进一步降低运维复杂度。
（四）完善平滑迁移方案，打造应用基本无感的稳妥升级
大量的数据库升级是存量替换的过程，如何保证迁移过程的平稳极为关键。OceanBase 经过多年商业化打磨，形成向上向下兼容、向上游向下游适配的整套迁移部署方案。
向上兼容方面，我们从 0.4 版本就开始做 SQL 语法，确定兼容 SQL 语法的原则。自 2008 年集团开启传统数据库升级以来，平滑迁移经验不断积累、Oracle/MySQL 语法兼容能力不断增强，Oracle 兼容性经过多年打磨，功能兼容覆盖率在 95%以上；MySQL 兼容版本也从 5.x 发展到 8.0，兼容 MySQL 8.0 的主流功能。应用只需要很小的改动，甚至无需改动，就可以迁移至 OceanBase 分布式数据库中。今年我们又增加并完善了 DBLink、JSON/XML/GIS/LOB 等大颗粒的功能；在 OLAP 方向常用到的复杂数据类型如 Nchar、Nvarchar 等也有了更好的支持。向下兼容方面，OceanBase 完成了基本全部主流芯片和服务器的适配，包括 7 款主流芯片和 10 多家整机厂商的适配。
向上游适配方面，具备四大类源端数据库的对接解析能力，其中包括 10 多款云上云下的数据库产品；向下游适配方面，则通过 Canal、Flink、DTS 等比较常见的数据同步工具打通上下游数据处理软件，同时支持 20 多款常见数据处理平台，可以无缝地跟原有的数据架构进行对接。OceanBase 平滑迁移方案如图 10 所示。
正是利用这套平滑迁移方案，西安银行用了 3 个月时间就完成了互金核心升级至 OceanBase。青海银行的柜面系统，耗时 1 个月即从 DB2 平滑升级至 OceanBase。某国有特大型保险机构全栈核心系统，仅用 1 年时间即完成整体升级，迁移规模和速度破金融行业纪录，全程无一例回切。
（五）OLTP-Based HTAP，实时分析回归业务本质需求
在数据库领域，是否需要“one size fit all”、是否需要 HTAP 数据库是业界长期关注的话题。然而一切还要从实际需求溯源，实际情况是无论是传统金融还是互联网金融场景，绝大多数业务系统都不可能是纯粹的 OLTP 或 OLAP。
即使是银行核心业务系统，联机是典型的 OLTP，而批量中有大量 OLAP 形式的负载。随着 24 小时实时批量的流行，很难把 OLTP/OLAP 负载进行非常清晰的切割；随着微服务化改造，各种数据中台、业务中台成为刚需，而各类中台本身的业务特点就是典型的 HTAP 混合负载。
行业内的通用解决方案是使用两套数据库引擎，分别提供 OLTP 和 OLAP 处理能力，两种引擎之间通过数据复制/迁移进行数据交换，这种方案能够解决一些问题，比如两套引擎各自支持 OLTP 和 OLAP 都可以支持得很好，但仍然明显存在着自身的局限性：
一是在不同引擎下，数据的一致性无法保证；
二是无法保证不同引擎下数据的时效性；
三是业务侵入性较强，OLTP 和 OLAP 两套库采用的 SQL 语法、数据类型不同，需要在数据同步时进行映射转换和应用修改；
四是将 OLTP 库和 OLAP 库完全独立会带来数据的冗余和维护数据同步，增加 TCO。
以常见的金融核心交易类系统为例，基于核心交易类系统的数据源下进行复杂查询、报表分析和批处理等是非常普遍的场景，传统数据库往往在一定数据量和复杂度的情况下会遇到可扩展性、性能或者并发的瓶颈，因此不得不需要两套软件的解决方案。
我们从存储层、SQL 层、事务层乃至链路层都进行了整体优化设计，提供“一体化”设计的 HTAP 混合引擎（如图 11 所示），通过一套数据、一套引擎同时支持 OLTP 和 OLAP 的负载。这样可以充分挖掘一份数据价值和一套集群的能力，数据在一致性、分析实时性和运维效率上取得平衡。交易数据原地分析，无需繁琐的 ETL 过程，数据最大程度保鲜，省去了很多业务场景中实时数仓的构建工作，帮助客户实现业务价值。
图 11 传统方式 VS HTAP 方式
中国太保利用 OceanBase 的 HTAP 能力，财险核心批处理相比于传统“IOE”架构，节省了 62% 的时间。同时，利用向量化引擎、优化器改写优化能力和大规模分布式并行执行技术，显著提升处理性能，财险分析型的数据加工处理能力提升 10 倍，监管报送批量场景性能提升 3 倍，构建起全面的实时数据处理和服务能力。
六、核心系统数据库，升级最佳路径实践
金融核心系统更换数据库，好比飞机在运行过程中更换发动机。如何在更换发动机的过程中不影响飞机的正常飞行，甚至让乘客感受不到这个过程，对于金融机构和数据库厂商而言都是一场“大考”。
（一）八个步骤
目前，金融机构的核心系统数据库主要以 Oracle、DB2 为主。从应用演进的角度，常见的金融核心系统数据库升级有平滑迁移和完全新建两种，平滑迁移侧重于应用不改或者仅有少量修改，保持库表结构基本不变的情况下，将数据库替换成分布式数据库；完全新建指建设一套新的核心系统，然后将老核心系统的数据与新核心系统的数据结构映射后完成数据的转换和迁移。
OceanBase 在服务众多金融机构的核心系统数据库升级过程中，沉淀出一套升级替换的方法论，供金融机构在核心系统数据库升级时参考（如图 12 所示）。
图 12 八个重点步骤
（1）需求分析与战略规划。首先金融机构需进行通盘的需求分析和战略规划。这包括评估现有系统的性能瓶颈、安全威胁、成本效益等方面，同时考虑国家关于金融信息化的政策导向及未来的业务扩展性、技术发展趋势。
（2）技术选型与方案设计。在明确需求后，选择合适的技术路径和方案至关重要。金融机构往往会考虑选择具有兜底能力的数据库，这不仅响应了国家的自主战略，也有助于降低对外国技术的依赖，增强金融信息系统的安全性。技术选型时会关注数据库的性能、稳定性、安全性、可扩展性及与现有系统的兼容性。
（3）应用适配、业务测试与评估。在实际升级之前，需要进行应用适配工作、详尽的业务测试与评估。这包括在测试环境中模拟实际业务场景，验证新数据库系统的性能、稳定性及业务兼容性。
（4）系统迁移与优化。系统迁移是升级过程中最为关键的环节。金融机构在迁移过程中，可能会采用渐进式、分阶段迁移的策略，确保每一步迁移都是稳妥可靠的。迁移后，需要对系统进行调优，确保其能满足业务需求并达到最佳性能。
（5）业务验证与持续监控。系统升级上线（跟账上线或者灰度上线）后，需要进行业务长期跟踪验证，确保所有业务流程在新型数据库上都能正常运行。此后，还需建立持续监控机制，实时跟踪系统性能和稳定性，以便快速响应可能出现的问题。
（6）安全与合规。数据安全与合规性是金融机构无法忽视的重要方面。数据库升级后，需确保满足国家相关金融信息安全的法律法规要求，加强数据加密、访问控制、安全审计等措施。
（7）培训与文档。为了确保系统升级后人员能够熟练操作新系统，金融机构会组织相应的培训。同时，完善的技术文档和操作手册也是必不可少的，以便于日常运维和未来可能的系统迭代。
（8）持续迭代与优化。金融机构的信息技术架构不是一成不变的。在完成核心系统数据库升级后，需要根据市场变化和业务发展需求，持续对系统进行优化和迭代，保持系统的先进性和竞争力。
通过以下三点，可帮助金融机构的核心系统数据库实现平滑迁移。
一是高兼容与广适配，即极高的兼容性和广泛的上下游适配能力，包括国产软硬件、中间件和大量行业软件。其中，高兼容不仅体现在原生的支持各种原数据库的数据类型、SQL 功能和数据库对象，以及数据库安全、备份恢复、高可用和优化器等高级特性；而且在保持各种原数据库的开发、运维使用习惯上也在不断迭代。
二是完善的周边迁移工具，即一整套成熟的自动化迁移工具，包括兼容性评估、结构迁移、数据迁移、对象迁移等工具。如 ODC 开发工具尽可能保留原有的 Oracle PL 开发/调试习惯，通过 OMA/OMS 实现高度自动化的迁移评估+数据迁移/回迁功能。
三是成熟的迁移方法论，即大量内外部传统集中式数据库升级迁移项目所沉淀出来的升级迁移方法论。
（二）四条路径
从最早提出“IOE”以来，我们就已经在集团内部承担了传统集中式数据库的分布式升级重任。我们从在内部电商、第三方支付、首批民营银行等内部场景苦练内功，具备了较强的 Oracle 兼容性，到拥有第一家商业银行客户，以及在大型保险机构、运营商等重度使用场景，不断与客户共同打磨兼容性，如今已经服务了众多大中小型金融机构。
得益于完全自研，OceanBase 不会有基于 PG/MySQL 开源版本上与 Oracle 进行兼容的桎梏。经过长期内外场景打磨，OceanBase 的兼容性日趋成熟稳定，主线的 GA 版本即可满足升级需求，无需通过定制化版本来支持。在这个过程中，我们也总结出核心系统数据库升级的四条技术路径（如图 13 所示）。
图 13 核心系统数据库升级的四条技术路径
路径一：Oracle 平滑升级迁移
Oracle 在金融行业是最常见的集中式数据库，在金融业务场景的覆盖上兼具广度和深度。当分布式转型升级到来，银行、保险、证券、基金等金融行业的客户需要最短、最快的转型升级方案，于是产生了该方案。其特点是，在应用代码少改或者不改的情况下，依靠分布式数据库的兼容性实现。OceanBase 基于自身的高度兼容（95% 以上，若严格对标 Oracle 12C 文档的功能项，兼容性在 85%）及多年积累的体系化的迁移工具与迁移经验，通过“全面语法兼容”配合客户实现平滑迁移（如图 14 所示）。
图 14 Oracle 平滑迁移示意
以某国有特大型保险机构为例，从 2020 年 9 月～2021 年 9 月，仅用时一年即完成包括传统核心在内的近百个业务系统近 800 套在线 Oracle 数据库的全量搬迁工作，迁移数据规模超 400TB、数据量超千亿，单库数据规模超 20TB，存储过程行数总数 500 万行以上，整个迁移过程无一例回切。业务改造“Pro*C+Tuxedo”的兼容能力和平滑迁移方案，避免了上千万行老核心代码的重写。
采用此路径的还有中国太保的“P17”、金华银行新一代核心系统以及广发证券的核心估值系统等。
路径二: “大型主机 DB2 迁移分布式数据库+单元化”方案
因业务规模大、范围广、复杂度高等，国有大型商业银行是分布式转型中的难点，同时国有大型商业银行在新一代核心建设中有单元化等架构方面的建设要求。
以某国有大行为例，某国有大行的贷记卡、借记卡、ECIF 这三大核心系统均已转型为分布式，其中，贷记卡核心系统采用“阿里云+SOFA 中间件+OceanBase 分布式数据库”整体技术栈，实现“两地四中心多地多活+单元化”设计。基于 OceanBase 多租户特性，跨多集群百租户百库百表单元化设计，其中 5 个单元化（Rzone）集群：每个集群 20 个租户，每个租户对应一套分片库/表，总共百租户/百库/百表，统一按客户内部编号分片，实现资源隔离和减少爆炸。OceanBase 分布式数据库+单元化方案如图 15 所示。
图 15 OceanBase 分布式数据库+单元化方案示意
OceanBase 具有超高的写入性能，支持长亮、天阳分别采用联机写入和多表 join 写入等不同的数据迁移方式，4 小时内即可完成全量数据从大机卸数、数据转换。从大型主机下移到 x86 服务器，贷记卡核心交易 TPS 提升 6 倍，跑批效率提升 7 倍以上，达成授权交易端到端耗时 80 毫秒以内的性能目标，并实现自动化运维、可观测与安全生产。
路径三：小型机 DB2 升级 OceanBase
小型机 DB2 在中小银行核心系统的数据库中占用重要位置，而中小银行普遍采用新建的方式建设新一代核心系统。其中，一部分选择 OB-Oracle 模式，实现一套核心应用分别部署在 OB-Oracle 和 DB2-Oracle 两种数据库上，实现双逃生；另一部分选择 OB-MySQL 模式，分批切换，一步到位。
以常熟农商银行为例，新一代核心系统从方案论证到交付实施，历时 18 个月，基于 OceanBase 构建起两地三中心五副本及主备架构，采用 OB-Oracle 租户，实现新一代核心系统 OB-Oracle 和 DB2 开启 Oracle 兼容的双容灾。OceanBase 一主拖两备架构，主集群和异地备集群采用 x86 芯片，本地备集群完全国产，包括 ARM 芯片、麒麟操作系统，做到“一库多芯，混合部署”。相比老核心系统，新一代核心系统的每秒交易处理能力提升 46 倍，日终批量处理能力提升 41 倍，批量代发代扣处理能力提升 651 倍。小型机 DB2 升级 OceanBase 示意如图 16 所示。
图 16 小型机 DB2 升级 OceanBase 示意
采用此路径的还有云南红塔银行、深圳农商银行的新一代核心系统等。
路径四：MySQL 平滑升级迁移
十多年前，为应对互联网发展带来的高并发、海量数据对数据库的挑战，电商、第三方支付企业以及民营银行进行了去传统集中式数据库的探索，MySQL 或中间件架构的 MySQL 是主要替代品，在整个金融行业覆盖度仅次于 Oracle 和 DB2。
诚然，MySQL 主要用于互联网核心或非核心系统，且大部分情况下为“完全新建”，“平滑迁移”为少数。与“Oracle 平滑迁移方案”类似，得益于高兼容性，选择 OB-MySQL 模式即可在应用基本零改动的情况下，从源数据库完成平滑迁移。MySQL 平滑迁移 OceanBase 示意如图 17 所示。
图 17 MySQL 平滑迁移 OceanBase 示意
以西安银行为例，其快捷支付系统——西银惠付通过在 OMS 不停机的情况下实施 MySQL 向 OceanBase 的完整迁移。从 2019 年 2 月进行数据库评估分析，到 2019 年 5 月正式业务切流，3 个月即完成迁移。迁移后，西银惠付的数据压缩为之前的 1/2，各项系统性能显著提升。
（三）核心系统数据库选型建议概述
赛迪顾问 2023 年 2 月发表的《核心数据库升级选型参考》报告显示，核心数据库选型因素涵盖数据、功能、效果三个层面（如图 18 所示），为金融机构的核心系统数据库选型提供了清晰的思路。
注：资料来源于赛迪顾问《核心系统升级选型参考》
图 18 核心系统数据库选型因素
首先是数据层面，其主要包括数据一致性、数据安全性以及底层代码安全性。数据一致性不仅局限于事务发生时，还需要考虑数据库是否具备多副本数据校验、主备库数据校验、链式数据校验以及数据定时校验的能力；近年来国家高度重视数据安全性，数据库需要具备让数据资产避免未经授权的访问、损坏或盗窃；底层代码的安全性涉及软件产品的本质安全，金融机构核心系统应优先选择完全自主研发的数据库，而非基于开源的数据库。
数据层面的选型考量相当于“1”，数据库只有在这个层面具备足够的能力，后续拥有其他的“0”（如更高的性能、更低的成本等）才有意义。
其次是功能层面，其主要包括兼容与迁移、双写及回迁、事务处理、大数据实时分析能力。金融机构的核心系统如何有效降低数据迁移复杂度和迁移成本，主要依赖数据库的兼容与迁移能力，尤其是 Oracle 的兼容能力；一旦出现问题需要异构数据库切换或回滚，确保业务正常，这与数据库的双写、回迁能力紧密相关；事务处理能力和大数据实时分析能力则是 OLTP 和 HTAP。
七、典型金融场景实践
（一）银行
随着金融数字化转型的逐渐深入，银行业产品百花齐放，不同银行对于业务经营更多的是拼“软实力”。从内部来说，银行需要提升信用风险管控能力、提高优质资产率、满足监管合规要求等；从外部来说，银行需要通过设计特色化、差异化的营销手段提升用户体验和用户忠诚度，同时利用数字化手段通过全渠道为用户提供无处不在、触手可及的全天候、全场景、全生命周期的金融服务。
无论是从内部还是外部，“软实力”提升都需要借助数字化能力得以实现。而作为数字化转型的关键环节，OceanBase 在国有大型商业银行、股份制商业银行、城市商业银行、农村商业银行、省级农信社等经过多年打磨积累了相当丰富的经验，助力银行业务系统尤其是核心系统更好地承担数字化转型重任。
银行业务系统按照用途可以分为存款系统、贷款系统、客户管理系统、渠道系统、会计系统、风险管理系统、内部支持系统等，典型的银行系统业务全景架构如图 19 所示。
图 19 典型的银行系统业务全景架构
银行核心系统是指银行提供财务服务、进行日常操作的基础软件系统，通常包含客户和机构管理、存款管理、贷款管理、产品管理、交易处理、支付和结算等，是银行最重要的业务系统。
从银行业务服务的角度，银行核心系统主要包含 ECIF、贷记核心、借记核心系统三部分，其中 ECIF 系统提供客户信息的管理，贷记核心系统如信用卡系统、贷款系统等，借记核心系统即银行卡核心系统，三大核心系统按业务实现方式可以分为跑批类场景和交易类场景。
（1）跑批类场景
跑批类场景天生就是高并发的联机交易，最重要的是时效。若跑批时间过长，轻则造成客诉，重则导致资损，甚至出现舆情事件。
这类场景对数据库处理能力的有效检验方式之一就是如何快速完成批量交易，因为需要频繁地对数据库进行增删改查，进行大量的 I/O 物理读和逻辑读计算操作，应用访问数据库的吞吐量也尤为关键。集中式数据库上性能的容量有限，跑批业务需要的时间缺乏弹性，一旦出现突发情况，可能留给跑批的应急处理时间有限。
贷记核心：贷款的批量扣款还款是面向个人提供的车贷、房贷等贷款的定期扣款还款的业务，扣款还款是银行回收借款本金和利息的途径，若因银行扣款不及时产生逾期利息，可能导致客户投诉；信用卡营销需要在更短时间内将优惠信息推送到客户的移动端，以保障活动效果。
借记核心：日终批量用来标记银行逻辑日的结束，跑批及时性决定着银行这一天的业务真正结束；季度计息是个人在银行中每个季度结算一次的活期存款利息，结息日一般放在每个季度最后一个月的 20 日；银行面向企业提供工资代发服务，一般要求在 2 小时内完成工资发放；面向个人提供水电煤等费用的代扣代缴服务即时到账，从而保障用户体验。
原生分布式数据库利用多台机器的并发能力，并通过弹性扩缩实现动态的资源调整，因而在跑批场景具备优势。如避免分布式事务和远程访问，让所有服务器全部参与批量结息过程，提高处理速度；分散负载到多个节点，减少单一节点的压力；迅速扩容以应对流量高峰，同时在低峰期自动缩减资源以节约成本；允许读操作分散到多个副本，而写操作则在主节点上进行，减少读写竞争等，大幅提升批量场景效率。
银行在核心系统分布式转型中一般通过新老系统对比、银行同业对比两种方式来衡量。老核心（全栈国产分布式升级前）新核心（全栈国产分布式升级后）系统的跑批指标对比见表 1，同等规模商业银行日终批量、批量代发实际值对比见表 2。
表 1 老核心（全栈国产分布式升级前）新核心（全栈国产分布式升级后）系统的跑批指标对比
表 2 同等规模商业银行日终批量、批量代发实际值对比
综上，在跑批场景中原生分布式数据库相较传统集中式数据库的优势非常明显，在银行同业对比中相较传统集中式数据库或者基于 MySQL 二次开发的数据库也具备明显优势。
（2）交易类场景
在交易类场景中，最重要的是单笔交易耗时和交易吞吐量。若单笔交易耗时过长，则影响用户体验；若性能容量的 TPS 不足，则会造成高并发场景下部分客户的业务连续性无法保障。
ECIF 系统：作为全行业务的基础系统，提供客户信息的查询服务，整体以高并发的读操作为主，影响全行几乎所有业务系统的可用性；写操作主要是开户链路。
贷记核心：信用卡营销活动中产生大量交易，这些交易峰值常集中在信用卡营销日，其中用餐时间前后最为明显，信用卡交易的交易耗时和性能容量关系到每一个消费者的信用卡交易体验。
借记核心：存款与贷款是银行的传统业务，而存贷比是评价银行风险水平的重要监管指标；银行卡具有转账、存取现金和消费功能，同时可以支持一卡多账户、多币种。随着移动互联网的发展，移动支付成了重要的支付渠道，银行卡交易的单笔耗时和性能容量不仅是银行信用的体现，同时也是许多创新业务营收的基石，如银行卡买基金、买外汇、买保险等。
伴随新一代核心系统的分布式转型，分布式数据库在交易性能容量方面具有天然优势。在单笔耗时方面，应用和数据库同时转型分布式时耗时增加有限，业务上完全可接受。例如，某大型商业银行信用卡核心转型分布式虽然从 60 毫秒增至了 80 毫秒，在耗时有限增长的情况下，提供了机房级容灾能力，为业务连续性提供更好的保障。
某商业银行在核心系统交易类场景比对上更加精细化，其以一借一贷和混合压测这两种场景的压测结果进行度量，并进行了同规模银行的同业数据对比。如表 3 所示，该银行的新一代核心系统在同规模银行中处于领先地位，这也进一步印证了原生分布式数据库对新一代银行核心系统的支撑能力。
表 3 同等规模商业银行一借一贷、混合压测场景数据对比
在金融数字化转型的浪潮中，银行新一代核心系统中无论是跑批场景还是交易场景，原生分布式数据库都能够为业务提供更好的支撑力。某国有大行、常熟农商银行、云南红塔银行、深圳农商银行等新一代核心系统，以及某国有大行 ECIF 系统等均选择升级至原生分布式数据库。
（二）保险
近年来，保险行业出现了非常明显的行业变革特征，传统保险的经营方式，无论寿险还是财险都难以实现大规模增长。数字经济时代的到来让这一趋势更加明显，倒逼各大保险机构从跑马圈地式发展升级为高质量发展。
粗放式地不计成本获取客户和保单已经成为过去，从线下地推到线上获客、从人海战术到精英化代理人团队、从单一化产品到综合型/定制化产品、从单一保单销售到客户长期陪伴乃至发展多维高频业务。
要做到这些，保险机构必须进行数字化转型，通过 IT 战略和商业战略的有机结合，灵活响应业务需求、开发优质保险产品、提升服务质量和客户满意度、降低服务成本。保险机构的 IT 系统大致分为三类，保险系统业务全景架构如图 20 所示。
图 20 保险系统业务全景架构
核心业务系统：满足产品定义（包括产品定价模型定义）、报价、批改、理赔、续保、再保等全流程保险业务需求，不同险种拥有单独的核心系统，是险企的刚需系统。系统提供精算、产品设计、核保等业务功能以及支持日常事务处理的技术组件，同时能够对接其他渠道、管理系统。
渠道系统：包括营销管理、银保系统、呼叫中心、电子商务等子系统，主要辅助核心业务系统进行营销展业。
管理系统：包括风险管理、客户关系管理、商业管理、财务管理等子系统，主要负责进行日常事务管理，功能模块可由数据中台提供支持。
在“互联网+”的大背景下，保险机构应扬长避短，结合自身特点，借鉴互联网金融的成功经验，从传统的烟囱式的 IT 架构转变为以“云平台底座+分布式数据库”为基础的一体化 IT 架构，从而完成业务模式的转型，最终实现弯道超车。
遵循国家自主可控的战略要求，各大保险机构也开始了新数据库的升级，近两年取得了不错的成绩，在不少系统积累了大量数据库升级迁移的成功案例。但寿险、财险核心业务系统仍然是数据库最后和最大的“拦路虎”，其难度超出其他系统不止一个数量级，是非常难啃的“硬骨头”，所谓“行百里者，半于九十”。
（1）寿险核心场景
保险机构的寿险核心业务系统重构频率比银行低，很多都有超过 10 年，甚至 20 年的历史，完全推翻、重构这些业务代码难度和风险极高，可以说既是宝贵财富也是沉重负担。寿险业务主要具有以下特点。
业务场景复杂：相比银行业务，寿险业务模式更复杂、业务流程更长、复杂查询更多。例如，寿险业务通常会有数分钟的长流程事务，相对而言，银行业务基本都是短事务；各类多层次嵌套子查询、关联子查询、多表关联比比皆是。
业务数据量大：寿险业务从客户开户、参保以来所有的历史数据都是“热数据库”，要参与计算，存量数据生命周期长，数据量的增长对业务性能有明显影响。而大部分银行业务超过一定时间的数据都不会参与计算，比如，超过 1 年的数据可以归档到历史库作为“冷数据”处理，不参与日常业务处理，数据量的增长对业务性能影响较小。
业务突发流量高：银行业务每天的时段业务量和业务种类都比较平均、非常有规律。因其行业特性，寿险业务经常有“开门红”“周周红”这样的促销活动，虽然日常资源使用率不高，但某些特定日期业务量突增，可能达到平常的 10 倍以上甚至更高。
过去，寿险核心业务系统基本 90%以上使用传统集中式数据库，面对以上业务特点，随着数据经济的加速前行，其在容量、性能、云化、多模等方面都已经愈发力不从心。
一是复杂 SQL、大数据量的性能挑战。在大多数场景，OceanBase 均能获得和 Oracle 相似的性能；在某些特定场景，OceanBase 可以通过并发获得比 Oracle 更佳的性能。值得一提的是，我们在进行优化时可以直接参考 Oracle 的执行计划，将之以 hint 的方式直接应用于 OceanBase 中，用于固化执行计划不准的 SQL 语句，大大降低性能问题带来的生产运行风险。
二是突发流量的挑战。如果按流量最高峰来配置集群资源，显然是一种极大的资源浪费。我们在支持历年“双十一”的过程中，锻炼出透明扩缩容的能力。在促销活动前，可以提前将准备好的物理服务器或云上 ECS 动态扩容到集群中；活动结束后，再缩容将机器归还，从容应对业务流量高峰。
某国有特大型保险机构的寿险核心系统数据库升级至 OceanBase 后，最大化利用资源，通过动态弹性调整租户计算资源，敏捷应对业务负载要求的变化，经受住“开门红 TPS 5 万+”、“QPS 21 万+”的严苛考验，稳妥保障业务连续性和数据准确性。
某国有特大型保险机构核心业务群的 60 多套系统，300 多套 Oracle 历时一年完成向 OceanBase 的迁移，数据库存储容量瘦身 78%，数据库软硬件成本大幅缩减 75%，实现 RPO=0 的最高级别容灾能力，满足国家级金融基础设施要求。
（2）客服系统场景
客户服务系统通常是保险机构关联关系最为复杂、商业数据库绑定程度最深、业务影响最多的核心业务系统之一。秉承“以客户为中心”的理念，该系统除了提供 7×24 小时服务外，还具有以下特点。
一是数据量庞大：随着互联网保险业务的开展，客户服务系统需要支持越来越多互联网类型的业务，这些业务不仅数据量大，还有瞬时高并发的特点。
二是割接要求高：客户服务系统上下游对接系统众多，客户服务系统停机窗口时间要求极短，对迁移及数据校验都是挑战。
以中国太保的“P17”为例，其是产、寿、健康、长江等所有子公司客户服务系统的整合，为公司 6 地 8 个客服中心超过 2000 座席提供系统服务。与一般热线系统相比，“P17”涵盖了中国太保几乎所有子公司业务的服务入口功能，包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等，对接周边系统超过 200 个。
“P17”对 Oracle 兼容性要求高。与其他保险核心系统一样，挑战最大的还是“P17”与原数据库的深度绑定。“P17”对原数据库特性使用非常深入，包括自定义锁、自治事务、嵌套表、索引组织表、PLSQL 包、物化视图、DBlink、触发器、系统视图。其存储过程数量庞大，总代码量近百万行。
“P17”周边对接产品多。“P17”集成了大量周边工具软件和应用，与很多周边软件协同工作，如 IBM Datastage、IBM Cognos 等，这些软件都利用了原数据库很多特有的功能，更换数据库后需要对这些软件重新适配。
凭借 OceanBase 的高度 Oracle 兼容性、完善的迁移工具链，经过近一年的技术攻坚，“P17”完全迁移到 OceanBase，百万行 PL/SQL 代码平迁复用。
在全面升级后，原生分布式数据库的优异性能展现出来。中国太保在保持高运行性能、高可用能力的同时，数据库软件的运维费用大幅降低，每年可节省设备投入数亿元。特别是 OceanBase 的高级压缩技术，结合“数据库瘦身”，将存储容量节省 80%以上。可以说，升级后的应⽤系统弹性扩缩容、处理速度、数据加⼯能⼒均实现⼤幅提升。
（三）证券和基金
自券商的主要经营方式由网点营业部模式转变为总部集中模式，在集中交易系统的建设背景下，关系型数据库的重要性愈加突出，以 Oracle、DB2 为代表的数据库产品几乎占据证券和基金的各类核心业务系统。
伴随金融数字化的全面开启，新形势下行业规则不断变化，证券和基金业务的创新争分夺秒，精细化服务客户成为重中之重。传统烟囱式、系统紧耦、信息分裂的系统架构已经无法适应当前的业务发展。
证券和基金行业的关键业务系统包括集中交易系统、理财系统、法人结算系统、第三方存管系统、开放式基金代销系统、风险监控以及反洗钱系统、网上交易系统等 7 小类系统，此外，还包括反欺诈引擎、数据平台、进件系统、催收/贷后系统、呼叫中心等。证券业务全景架构如图 21 所示，基金业务全景架构如图 22 所示。
图 21 证券业务全景架构
图 22 基金业务全景架构
核心系统整体上可分为两类，一类是以股票交易为中心的在线类业务，另一类是以基金/资管为中心的“T+1”业务。对于数据库而言，前者强调极致的低延迟与高可用；后者则通常涉及批处理、大事务、复杂查询、备份恢复，对数据库的综合能力有较高要求。
（1）UF3.0 核心交易系统
证券机构的集中交易系统，对外与沪深两个交易所的系统对接，对内则与其他各种系统对接，具有投资者开户、证券交易委托和成交、各种维度的查询等功能。其中“委托”和“成交”是最主要的功能，也称为“路由”功能，同时还有资金买空或证券卖空的“监控”功能，以及“查询”功能。
传统集中交易系统通常直接引入一体机解决性能问题，但是众多系统仍以“竖井”的方式建设，配套硬件成本、部署成本等整体成本投入大。由于单体架构的先天限制，在容量和性能遇到瓶颈时无法横向动态扩容，制约系统的整体处理能力。
恒生电子的 UF3.0 采用分布式微服务架构实现交易、清算、管理的三大模块，整体架构设计与 OceanBase 相契合，提升业务处理能力，加快交易结算速度，提高证券客户满意度。UF3.0 业务架构如图 23 所示。
图 23 UF3.0 业务架构
招商证券、东方证券等券商公司新一代核心交易系统选用基于 OceanBase 的 UF3.0 支持整体 IT 业务平台，提供综合金融服务。
以招商证券为例，其 OceanBase 承载了包括 UF3.0、数据中台服务、Level2 行情数据等共计百套业务系统。用“国产原生分布式数据库+国产服务器”替换“中高配 x86 服务器+传统集中式数据库”，节约整体拥有成本约 70%。其中，UF3.0 将原先分布在不同数据库的全量历史数据集中到 OceanBase，数据由原先的 50TB 压缩到 5TB，自此招商证券的用户能够直接查询自开户以来的全量历史交易流水、进行远期历史查询，不再需要临柜办理，使用体验显著提升。
（2）ETF_TA 系统
TA 系统全称为开放式基金登记过户系统，用于记录投资者买入和卖出的基金份额，是基金公司的核心业务系统之一。TA 系统和典型的 OLTP 业务（如在线联机交易）不同，清算跑批必须在规定的窗口时间内完成。
同时，TA 系统属于比较复杂的“跑批”业务，涉及的数据量较大，计算逻辑也比较复杂，存在多表关联和复杂查询，并且步骤多。比如，清算过程中有串行的、复杂的对账查询，也有需要高并发的小事务清算，还涉及大量的文件导入导出。
因此，TA 系统对数据库的综合要求较高，不仅要高稳定、高可靠，同时也要高性能。
OceanBase 通过稳定的 SQL 引擎保障复杂查询的执行效率，完全满足系统的高并发、数据高并行的业务特性，通过多租户架构（如图 24 所示），支撑 TA 系统的分布式微服务架构，提升资源利用率。分布式数据库的扩展性，让 TA 系统跑批效率随数据库节点增加而提升，未来基金用户数、交易数上升时，能在不调整业务架构的前提下，通过数据库层的横向扩展支撑业务发展。
图 24 OceanBase 多租户的 TA 数据分布
易方达基金通过 OceanBase 的多租户与 TA 分片对应，分别设立了账户、清算、汇聚三类租户。将来如果业务量增长，扩容增加服务器后，可以把其中几个租户在线迁移到新的服务器上，这样每个租户的可用资源增加，对业务而言则无感。不仅如此，和从一开始就将设备部署到位相比，这种按需扩容还可以节省前期投资。
2022 年底，经过一年的双轨并行之后正式切换到 OceanBase 独立运行，易方达基金的 ETF_TA 系统成为基金行业首个基于国产数据库单轨运行的 TA 项目，同时也标志着国产数据库在基金行业迈出的关键一步。
安信证券的新一代 TA 系统上线 OceanBase 后，登记过户的跑批清算时间由 2 小时降低为 1 小时，TA 系统的清算时间缩短为原先的 50%，对上下游业务系统而言，登记过户相关的整体运营效率得到显著提升。
八、写在最后
感谢选择与 OceanBase 同行的每一位金融客户，感谢您的信任，金融行业对数据库有着最为严苛的要求，数据库影响面广、重要性高，在如此重要场景能选择 OceanBase 作为一个新的数据库，这份高度信任难能可贵，也来之不易；感谢您的建议，OceanBase 从 1.x、2.x、3.x 到如今实现多项业内首创的 4.x 版本，产品能力持续提升，技术发展持续向前，正是因为有金融客户给我们提出大量宝贵的、出色的建议，很多关键输入都来自金融场景、源自金融客户。
“九层之台，起于累土。” 作为一款“根自研”的分布式数据库，OceanBase 致力于打造负载关键业务系统的一体化数据库，让更多金融机构在数字化转型升级的过程中用一个数据库就能解决 80% 的问题，数据架构更加适应现代应用开发、AI 延展等，并能享受一体化架构带来的技术红利。后续，我们将继续携手服务、技术、ISV 等生态伙伴攻坚关键业务系统，为金融数字化转型贡献更大的力量。
