OceanBase 在证券行业基金资管场景落地实践与解决方案

自从证监会发布《客户交易结算资金管理办法》以来，券商的主要经营方式由网点营业部模式变化为总部集中模式，在集中交易系统的建设背景下，关系型数据库的重要性愈加突出，以 Oracle、DB2 为代表的数据库产品几乎占据了整个券商的各类核心业务系统。

证券基金行业的核心系统整体上可分为两类，一类是以股票交易为中心的在线类业务，另一类是以基金/资管为中心的“T + 1”业务。对于数据库而言，前者强调极致的低延迟与高可用；后者则通常涉及批处理、大事务、复杂查询、备份恢复，对数据库的综合能力有较高要求。

本文重点描述近年来在基金/资管场景下，OceanBase 整体解决方案与落地实践。

基金资管的业务架构与数据库实践

业务模型

典型的资管场景业务架构如下：

• 对客查询系统：终端用户通过券商/基金的直销渠道或互联网分销渠道执行买入、卖出、查询等请求；

• TA 登记过户系统：登记用户交易请求，在每笔交易链路中，根据资产估值计算用户的实际买入份额与卖出金额；在用户与交易两个维度进行批处理；

• 估值系统：计算资产的净值、利息收入，资产维度批处理；

• 投资交易系统：交易核心账务处理；高并发低延迟，满足 ACID；

• 投资分析系统：统计分析，包括大量大事务，复杂查询。

容灾要求

1. 机房切换演练：

在线类交易业务对业务连续性有较高的要求，以银行核心做对比，发生灾难时，银行账务核心需优先保 RPO，确保数据一致，在此前提下，能接受一定时间的系统不可用；而证券核心交易系统需要优先确保业务可用，其交易期间的系统不可用损失往往以秒为单位计算。因此证券行业需要定期做各类高可用切换演练。

2. 快速数据恢复：

T+1 类交易业务则对数据一致性有较高要求，一旦跑批出现错误，需要将数据恢复到某个时间点进行重跑，同时需要在跑批时间窗口完成批量任务，因此一方面需要跑批稳定，尽量不出错，一旦出错还需要数据能可靠且快速地完成时间点恢复。

针对业务模型的数据库方案实践

1. 对客查询系统：

在自有销售渠道预期增长的背景下，为了支撑未来高并发场景，部分头部企业开始专库专用，将对客查询模块从数仓平台中抽出，单独运行在分布式关系型数据库。

资管系统的对客查询模块，虽然 SQL 基本都带有“用户 ID ”这类信息作为等值条件，但其 SQL 往往不是简单的点查，而是带有去重排序等各类计算以及多表 join 的中等复杂 SQL。在此情况下，OceanBase 的分区表+TableGroup+复制表可尽量将 join 中的相同数据放在同一个节点，减少分布式系统下带来的跨机 RPC 请求，同时 OceanBase 的一体化设计能尽量避免计算过程中的数据 merge。综合多方面特性，OceanBase 在此类场景下能够提供高并发低延迟的查询能力。

对于写入负载，若数据来源于数仓平台，建议在数仓平台完成数据进行清洗后再导入；若选择直接在对客查询系统进行数据清洗，则建议控制事务尺寸，尽量避免一条 SQL 处理一整段时间的数据（如一个月），尽管 OceanBase 3.X 已经支持大事务，但为了保持系统持续长远运行的健壮性，建议固定事务尺寸，否则随业务增长，按时间维度的事务大小也将持续增长，在达到临界点后，还是需要回头调整业务逻辑。

2. TA 登记过户系统：

引入分布式数据库并且借助其可扩展性，可在保持业务架构不变的情况下，较好应对未来基金用户数、交易数大幅提升的需求。

该系统涉及用户记录与交易记录两个维度，同时部分清算必须以串行方式完成，因此架构上较好方案是单元化，即将业务拆分为若干个能够独立完成关键业务流程的数据单元，单元之间避免 DB 间的交互，将不同业务单元以租户或用户维度进行部署，并将其主节点置于不同主机，从而提升整体批处理效率并且保证硬件资源利用率。

在每个单元内，需要确保其数据相对均匀并且执行效率相当，因为系统整体的处理时间本质上就是最后一个单元完成清算的时间，这需要数据库具备良好的租户资源隔离能力。

相对于分片单元而言的是汇聚单元，汇聚单元内有所有的数据，负责承载全局分析类负载，这需要数据库具备良好的 AP/TP 负载隔离能力。

3. 估值系统：

该系统只涉及资金维度，其批处理逻辑较为简单，通过热点大表分区 +TableGroup，可将负载均匀分布到各个节点，达到较高的性能效果，当前 Oracle 生产环境运行在一套高配 Oracle 数据库中，跑批时间在小时级别，高峰期 CPU 达到满负荷，OceanBase 采用了比生产多一倍的数据进行跑批压测，在国产芯片的 2-2-2 集群环境中，可在 6 分钟内完成。

4. 投资分析系统：

线上常见的问题是偶发的执行计划走错，导致复杂查询 SQL 时间变长，该问题在 Oracle 数据库也是常见的影响性能的因素之一，OceanBase 支持通过 HINT 来描述具体如何固定计划，并具备绑定执行计划的能力，更进一步，当前 OCP 3.2.1 版本已支持白屏绑定历史执行计划（点击文末阅读原文查看详情）。

对于上述场景，若该 SQL 在执行计划变化之前一直运行正常，则可找到以前正常的执行计划，若定位后发现根本原因确实是执行计划改变，则可直接一键绑定历史执行计划。该能力大大降低了线上环境复杂 SQL 计划调优的操作风险与复杂度。

除此之外，复杂分析 SQL 往往大量运行在 PL 环境中，业务逻辑均在存储过程、函数、匿名块中，数据库本身对 PL 语言的支持程度也决定了业务迁移改造的实施难度，OceanBase 能兼容 PL 的基本常见语法，在该项目中，原运行在 Oracle 的 PL 代码几乎没有做业务逻辑修改。

数据库部署架构

1. 集群内高可用能力：

OceanBase 集群在同机房内部署，其提供的高可用能力与效果可认为是一组节点扩展能力上限更高、没有存储单点风险的 Oracle RAC：无需人工或外部工具参与的自动故障转移、多节点多活提供服务、添加节点即可完成资源自动扩展。OceanBase 基于 Paxos 多数派共识协议的高可用底座经历了阿里巴巴/蚂蚁集团“双十一”级别的负载考验，而 TableGroup 、集群内负载均衡等日常运维手段也都依赖于高可用切主，因此可以认为集群内高可用已经是成熟稳定的能力，可有效抵御基础设施计划外故障导致的业务中断。

2. 集群间高可用能力：

基于多数派共识的高可用协议对于双机房场景无法有效抵御风险，若将多数派节点放置在主机房，则主机房故障就无法提供服务；若将多数派放置在备机房，对于主机房而言，其具备了故障转移的能力，但若备机房故障，主机房可用性将受到影响，系统整体可用性没有实质提升，在没有同城三机房的条件下，若要借助集群内高可用能力实现“双活”级别可用性，则至少需要引入第三机房存放日志副本做 Paxos 投票。

在此背景下，OceanBase 提供了集群级别的主备能力，针对双机房场景提供机房级别高可用能力。对于机房切换演练，带生产数据进行切换演练时，可通过 switchover 将主备集群的角色互换，演练结束后业务负载回到主机房，数据库侧则再次执行 switchover。不带生产数据做演练时，则将第二备集群与主集群解耦，让其独立为一个单独的集群，测试数据运行完后，重建该备集群。

*主备库概述请查看：https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.2.2/primary-secondary-database-overview-1

相比耳熟能详的单机数据库，OceanBase 在开发使用、运维管理方面还不足够被广大技术人员熟知，同时产品架构与功能细节也在持续迭代。众多核心业务的成功上线离不开客户与合作伙伴的信任，OceanBase 也将以解决真实业务场景难题作为方向，不断提升产品能力，用技术让数据的管理和使用更简单。