写点什么

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

  • 2022 年 3 月 29 日
  • 本文字数:2873 字

    阅读完需:约 9 分钟

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

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


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


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


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



业务模型


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


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

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

  3. 估值系统:计算资产的净值、利息收入,资产维度批处理;

  4. 投资交易系统:交易核心账务处理;高并发低延迟,满足 ACID;

  5. 投资分析系统:统计分析,包括大量大事务,复杂查询。

容灾要求

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。不带生产数据做演练时,则将第二备集群与主集群解耦,让其独立为一个单独的集群,测试数据运行完后,重建该备集群。



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

用户头像

企业级原生分布式数据库 2020.05.06 加入

github:https://github.com/oceanbase/oceanbase 欢迎大家

评论

发布
暂无评论
OceanBase 在证券行业基金资管场景落地实践与解决方案_证券_OceanBase 数据库_InfoQ写作平台