全文发布｜SmartX 金融行业跑批类业务场景探索与实践合集-CSDN博客

本文链接：https://blog.csdn.net/weixin_43696211/article/details/141358160

经过多年在⾦融⾏业的积累和发展，SmartX 已经赢得了 300 多家⾦融⽤户的信任。覆盖了银⾏、保险、证券、基⾦、期货和信托等主要⾦融细分领域。在这个过程中，我们从最初的单⼀超融合⼚商（⼩规模起步/快速交付/按需灵活扩容/降低总拥有成本）发展成为提供全栈企业云产品与解决方案的云基础架构厂商。

随着客户对 SmartX 的信任不断地增加，逐步将重要的应⽤场景部署在 SmartX 资源池之上。SmartX 从⽀撑开发测试逐渐过渡到⼀般⽣产系统和核⼼⽣产环境，并承载客户⽣产级数据库系统。在⽣产系统中，有⼀类特殊的场景，不仅需要基础架构具备极⾼的 I/O 吞吐能⼒，还需要在长时间⾼压⼒下始终保持稳定的性能输出，这就是应⽤跑批场景。SmartX 针对跑批类场景展开探索，结合多个真实案例，形成了《金融行业跑批类业务场景探索与实践合集》。

某银行年终决算跑批场景中，超融合对比 IBM ⼩机 / HDS & NetApp 全闪存储的表现如何？
在某⾦融服务公司 Oracle 数仓跑批性能验证过程中，超融合对比裸⾦属 / EMC Power Max 全闪存储比的表现如何？
多家基金公司结合核心应用系统，针对传统架构与超融合架构的跑批验证表现如何？
在某银行客户风控系统跑批性能验证中，基于海光平台构建分布式存储对比 Huawei 集中式全闪存储的表现如何？
基于鲲鹏信创服务器构建分布式存储，结合 NVMe over RDMA 高性能协议，对比传统集中式架构的性能表现如何？

如果您对这些问题感兴趣，欢迎点击下载《金融行业跑批类业务场景探索与实践合集》。

同时，您可以通过本篇文章了解合集全文内容。

01-超融合加速某银⾏年终决算跑批实践

超融合架构 vs IBM ⼩机 / HDS & NetApp 全闪存储

背景信息

某银⾏客户⾃ 2019 年开始引⼊ SmartX 超融合基础架构平台（后续简称为 HCI ），⽤于⽀撑开发测试/同城灾备/桌⾯虚拟化/⽣产系统的新⼀代计算存储资源池，到⽬前为⽌，已交付的 6 个集群运⾏稳定。

经过多次交流和讨论，客户计划将年终决算跑批相关的 5 个系统迁移⾄ SmartX HCI，分别包括总账系统、CBS 信贷系统（Core Banking System）、CMS 核⼼系统（Credit Management System）、营销系统和新会计计量准则，通过实际业务场景和真实数据量进⾏模拟跑批，验证 SmartX HCI 性能表现的同时，评估并探索 HCI 对于银⾏多元化业务场景适⽤性。

银⾏核⼼系统的年终跑批在银⾏业中具有⼤规模数据集处理、复杂的业务逻辑、数据准确性、任务执⾏时效性、监控合规和业务连续性等⾏业特点。银⾏需要结合这些特点进⾏有效规划、管理和执⾏，以确保年终跑批的顺利进⾏。

客户⽣产环境现状

该银⾏营销和新会计财务系统采⽤ VMware 虚拟化⽀撑应⽤和数据库，总账系统数据库采⽤裸⾦属服务器，三套系统后端存储通过 NetApp ⾼端集中存储提供数据持久化；CBS 和 CMS 应⽤系统同样采⽤ VMware 虚拟化底层架构，数据库运⾏在 IBM ⼩机平台，并通过 HDS ⾼端全闪集中存储提供数据持久化。

SmartX HCI 验证环境

通过对验证系统的资源配置的分析，确定采⽤如下测试硬件，以⽀撑本次跑批验证⽬标。

由三台服务器组建超融合集群。
每节点配置 Intel Xeon Gold 6132 * 2 / 256GB 内存 / NVMe SSD 1.6TB * 2 / HDD 2TB * 4 / 25GbE。
超融合集群存储⽹络启⽤ RDMA。

迁移 & 新建虚拟机共 18 台，包括 4 套 Oracle 数据库，1 套 MySQL 数据库，存储使⽤率达 96.6%，测试集群资源使⽤率处在⾼负载状态，数据采⽤⼆副本冗余保护。由于测试所选⽤的服务器硬件资源有限，CBS 与 CMS 数据库系统的 CPU 与内存分配相较⽣产环境有不同程度的降配。通过下⾯的业务系统资源分配表的统计信息，可以看到 CMS 数据库系统仅分配 8vCPU 和 8GB 内存，是所有测试系统中与⽣产环境差距最⼤的系统。

验证结论

SmartX 超融合架构使⽤ 3 台服务器⽀撑 5 套业务系统的跑批性能，总体与⽣产环境性能相当。其中，CBS 核⼼系统相⽐⽣产环境跑批时间缩短 45%，效率提升 83%。CMS 系统跑批性能略低于⽣产系统，主要影响因素是与资源分配相关（资源分配相差 8 倍以上）。所有测试数据得到客户的认可。
本次测试充分验证了超融合的架构简单、弹性资源、⾼性能、易维护性和经济成本等优势，以及 SmartX 超融合对数据平台多元场景应⽤的⾼性能⽀撑能⼒，⽀持客户实现集群快速交付、业务系统快速部署，顺利完成跑批结算验证⽬标。

02-某保险客户经营管理报表跑批性能验证

超融合架构 vs IBM ⼩机 / HDS 全闪存储

背景信息

客户在⽣产环境使⽤ Oracle 数据库为前端报表系统提供数据加⼯和数据处理。随着业务量和数据量的增长，Oracle 数据库跑批的性能越来越差，⽬前跑批⼯作是从凌晨开始到早上 6 点结束，考虑到后期数据量还会继续增⼤，可能会继续增加跑批时间，影响⽩天业务正常开展。因此，客户希望能够优化基础架构，缩短数仓跑批运⾏时间。

同时，⽣产环境的数据库部署在 IBM ⼩型机上，虽然运⾏较为稳定，但由于⼩型机使⽤年限较长，考虑到设备运⾏风险、运维复杂度以及后期服务等问题，客户希望进⾏⼩机下移 x86 的可能性验证，以应对未来的业务增长。

验证⽬标

本次测试为了验证 Oracle 数据库在超融合架构下的跑批性能表现。在数据量完全相同的情况下，对⽐⽣产环境现有⽅案与基于 SmartX 超融合架构下的 Oracle 数据库跑批时间，客户⽬标是希望将跑批时间缩短⾄ 4 ⼩时上下。

客户⽣产环境现状

当前跑批数据流是将 DB2 数据库的数据，通过 Informatica （ ETL 抽数⼯具）抽取到 Oracle 数据库当中，接下来由 Oracle 数据库完成数据加⼯和数据处理的⼯作。

ETL VM 配置

・16vCPU / 64GB 内存

IBM ⼩机配置

・Power 4.2GHz 12 Cores

・128GB 内存

・2.5TB 数据量

SmartX HCI 验证环境

本次测试将对⽐ IBM ⼩机（拥有 4.2GHz 主频），构建测试环境时，优先寻找⾼主频 x86 CPU 服务器来承载数据库，测试集群由三台服务器组成（ SmartX 超融合⽀持集群内服务器配置异构）。

节点⼀配置 Intel Xeon Gold 6226R 2.9GHz * 2 / 256GB 内存 / NVMe SSD 3.2TB * 2 / HDD 2TB * 4 / 25GbE。节点⼆&节点三配置 Intel Xeon Silver 4214R 2.4GHz * 2 / 256GB 内存 / NVMe SSD 3.2TB * 2 / HDD 2TB * 4 / 25GbE。
超融合集群存储⽹络启⽤ RDMA。

ETL VM 配置

・16vCPU / 64GB 内存

Oracle VM 配置

・48vCPU

・128GB 内存（第三轮测试增加到 192GB）

・2.5TB 数据量

・采⽤ Linux 作为数据库⽀撑系统，替代 AIX OS。

测试数据

验证结论

经过多轮测试验证，SmartX 超融合架构相⽐原⽣产架构的⼩机＋集中式存储，在进⾏ Oracle 数据仓跑批时有明显的性能提升，跑批时间有效缩短了 36%，并得到客户认可。
验证了 Oracle 数据库从⼩机下移 x86 服务器的可⾏性，为客户后续使⽤ SmartX 超融合替换⼩机＋集中式存储，提供了可量化参考依据。
提⾼了资源利⽤率，Oracle 数据仓库跑批业务通常是在夜间运⾏，超融合架构在⽩天可以⽀撑其他应⽤和数据库等业务（混部场景）。基础架构硬件资源可充分复⽤提⾼资源利⽤效率。

后续故事

经过充分验证，客户于 2023 年上线 5 节点 SmartX ⾼性能集群（NVMe + 25GbE + RDMA）完成公司经营数仓数据库下移，同时该集群还⽤于⽀撑其他多个 Oracle ⽣产系统。

03-某⾦融服务公司 Oracle 数仓跑批性能验证

超融合架构 vs 裸⾦属 / EMC Power Max 全闪存储

背景信息

某⾦融客户 BI ⽣产系统计算端使⽤四路物理服务器，存储端采⽤ EMC Power Max 2000 全闪架构，系统每天⼀次⽇跑批和每⽉⼀次⽉跑批，⽬前跑批时间为 8.5 ⼩时完成。数据中⼼部分传统集中存储硬件⽼化，资源不⾜等现象也迫使客户思考新⼀代架构的规划与建设。

当前客户拥抱分布式架构，并在测试环境使⽤ VMware vSAN 集群承载 BI 业务，由于数据量较⼤，以及受限于 vSAN 缓存技术实现原理，造成 BI 跑批出现缓存击穿，导致整个 vSAN 集群存储 I/O 卡住，处于不可⽤状态，在不影响集群正常使⽤情况下，后续只能抽量跑批，约占⽇跑批的 1/3 数据量。vSAN ⽬前⽆法满⾜客户新 BI 系统的压⼒测试验证⼯作，直接影响系统迭代、调试和相关测试任务的进度推进。

验证⽬标

通过将 SmartX 超融合系统安装到与 VMware vSAN 相同的混闪硬件环境来验证 SmartX 集群 BI 跑批的性能表现（验证 SmartX 混闪集群是否可以符合⽣产环境 9 ⼩时内完成跑批的要求）。

部署 SmartX 全闪集群，进⼀步验证 BI 跑批相⽐⽣产环境是否有性能提升，将 BI 数据库跑批缩短到更⼩的时间窗口，以提⾼开发效率，缩短整体新 BI 核⼼项⽬开发验证周期。

客户⽣产环境现状

当前 Oracle 数仓总数据量 28TB。
计算端采⽤ Oracle RAC 物理机部署模式，分别部署在 2 台四路 x86 服务器。
存储采⽤ EMC Power MAX 2000 集中式存储阵列，共配置 10 块 NVMe SSD。

SmartX HCI 验证环境

测试数据

由于 vSAN 集群⽆法跑完⽇跑批，本次测试直接与⽣产环境进⾏对⽐，⽬标是将⽇跑批时间跑进 9 ⼩时内。每轮跑批会进⾏多次测试，观测其跑批时效的稳定性。

验证结论

SmartX 混闪配置在连续四轮跑批下（每次间隔 4 ⼩时），未发现缓存击穿，多轮跑批的热数据被有效缓存，性能略有提升，满⾜⽣产环境对⽇跑批的时效要求，具备承载⽣产环境 BI 数据库的跑批任务。

SmartX 全闪配置（SATA SSD），⽐⽣产环境缩短了近 4 ⼩时跑批时间。验证 SmartX 全闪集群的⾼性能存储表现，可以缩⼩应⽤开发部门改造新版本 BI 数据库跑批时间窗口的难度，缩短整体新核⼼项⽬开发验证周期，并为后续业务增长预留⾜够的性能空间。

后续故事

客户在⾸次构建超融合集群时，就有关注并验证 SmartX 产品，但并未能引⼊。通过本次跑批验证和最终效果，SmartX 超融合产品得到客户的充分认可，后续客户不仅引⼊ SmartX 超融合产品，还将使⽤ SmartX 双活集群⽅案，实现数据中⼼关键业务的可⽤性加固。

在完成 SmartX 双活集群部署交付后（当前 SmartX 超融合集成 VMware 虚拟化），客户计划全⾯验证 SmartX 原⽣虚拟化软件 ELF，评估使⽤ ELF 替代 ESXi 产品的可⾏性（新的 VMware 订阅许可模式使采购成本上升，在不改变产品服务⽔平的前提下，有效降本也将是客户重点关注⽅向），为后续基础架构的全⾯转型提供技术参考依据。

04-某基⾦客户基于超融合⾼性能集群验证 CC 跑批

软件定义基础架构充分发挥新⼀代硬件性能

背景信息

在 2015 ⾄ 2016 年期间，客户通过 4 台 HP DL580 服务器+ EMC VNX 5600 混闪存储组成的 SAN 架构⽀撑着两套 Oracle RAC 集群，每套 RAC 上部署多套数据库为业务提供服务。随着硬件设备⽼化，单台设备故障会对业务造成较⼤范围的影响。同时，存储资源使⽤率不断攀升，长期处于⾼“⽔位”运⾏，存储扩容昂贵，维护繁琐，这些因素叠加，为运维带来了较⼤的压⼒。

在 2018 年初，客户先后在周边⽣产和信息化等业务场景中尝试使⽤了 SmartX 超融合架构。截⽌当前，两个业务场景中的集群已经稳定运⾏了超过 4 年时间。在此期间，客户也将⼀套以 RAC 架构部署的业务系统跑在超融合上进⾏长时间运⾏验证，超融合架构的可靠性、稳定性、资源扩展弹性以及监控运维管理的便利性等诸多特性得到了客户的认可。

在 2020 年底，基于现有 2 套超融合集群的稳定表现，客户决定新建⼀套超融合集群，将传统 SAN 架构上的 2 套 RAC 系统迁移上来，同时对 RAC 进⾏拆分，由原来的 2 套 RAC 拆分成多套，从⽽控制硬件设备故障对业务系统造成的影响范围，缓解设备⽼化和存储资源长期⾼“⽔位”运⾏带来的风险和压⼒，简化运维。

在 SmartX 超融合架构承载运⾏多套 RAC 数据库期间，客户关注到基⾦数据中⼼业务系统（简称 CC ）性能较迁移前存在⼀定的提升，与此同时客户也在规划 O32 和 TA 等核⼼业务系统的未来基础架构平台。看到基⾦数据中⼼业务性能提升后，客户想了解，超融合架构是否可以进⼀步提升该场景下的性能，同时也为后续 O32 和 TA 的基础架构选型提供数据参考，为此围绕“基⾦数据中⼼系统”展开 POC 性能验证测试及优化⼯作。

客户⽣产环境现状

当前 CC 系统部署在基于 SATA SSD 磁盘介质的 SmartX 超融合⽣产集群（四节点）之上，硬件资源配置如下。

Intel Xeon Gold 6240 2.60GHz 28 Cores * 2 / 512GB / 1.92TB SATA SSD * 4 / 25GbE

Oracle数据库软件版本为 11G R2，采⽤ RAC 部署在 2 台虚拟机，为保持测试标准统⼀，将采⽤相同的软件版本和配置部署在验证环境集群进⾏测试。

SmartX HCI 验证环境

验证环境由 3 台 x86 服务器构建超融合集群，硬件资源配置如下。

每节点配置 Intel Xeon Gold 5220R 2.20GHz * 2 / 256GB 内存 / NVMe SSD 3.2TB * 2 / 25GbE。
CC 系统 Oracle 虚拟机资源配置与⽣产环境保持⼀致，每虚拟机资源配置 8vCPU / 64GB 内存 / 3TB vDisk。
本次规划多种跑批任务模型组合，如 CISP 估值数据落地、ETF 分 TA ⾏情数据处理、ETF 分 TA 数据确认处理、分 TA ⾏情数据处理、分 TA 数据确认处理、⾃建 TA ⾏情数据处理、⾃建 TA 数据确认处理。

测试数据

验证结论

得益于 SmartX 超融合软件对 NVMe 闪存的优化，结合 25GbE ⾼速⽹络，以及 I/O 本地化等特性，存储读写性能得到⼤幅度优化，测试结果相⽐于⽣产环境有明显的性能提升。
•该业务场景的测试结果为后续 TA、O32 等核⼼业务系统迁移到超融合提供了参考数据。
测试期间超融合存储空间使⽤率达 96%，多次测试的结果之间性能差异仅为秒级，SmartX 超融合架构在⾼负载场景下依然保持着可靠稳定的性能输出。

05-某基⾦客户032/TA/CC风控与跑批性能验证

超融合架构 vs 裸⾦属 / NetApp 全闪存储

背景信息

某基⾦客户⾃ 2022 年开始引⼊ SmartX 超融合基础架构平台，⽤于⽀撑办公⽣产 / ⽹站业务 / 开发测试的新⼀代计算存储资源池，到⽬前为⽌，已交付的 2 个集群运⾏稳定。

经过多次交流和讨论，客户计划将⼤部分核⼼⽣产、周边⽣产、ToC 业务等系统（包括相关数据库）迁移⾄ SmartX 超融合集群，包括 O32、TA、FA、CC、反洗钱、直销、订单等多个业务系统。

迁移前，客户需要评估并验证 SmartX 超融合架构的性能表现，通过实际业务场景和真实数据量进⾏核⼼业务系统的模拟跑批，评估超融合架构对于基⾦多元化业务场景的适⽤性。

客户⽣产环境现状

该基⾦客户 O32 / TA / FA 等核⼼应⽤及数据库采⽤裸⾦属服务器，三套系统后端存储通过 NetAPP ⾼端全闪集中式存储提供数据持久化。CC 核⼼数据库采⽤裸⾦属服务器，以本地盘⽅式提供数据持久化。4 套核⼼系统相关的周边⽣产以及直销、订单、⽹站、⽹上交易等各类系统的应⽤和数据库组件，采⽤ Nutanix 超融合平台（ VMware 虚拟化）⽀撑运⾏。

核⼼⽣产系统数据库硬件配置

O32 系统 Intel Xeon Gold 6128 3.4GHz * 2 / 512GB / HBA 16G。
TA & FA 系统 Intel Xeon E5-2643 V4 3.4GHz / 256GB / HBA 16G。
CC 系统 Intel Xeon E5-2650 V3 2.4GHz / 32GB / 数据持久化在本地磁盘（SAS HDD）。

SmartX HCI 测试环境

通过对⽣产系统的资源配置分析，确定采⽤如下测试硬件以⽀撑本次跑批验证。

测试集群由三台服务器组成，超融合采⽤ SmartX 原⽣虚拟化 ELF，并开启 Boost 存储加速模式。
集群内服务器 CPU 异构，其中⼀节点配置 Intel Xeon Gold 6226R * 2，剩余两节点配置 Intel Xeon Silver 4214R * 2。各节点硬件配置 256GB 内存 / NVMe SSD 1.6TB * 2 / HDD 2.4TB * 4 / 25GbE ⽹卡。

迁移 & 新建虚拟机共 7 台，包括 O32、TA、CC 系统 3 套 Oracle 数据库，以及相关的应⽤、中间件、客户端系统 4 台，存储使⽤率达到 65%（ 3 副本）。

虚拟机资源配置

O32 Oracle配置 16 vCPU / 128GB 内存 / 1TB 磁盘。
TA Oracle配置 16 vCPU / 32GB 内存 / 1TB 磁盛。
CC Oracle配置 16 vCPU / 32GB 内存 / 1TB 磁盘。

测试数据

各测试库数据量信息，O32 库 300GB，TA 库 480GB，CC 库 580GB。

验证结论

通过多轮性能测试，SmartX 超融合的跑批性能相⽐⽣产环境显著提升。

模拟 32 万笔委托交易量的 O32 压⼒测试，不带风控委托平均单笔延时 40ms，相⽐恒⽣提供基准值 500ms 缩短 92%。
O32 静态风控场景耗时缩短 67.5%，TA 跑批耗时缩短 41.4%，CC 跑批耗时缩短 91.5%。

通过本次测试充分验证了 SmartX 超融合架构的优势以及对基⾦公司多元化场景的⾼性能⽀撑能⼒，顺利完成跑批测试验证⽬标，为后续客户 IT 规划提供量化参考依据。

06 – 某基金客户 TA 跑批性能验证

超融合架构 vs 虚拟化 / HDS & EMC 全闪存储

背景信息

某基金客户原有 TA 系统的支撑平台老旧，完成一次全量跑批任务耗时接近 14 个小时，伴随数据量的持续增长，跑批时间面临不可控的风险，如果当日夜间的跑批任务不能在规定时间内成功执行完成，将会阻塞后续的业务环节，从而影响到第二天相关业务的正常运行。

客户经过评估，决定将基础架构的改造升级提上日程。通过分析定位，当前 TA 跑批任务主要瓶颈点出现在存储侧，明确了改造目标后，客户调研了多种集中式存储产品，并于前期完成了对 HDS 和 EMC 集中式全闪存储的验证工作。后续 SmartX 通过和客户的日常沟通和场景探讨，使客户对分布式存储的表现产生了兴趣，借此次基础平台改造工作，验证并探索分布式存储在该业务场景下的性能表现，从而为后续架构选型提供可量化的数据参考。

SmartX HCI 验证环境

此次测试为补充测试，由于 HDS 和 EMC Unity 680F 集中式全闪存储测试已经结束。客户再次从生产环境导出 TA 相关虚拟机，并导入测试环境进行验证，确保测试条件公平一致，使测试结果更具有参考性。

SmartX 超融合集群由 3 台 Dell R750 服务器组成，服务器配件配置信息 Intel Xeon Gold 6226 2.9GHz * 2 / 768GB / Intel NVMe SSD 3.2TB * 4 / 25GbE TA 系统相关虚拟机资源配置信息。TA Server 配置 16vCPU / 32GB / 150GB 磁盘。TA Client 配置 8vCPU / 16GB / 1000GB 磁盘。2 台 Oracle 数据库组成 RAC 集群模式（每个数据库 VM 配置 32vCPU / 600GB / 3.35TB 磁盘）。

测试数据

客户日均交易量约 200 万笔，本次模拟 1 – 7 天业务量，并在批处理过程中增加权益登记和红利下发业务流程。

跑批性能对比

验证结论

对比生产环境，SmartX 超融合架构在 200 万笔 – 1600 万笔多个交易量场景下，TA 跑批任务耗时平均有 70% 的缩短。相比 HDS 和 EMC 全闪存储，TA 跑批任务耗时平均也有 20% 的缩短。客户认为，通过对于 TA 4.0 这种基金核心类业务场景的性能测试，证明了超融合平台不仅能够很好的支撑基金公司核心业务系统，而且还能大幅提升系统执行的效率。客户认可超融合架构轻量、简单、弹性的特点，通过本次测试，对超融合架构的价值有了更进一步的理解。

07 – 某基金客户基于投研和 TA 系统跑批验证

超融合架构 vs 裸金属 / Netapp 全闪存储

背景信息

基金行业正处于业务快速发展阶段，随着业务形态的逐步丰富、交易量的不断增加、新系统的快速交付与稳定运行都要求 IT 基础架构提供快速的响应和稳定的性能支撑。客户了解到 SmartX 在多个金融用户的跑批验证效果后，引起了客户兴趣，并推动针对投研和 TA 系统的跑批验证工作。

客户将生产环境的数据完整导入至测试环境，通过对比超融合环境与传统集中式全闪环境下的任务耗时，验证超融合架构对于核心业务场景的支撑能力。

客户生产环境现状

生产环境 TA 数据库通过 Oracle RAC 支撑（3 台裸金属服务器），存储使用 Netapp 全闪阵列，配置信息如下。

服务器 Lenovo SR850 * 3。
Intel Xeon Platinum 8156 3.6GHz * 4 / 512GB / HBA 16G。
存储 Netapp A300 全闪。

SmartX HCI 验证环境

超融合平台单独部署一台 Oracle 数据库虚拟机，从生产环境导入数据 5.5 TB，虚拟机资源配置 16vCPU / 128GB 内存 / 6TB 磁盘（数据保护 2 副本）。超融合集群服务器硬件配置如下。

Intel Xeon Gold 6246 3.3GHz * 2 / 256GB / NVMe SSD 1.6TB * 2 / Intel SSD 3.84TB * 4 / 25GbE。
开启 RDMA 和 Boost。

测试数据

生产环境和测试环境采用相同的应用配置以及数据进行 TA 跑批性能验证。共包含 3 个业务场景和 5 个测试项，测试对比数据如下。

场景 1：TA 跑批测试（TA 跑批包含多项任务串行操作，包括参数初始化、客户资料加载、数据下载等多项子任务，在客户日常跑批过程中任务耗时最长）。

场景 2：投研跑批测试

场景 3：投研系统查询任务测试

验证结论

与传统架构的任务耗时对比，能够看到超融合平台所提供的高性能分布式存储在跑批任务场景中能够大幅提升任务执行效率，缩短任务耗时，加速业务流转。

通过验证 TA 业务系统中任务耗时较长的跑批任务，超融合架构完全能够实现对于基金公司核心业务系统的支撑。

对比传统架构资源独用的使用方式，采用超融合架构在支撑核心业务（数据库）场景的同时，还能够将服务器硬件资源与其他业务系统共享，大幅提升服务器的资源利用率，同时带来快速资源交付以及统一运维管理的收益。后续为客户引入超融合架构应用在更多元化的业务场景提供了可量化的数据参考。

08 – 某保险客户基于分布式存储验证数仓跑批场景

基于 Intel 平台构建分布式存储 vs EMC 集中式全闪存储

背景信息

某保险客户使用传统架构支撑数仓业务系统，存储采用 EMC PowerStore 全闪阵列，虽然现阶段可满足经营决策者及监管机构对信息时效性的要求，但科技部门认为该架构仍然面临以下挑战。

全闪中高端集中式存储采购和综合运维成本较高。
集中式存储弹性扩展能力有限，无法做到容量及性能同步线性扩展。
新旧集中式存储替换带来庞大的数据迁移工作和开销，且无法保证业务零中断。

得益于分布式的架构和弹性扩展能力，分布式存储能很好地解决以上问题。但让科技部门顾虑的是，分布式存储性能能否对标全闪中高端集中式存储，能否有效支撑数仓业务系统对报表输出时效性的要求，为此，该客户在测试环境部署 SmartX 分布式存储支撑数仓业务系统，进行跑批性能验证。

客户生产环境现状

生产环境当前采用传统三层架构，即物理服务器、FC 交换机和集中存储的组合，资源配置如下。

计算端 Intel Xeon E7-4830 v4 * 4（四路服务器） / 512GB / HBA 16G。
网络使用 FC 交换机。
存储端 EMC PowerStore 1000T / NVMe SSD 1.9TB * 16。

SmartX ZBS 验证环境

通过对生产系统的资源配置分析，确定采用如下测试硬件以支撑本次跑批验证。

计算端使用物理机部署 Oracle 数据库，配置 Intel Xeon Gold 6226R * 2 / 512GB / 25GbE。
网络使用 25GbE 以太网交换机。
存储端由三台通用 x86 服务器组成，并安装 SmartX ZBS 分布式存储系统构建存储资源池。
Intel Xeon Silver 4214R * 2 / 64GB / NVMe SSD 3.2TB * 2 / HDD 2.4TB * 4 / 25GbE。
存储接入采用 NVMe over RDMA 高性能协议。

测试数据

测试数据来自真实生产环境，导入数据量 3.9TB，提取并处理 4 / 5 / 6 三个月数据集，跑批记录每个月执行开始时间到结束时间。

跑批结果显示，相比生产环境，SmartX 分布式存储执行全部存储过程集，3 个月平均跑批时间缩短 45%；其中，某耗时最长存储过程，3 个月平均跑批时间缩短 55%，其他存储过程集 3 个月平均跑批时间缩短 31%。

数仓业务跑批期间统计了 ZBS 分布式存储在该业务下的存储负载峰值，与存储基准性能做了进一步对比。从数据可以看出，ZBS 分布式存储除支撑该数仓工作负载外，仍有很大性能余量。

基准性能数据指 SmartX ZBS 在本次测试环境的最佳性能。
本次测试数据指数仓业务跑批期间 SmartX ZBS 监控的负载峰值。

验证结论

本次测试由客户全程操作完成，从测试结果看，SMTX ZBS 分布式存储结合 NVMe over RDMA 数据接入协议，已经具备承载客户现有的数仓应用的能力。这意味着，客户可以在不改变上层数仓应用的情况下，通过优化基础架构设施进一步提升跑批的效率，缩短跑批时间，从而以更少的成本带来更大的应用价值的提升。

SmartX ZBS 分布式存储的诸多特性为客户提供面对多场景不同工作负载需求的存储解决方案。

灵活的接入协议 iSCSI & NVME-oF。
多种磁盘介质的使用组合方式（分层存储 & 全闪存储）。
适配多种基础架构平台（Intel & AMD & 海光 & 鲲鹏）。

09 – 某银行客户风控系统跑批性能验证

基于海光平台构建分布式存储 vs Huawei 集中式全闪存储

背景信息

某银行信用卡中心客户自 2012 年开始使用 SAS 风控系统进行风控跑批，随着业务量的增加， SAS 系统源数据量也随之增加，导致加载耗时不断上涨。由于对性能的严苛要求，客户早期使用物理机本地 NVMe 磁盘进行支撑，从而保证性能可很好满足要求。

随着设备老化，客户将 SAS 系统调整为虚拟化 + NVMe 全闪集中式存储架构。但伴随数据量不断增长，需要对存储端进行扩容，考虑到以下因素，客户推动了本次 POC 测试验证。

集中存储为多个业务系统提供存储服务，当 SAS 系统白天跑批时，需要对 SAS 系统所使用的 LUN 进行限速，考虑将 SAS 系统数据迁出。
基础架构国产化逐步转型。
当前存储品牌绑定，采购成本很难优化并控制。

经过多次交流和讨论，客户计划将 SAS 系统跑批过程中的 TXT 装载部分放到 SmartX 分布式存储 POC 环境中，进行性能验证，评估分布式存储对于银行跑批场景的适用性。

客户生产环境现状

该银行信用卡中心 SAS 系统部署在 VMware 虚拟化平台，由于 SAS 系统对计算资源需求较大，所以采用 4 路服务器作为底层硬件支撑，ESXi 通过 32G HBA 卡连接到全闪 NVMe 集中式存储，为虚拟机提供数据持久化。

虚拟化物理服务器硬件配置

Intel Xeon Gold 6240 2.6GHz * 4。
256GB / 32G HBA。

集中式存储

Huawei Dorado 5600F 全闪阵列。
NVMe SSD 7.68TB * 36。

SAS 虚拟机配置

128vCPU / 128GB / 10TB Disk / 10GbE。

SmartX ZBS 验证环境

本次测试，由客户提供多台服务器，1 台用于安装 ESXi 虚拟化，支撑运行 SAS 虚拟机，3 台海光平台用于部署 ZBS 分布式存储，为前端虚拟化提供数据持久化。为达到与生产环境一致的数据可靠性，分布式存储的数据冗余保护采用 3 副本策略。

SAS 系统的测试数据来自真实生产环境，验证装载耗时最长的 Top 15 表，并与生产环境进行对比。除 SAS 系统数据装载测试外，增加 Oracle 基准测试，验证分布式存储对数据库一般类场景的支撑情况。

虚拟化物理服务器硬件配置

Intel Xeon Gold 6132 2.6GHz * 4。
256GB / 25GbE。

ZBS 分布式存储节点硬件配置

Hygon 7380 2.0GHz * 2。
256GB / 25GbE。
NVMe SSD 4TB * 4 / SATA SSD 3.84TB * 10。
存储接入采用 NVMe over RDMA。

SAS 虚拟机配置

106vCPU / 128GB / 10TB Disk / 10GbE。

测试数据

测试环境相较生产环境，在计算节点 CPU 核心数量、睿频能力、 L3 Cache、网络带宽和存储节点磁盘使用年限均存有一定差距的背景下，月跑批数据装载耗时效率提升 16.3%，日跑批数据装载耗时效率提升 11.2%。

验证结论

多轮 SAS 系统装载跑批验证，在计算端相对弱于生产环境的条件下，基于分布式存储的跑批性能与生产环境相当，分布式存储的性能表现满足支撑中高 I/O 负载应用场景，符合客户测试预期目标，为后续探索银行多元化场景提供参考依据。

10 – 信创平台构建分布式存储验证 TA 估值清算跑批

探索信创平台（鲲鹏 ARM）构建分布式存储支撑数据库场景

背景信息

某证券客户自 2021 年开始采用 SmartX 超融合技术实现基础架构的转型，基于超融合技术构建分布式资源池（信创/非信创），用于支撑生产、灾备、开发测试等多个场景，共交付 100+ 节点规模，部署在多地多数据中心。为了降低硬件投入成本，发挥 SmartX 软件良好的硬件兼容性，灾备资源池建设全部使用利旧服务器进行建设。

客户现有部分灾备数据库基于本地磁盘存储数据（如总部类业务：私募、固收、资讯中心、泛投资等），此类数据库定位在交易类与普通办公类（通常部署在虚拟机中）之间，利用 Oracle DG 实现主备环境数据同步。但由于数据增长较快，对服务器的容量扩容（加盘/换盘/换机器）成为运维痛点，部分扩容动作给上层系统或应用也将带来变更操作，如系统重装、应用压测和上线前基线检查等，增加运维风险。采用传统存储（FC-SAN），需改造网络进行适配，增加改造成本，同时架构复杂度上升。

在信创的大背景下，客户希望基于国产化芯片，构建分布式存储资源池，解决以上运维痛点。推动验证分布式存储在功能、性能和可靠性层面的产品能力，同时对比传统集中存储，探索替代可能性。

SmartX ZBS 验证环境

测试分为两个阶段，首先对比分布式存储与集中存储的基准性能和可靠性验证，最后对比 TA 6.0 业务本地盘跑批性能。

分布式存储由三节点鲲鹏服务器构建。
各节点配置 Kunpeng 920 7261K / 128GB / NVMe SSD 1.6TB * 2 / HDD 1.92TB * 4 / 25GbE。
集中式存储 EMC PowerStore 500T 全闪。
TA 6.0 系统服务器配置 Intel Xeon Gold 8158R 3.0GHz / 512GB / HDD 2.4TB * 4 / 25GbE。

测试数据

存储基准（压测 3 个 Volume）性能对比 SmartX ZBS vs EMC PowerStore 500T。

为了验证 SMTX ZBS 支撑估值业务系统的跑批效果。由客户提供 TA 6.0 估值系统，模拟了估值核算业务逻辑的跑批过程，并记录完成跑批产品数量和跑批时间等指标。测试分别在业务系统本地磁盘和基于 SMTX ZBS 分布式存储提供的 iSCSI 和 NVM-oF 存储协议共三种场景进行了测试，测试数据量接近 6TB。