VaR值计算性能千倍提升——某头部外资银行实例分享

Posted 2023-03-22

随着政策的推进、技术的迭代以及市场需求的逐步扩大，采用安全可控的金融科技产品渐渐成为热潮，国内众多金融政企机构纷纷开始改造升级原有IT系统，对老旧系统的国产化替换需求日益强烈。

但“替换”不应该是简单的更换产品，而是根据业务发展需要，选择一套更优秀的解决方案，为企业实现“降本增效”。

这里，我们为大家介绍一个外资银行金融市场数据集市国产替换的成功案例。

在这个案例中，该外资银行使用 DolphinDB 从底层完美替换了 Oracle，不仅成功解决了兼容性、海量数据迁移问题，更实现了对原有金融市场数据集市所面向业务的全面升级：

• IRS VaR 业务的每日平均处理时长由40分钟降至3.5秒，提升近千倍；
• CMDS 实时数据接口延时由300-500毫秒降至10毫秒以下；
• 整体报表查询速度提升近5倍。

​

打破性能瓶颈，释放业务潜力

IRS VaR 计算：从40分钟至3.5秒

VaR 值是银行风险控制中最基础的风险度量指标之一，可以用来度量在一定时间区间内，某个投资组合或资产价值可能出现的最大亏损，帮助投资者了解自己的风险承受能力，制定风险控制策略，降低投资风险。

提升 VaR 值计算的性能不仅能提高风险控制能力，还可以实现对资本分配和决策的优化。

在本案例中，该银行原有系统使用老牌传统数据库 Oracle 来存储和处理 IRS VaR 业务数据。具体来说，通过上游交易系统日终文件交换获取当日 IRS 交易明细、中债估值、曲线等相关业务数据，存储在 Oracle 中，生成金融市场数据集市内部模型数据，并根据下游 Risk Matrix 所需要的 VaR 报表计算逻辑生成供数文件。

然而，随着数据量的不断增加和业务优化，处理IRS VaR 业务的每日平均时长最高达到了40分钟。

为了进一步缩短耗时，提升效率，经过多轮对比测试，他们最终选择了DB-Engines 时序数据库榜单上国内排名第一的 DolphinDB，实现对系统和业务的全面升级。

通过 DolphinDB 语法，可以在低资源成本下实现业务目标。根据当前生产运行情况统计，该计算任务的每日平均处理时长由原来的40分钟降至3.5秒，提升近千倍。

​

逐笔数据实时处理：从上百毫秒至10毫秒以下

除了对 IRS VaR 业务的改造升级，DolphinDB 还帮助用户大幅降低了逐笔数据处理的延时。

该银行业务需要根据外汇交易中心数据接口技术规范，通过 API 形式获取 CMDS 利率互换实时逐笔行情及成交数据并落库。根据当前生产运行情况监测，该接口逐笔数据处理延迟约300-500毫秒。

经过 DolphinDB 改造升级后，在 TPS 1000笔的实时流数据吞吐量压力下，整体延时少于10 毫秒，CPU使用率低于20%，内存使用率低于60%，实时流处理队列没有堆积。

​

DolphinDB：强大的计算与流计算性能

在计算 VaR 值的过程中，需要用到大量的历史数据，这些数据往往可能分散在不同的系统或数据库中；同时，VaR 计算需要对多维度、大规模的数据进行数值计算，因此对多数据源的采集处理能力和复杂计算能力是提升 VaR 值计算性能的关键。

此外，该银行需要获取 CMDS 利率互换实时逐笔行情及成交数据并落库，这就要求具备高吞吐、低延时的流数据服务支持。

作为一个基于数据库管理系统，支持数据分析、流数据处理的低延时平台，DolphinDB 不仅在存储、查询拥有领先性能，还有强大的计算和流数据实时分析功能，被广泛应用于行情数据存储、量化策略研发和生产环境交易场景中，满足了用户从存储到反控决策的全流程需求。

• 存储与查询：支持 OLAP/TSDB 存储引擎，海量数据高性能读写；
• 海量数据计算：1400+ 内置函数，满足各类指标的复杂计算；强大的向量化和函数化编程，帮助用户享受极速性能体验；
• 实时流数据处理：封装流数据处理引擎，用更少的步骤实现增量计算，降低计算时延。

而在以银行为代表的传统金融机构领域，除了数据存储、查询与计算，数据安全与系统运维成本也至关重要，对此 DolphinDB 同样拥有亮眼表现——

原生的分布式架构具备较强的可扩展性，满足海量数据高并发低延时处理需求；具备数据备份和恢复功能，可以有效分散单点故障带来的数据安全风险，保障了金融业务的持续进行；此外，完全国产自研，掌握所有核心技术。

在完成了对业务的提速升级之后，DolphinDB 的上述特点，让该外资银行看到了更多的可能性，尝试从底层用 DolphinDB 替换 Oracle，以解决老旧系统对海量数据支撑乏力、业务连续性难保障和安全可控性较低的问题。

从改造升级到全面替换

Oracle 拥有独特的生态系统，其中包含数据类型、语法结构、函数功能、客户端支持等多个方面，并可支持程序化脚本以及批量任务的运行。此外，Oracle 现存数亿级别关键市场数据，包含 YDM/TDM 等多个数据集市的数据资源，拥有完善的数据模型，对数据的平迁与迭代均需保证准确性、完整性。在银行现有的报表业务下，还要保证上游系统的与下游系统的正常使用。

这些难题，在该外资银行携手第三方服务商 Tracade 共同推进了基于 DolphinDB 的数据基础服务系统后，都迎刃而解。

对 Oracle 生态系统的兼容

无论是常用数据类型、语法、函数，或是客户端等，DolphinDB 对 Oracle 的生态系统都具备非常好的支持。其中，对常用数据类型和语法的覆盖率均达到98%以上，常用函数兼容性高达96%以上。相较于Oracle，DolphinDB 的语法不存在明显差异，常用语法不需要进行改造即可使用。

此外，DolphinDB 支持多种语言的 API 和多种应用插件，对各种报表软件与其他类型数据库都具有良好支持。

数据迁移与迭代

Oracle 现存数亿级别关键市场数据，针对这些现有数据的平迁与新业务数据迭代，该银行在第三方服务商 Tracade 团队的帮助下，完成了全量数据迁移。通过业务测试数据的对比，数据结构兼容性为100%，数据一致性为100%。

在这个过程中，依托 DolphinDB 灵活的数据分区控制、高覆盖的数据类型和语法兼容性，数据查询速度得到了提升，性能优化了5倍左右。

多数据源支持

​

标准的数据迁移流程

报表平台兼容

DolphinDB 完美兼容了 SmartBI、Birt 报表平台，实现了2000多张报表的平迁，并通过 API 支持了银行业务系统的调用。

以 SmartBI 报表平台为例，该平台原本通过 Oralce 数据库生成银行业务所需报表，而替换成 DolphinDB 后，仅通过切换数据源，即可保障相关系统业务报表的正常使用，实现报表的批量平迁。

测试指标	平迁前	平迁后	备注
运行时间	8.2s	1.6s	相同条件下，报表运行20次的平均值
数据完整性		100%	相同条件下，报表运行20次完整性校验

本案例中，该银行面临日益增长的数据量和不断升级的数据安全要求，并且需要支撑低延时的报表分析业务，因而传统老牌数据库 Oracle 已逐渐难以满足需求。在 Tracade 的帮助下，该银行用国产自研产品 DolphinDB 替换了 Oracle。

作为一个基于数据库管理系统，支持数据分析、流数据处理的低延时平台，DolphinDB 不仅帮助用户快速实现了全量数据的平迁和迭代，还显著提升了原有业务的效率。可以说，该银行从 Oracle 到 DolphinDB 的实践，不仅是一次成功的国产替换，更是从存储、查询到实时流数据处理性能的全方位升级。

个推技术实践 | 掌握这两个调优技巧，让TiDB性能提速千倍！

北京冬奥会上，运动健儿们激战正酣，他们正在用速度、力量、韧性诠释更快、更高、更强的奥林匹克精神，向他们致敬！其实，在0和1的计算机世界里，开发者和程序员们为了提升系统运行速度、最大化释放服务器性能，也要面对各种各样的挑战，不断提出方案，展开实践，以突破瓶颈、解决难题。

个推“大数据降本提效”专题，正是通过总结分享自身在大数据实战过程中的踩坑经验、调优技巧等，为从业人员开展大数据实践提供参考。本文是“大数据降本提效”专题的第三篇，将为大家分享个推通过调优，实现TiDB千倍性能提升的实战经验。

个推与TiDB的结缘

作为一家数据智能企业，个推为数十万APP提供了消息推送等开发者服务，同时为众多行业客户提供专业的数字化解决方案。在快速发展业务的同时，公司的数据体量也在高速增长。随着时间的推移，数据量越来越大，MySQL已经无法满足公司对数据进行快速查询和分析的需求，一种支持水平弹性扩展，能够有效应对高并发、海量数据场景，同时高度兼容MySQL的新型数据库成为个推的选型需求。

经过深入调研，我们发现“网红”数据库TiDB不仅具备以上特性，还是金融级高可用、具有数据强一致性、支持实时HTAP的云原生分布式数据库。因此，我们决定将MySQL切换到TiDB，期望实现在数据存储量不断增长的情况下，仍然确保数据的快速查询，满足内外部客户高效分析数据的需求，比如为开发者用户提供及时的推送下发量、到达率等相关数据报表，帮助他们科学决策。

完成选型后，我们就开始进行数据迁移。本次迁移MySQL数据库实例的数据量有数T左右，我们采用TiDB自带的生态工具Data Migration (DM)进行全量和增量数据的迁移。

• 全量数据迁移：从数据源迁移对应表的表结构到TiDB，然后读取存量数据，写入到TiDB集群。
• 增量数据复制：全量数据迁移完成后，从数据源读取对应的表变更，然后写入到TiDB集群。

个推将MySQL数据迁移到TiDB

当数据同步稳定之后，将应用逐步迁移到TiDB Cluster。把最后一个应用迁移完成之后，停止DM Cluster。这样就完成了从MySQL到TiDB的数据迁移。

注：DM的具体配置使用详见官方文档。

陷入TiDB使用的“反模式”

然而，当应用全部迁移到TiDB之后，却出现了数据库反应慢、卡顿，应用不可用等一系列的问题。

如下图：

登陆数据库时遇到卡顿

通过排查，我们发现有大量的慢SQL都是使用load导入数据的脚本。

慢SQL的导入耗时几十分钟

和业务方沟通后，我们发现有些导入语句就包含几万条记录，导入时间需要耗时几十分钟。

对比之前使用MySQL，一次导入只需几分钟甚至几十秒钟就完成了，而迁到TiDB却需要双倍甚至几倍的时间才完成，几台机器组成的TiDB集群反而还不如一台MySQL机器。

这肯定不是打开TiDB的正确姿势，我们需要找到原因，对其进行优化。

单个服务器负载过高

通过查看监控，发现服务器负载压力都是在其中一台机器上（如上图，红色线框里标注的这台服务器承担主要压力），这说明我们目前并没有充分利用到所有的资源，未能发挥出TiDB作为分布式数据库的性能优势。

打开TiDB的正确使用姿势

首先优化配置参数

具体如何优化呢？我们首先从配置参数方面着手。众所周知，很多配置参数都是使用系统的默认参数，这并不能帮助我们合理地利用服务器的性能。通过深入查阅官方文档及多轮实测，我们对TiDB配置参数进行了适当调整，从而充分利用服务器资源，使服务器性能达到理想状态。

下表是个推对TiDB配置参数进行调整的说明，供参考：

重点解决热点问题

调整配置参数只是基础的一步，我们还是要从根本上解决服务器负载压力都集中在一台机器上的问题。可是如何解决呢？这就需要我们先深入了解TiDB的架构，以及TiDB中表保存数据的内在原理。

在TiDB的整个架构中，分布式数据存储引擎TiKV Server负责存储数据。在存储数据时，TiKV采用范围切分（range）的方式对数据进行切分，切分的最小单位是region。每个region有大小限制（默认上限为96M），会有多个副本，每一组副本，成为一个raft group。每个raft group中由leader负责执行这个块数据的读&写。leader会自动地被PD组件（Placement Driver，简称“PD”，是整个集群的管理模块）均匀调度在不同的物理节点上，用以均分读写压力，实现负载均衡。

TiDB架构图（图片来源于TiDB官网）

TiDB会为每个表分配一个TableID，为每一个索引分配一个IndexID，为每一行分配一个RowID（默认情况下，如果表使用整数型的Primary Key，那么会用Primary Key的值当做RowID）。同一个表的数据会存储在以表ID开头为前缀的一个range中，数据会按照RowID的值顺序排列。在插入（insert）表的过程中，如果RowID的值是递增的，则插入的行只能在末端追加。

当Region达到一定的大小之后会进行分裂，分裂之后还是只能在当前range范围的末端追加，并永远仅能在同一个Region上进行insert操作，由此形成热点（即单点的过高负载），陷入TiDB使用的“反模式”。

常见的increment类型自增主键就是按顺序递增的，默认情况下，在主键为整数型时，会将主键值作为RowID ，此时RowID也为顺序递增，在大量insert时就会形成表的写入热点。同时，TiDB中RowID默认也按照自增的方式顺序递增，主键不为整数类型时，同样会遇到写入热点的问题。

在使用MySQL数据库时，为了方便，我们都习惯使用自增ID来作为表的主键。因此，将数据从MySQL迁移到TiDB之后，原来的表结构都保持不变，仍然是以自增ID作为表的主键。这样就造成了批量导入数据时出现TiDB写入热点的问题，导致Region分裂不断进行，消耗大量资源。

对此，在进行TiDB优化时，我们从表结构入手，对以自增ID作为主键的表进行重建，删除自增ID，使用TiDB隐式的_tidb_rowid列作为主键，将

create table t (a int primary key auto_increment, b int)；

改为：

create table t (a int, b int)SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=2

通过设置SHARD_ROW_ID_BITS，将RowID打散写入多个不同的Region，从而缓解写入热点问题。

此处需要注意，SHARD_ROW_ID_BITS值决定分片数量：

• SHARD_ROW_ID_BITS = 0 表示 1 个分片
• SHARD_ROW_ID_BITS = 4 表示 16 个分片
• SHARD_ROW_ID_BITS = 6 表示 64 个分片

SHARD_ROW_ID_BITS值设置的过大会造成RPC请求数放大，增加CPU和网络开销，这里我们将SHARD_ROW_ID_BITS设置为4。

PRE_SPLIT_REGIONS指的是建表成功后的预均匀切分，我们通过设置PRE_SPLIT_REGIONS=2，实现建表成功后预均匀切分2^(PRE_SPLIT_REGIONS)个Region。

经验总结

· 以后新建表禁止使用自增主键，

考虑使用业务主键

· 加上参数SHARD_ROW_ID_BITS = 4  PRE_SPLIT_REGIONS=2

此外，由于TiDB的优化器和MySQL有一定差异，出现了相同的SQL语句在MySQL里可以正常执行，而在TiDB里执行慢的情况。我们针对特定的慢SQL进行了深入分析，并针对性地进行了索引优化，取得了不错的成效。

优化成果

通过慢SQL查询平台可以看到，经过优化，大部分的导入在秒级时间内就完成了，相比原来的数十分钟，实现了数千倍的性能提升。

慢SQL优化结果

同时，性能监控图表也显示，在负载高的时刻，是几台机器同时高，而不再是单独一台升高，这说明我们的优化手段是有效的，TiDB作为分布式数据库的优势得以真正体现。

优化后，实现服务器负载均衡

总结

作为一种新型分布式关系型数据库，TiDB能够为OLTP（Online Transactional Processing）和OLAP（Online Analytical Processing）场景提供一站式的解决方案。个推不仅使用TiDB进行海量数据高效查询，同时也展开了基于TiDB进行实时数据分析、洞察的探索。

后续更多“大数据降本提效”的干货分享，请大家持续锁定个推技术实践公众号（微信公众号ID：getuitech）~