（来源：twt社区 twt企业IT社区）

XIAO  MAN

传统一体化架构逐渐显现出性能瓶颈和扩展性等问题，尤其是在 AI 时代数据量剧增、计算需求日益增长的背景下，存算分离架构（Storage-Compute Separation）逐渐成为金融行业企业和技术团队所寻求的优化解决方案。如何选择合适的存算分离存储和计算平台？如何进行性能优化与资源调度？在具体的选型过程中应该考虑哪些因素？ twt 社区各领域专家结合理论与实战经验进行了细致的探讨与分析。（议题主持人：郭恺 某银行 存储技术专家）

社区相关投票共识结果

银行核心总账、信用卡、支付中心等关键 OLTP 交易系统产生的数据，是驱动智能风控、精准营销等关键AI 场景不可或缺的“燃料。为支撑可信 AI 应用，这些敏感数据有必要安全、高效地汇入 AI 数据湖。但在“信创分布式数据库 + 服务器本地盘多副本”的架构下，信创系统可靠性与 AI 数据入湖两大关键维度的痛点也愈发明显，为精准定位该架构有哪些核心痛点及隐患，特发起行业投票：“针对信创与 AI 数据治理，您认为信创分布式数据库 + 服务器本地盘多副本架构存在哪些核心隐患？”投票结果如下：

参与社区共识协作用户（社区 ID）：yuanly、wangghost556、ccrccr0603、disorder2013、jqht、chenxiaofei、zhenbaom、lding1985、yangyl_1987、hhucwhy、edisonzhou、wwzwh9521、hujw2016、侯守立、lihui、jfm、luckman_2008、sportsboy、wangzk0206、koolkite、liangjing_2018、chjayhsx、m_trump、ludi、yata52、chenmingfu、飞一直飞、wen_jxpx、fengwhq、陈翔 1006、chiyang、bankhp、informixfan、catalinaspring、huawei851120

参与用户来自企业：江苏农信、浦发银行、江苏银行、贵州银行、中信建投证券、建设银行、云南红塔银行、华泰证券、国信证券、北部湾银行、北京银行、中国太平洋保险(集团)、重庆三峡银行、平安银行、中信银行、郑州银行、徽商银行、国家开发银行、江西农信、兴业数金、长沙银行、浙商保险、中英人寿、四川农信、福建海峡银行、泰康保险集团、贵州银行、内蒙农信、中原银行、中国人寿财险、宁夏银行、吉林银行、哈尔滨银行、青岛银行、申万宏源证券、安徽农信、中国银行

部分参与投票同行观点

• koolkite 金融行业 数据库架构师 ：

针对数据入湖的场景来看，显然数据存储量是在不断上涨，在容量规划上就存在一定的事实难度，其次也会带来本地盘存储资源使用率不高的可能性。

• chjayhsx 西南某城商行 数据库工程师 / 架构师：

分布式数据库采用计算与存储分离的设计，虽提升了资源扩展灵活性，但也引入了数据访问延迟增加的风险。尤其在日终批处理等集中作业时段，批量任务可能持续占用大量存储 I/O 资源，进而对交易类业务的响应速度造成干扰。

在实际运维中，单纯依赖磁盘 I/O 利用率等传统性能指标，可能难以有效捕捉和解释这种延迟。业务系统已感知到性能下降，而数据库底层监控指标却显示“正常”。因此需要与自身公司的监控建设相关联，例如：

1. 监控的关联度：现有监控体系更关注磁盘吞吐量、IOPS 等硬件级指标，而对事务就绪时间或查询响应延迟 等直接影响业务体验的端到端链路指标覆盖不足。

2. 下沉式监控：未能将数据库内部指标（如锁等待时间、日志同步延迟）与底层存储系统的 I/O 队列深度、缓存命中率等进行关联分析。

• lujin 某保险 IT 运行中心 技术经理：

从数据库的角度，我认为的核心隐患是指数据丢失、数据不一致、不能保证事务的原子性、不能保证读写数据的一致性、不能进行备份和恢复，核心是不能保证数据的完整性、安全性和一致性。

同行专家探讨

■ 王辉 某大型金融机构 技术专家

优先选择具备数据主权保障能力的存储方案，满足信创合规要求，推动存算分离的信创替换。

结合业务需求与技术特性综合考量，给出以下建议：

1. 性能与可靠性优先：对交易高频的核心系统，优先选择专用硬件方案（如全闪存阵列 +RDMA 网络） ，其低延迟、高IOPS特性可保障交易响应速度；辅以双活 / 多活架构，RTO 接近 0 秒。分布式存储适合非核心交易业务，通过分布式副本机制实现高可靠，但需关注网络带宽对性能的影响。

2. 兼容性与扩展性评估：云原生存储凭借容器化部署和 Kubernetes 集成能力，与微服务架构兼容性最佳，适合新兴 AI、大数据业务。在选型时，需重点考察其 CSI 驱动成熟度、与调度器的集成能力以及对持久化卷管理的便捷性。

3. 成本与运维权衡：专用硬件初期投入高但运维复杂度低，适合预算充足且对稳定性要求极致的场景；依赖通用服务器的云原生存储，硬件成本较低，但需专业团队处理分布式系统的运维问题。

4. 安全与合规保障：无论选型哪种方案，需确保存储系统支持国密算法加密、细粒度权限控制及审计日志功能；对于涉及敏感数据的场景，优先选择具备数据主权保障能力的存储方案，满足信创合规要求。

5. 存算分离的信创（自主可控技术）替换：信创替换在存算分离架构中的实现虽然具有巨大的潜力，但也面临着很多挑战，如：兼容性问题、技术成熟度、成本问题等，然而在产业自主性提升、技术创新、国际化竞争力等方面也是一个重大的机会，在推动国内自主可控技术方面具有重要意义，尤其是在高性能计算、存储和网络设备的国产化替代方面。实施路径上，建议采取“由边缘到核心”的渐进式策略，先在非关键业务系统中完成技术验证与团队能力积累，再逐步向核心系统推进。然而实施这一替代需要克服很多方面的挑战，但这也是国内信息技术产业逐步走向自主创新的重要一步。

■ 徐园园 某城商银行 数据架构师

剖析 SAN、云原生与专用硬件三大技术路线，明晰其适用场景与演进关系。

存算分离技术是一种将计算和存储资源解耦的架构设计理念，其核心思想是将数据存储和处理逻辑分开，分别进行处理。在 SAN（存储区域网络）存储场景中，存算分离技术通过高速网络协议（如光纤通道、以太网）连接服务器和存储设备，提供高效、可靠的数据存储和访问能力。

随着国内数据基础设施技术日渐成熟，数据库存算分离方案也成为金融行业数据库改造的优选方案，不仅有效解决了传统架构下的性能瓶颈与扩展难题，更以其灵活性和高效性，日益凸显其在金融数据库改造进程中的关键价值。数据库存算分离带来了实实在在的效能提升：在可靠性方面，存算分离架构通过共享存储，高可用隔离掉硬盘故障对数据库自身产生的影响，使得数据库的运行处于稳定状态；灵活性方面，把计算节点从原来的物理机改造成了虚拟机，并进行大规模应用，极大的保证了业务的连续性；经济性方面，将大规模的物理机改造成虚拟机，极大降低了服务器成本。同时，在应对 AI 数据治理需求时，其数据共享能力和高效的数据供给机制，为消费域提供了稳定、高质量的数据输入支撑。

技术路线选型：

1. SAN 存储场景的存算分离

技术特点：这种架构通过将存储设备与计算机分离并连接到专用网络中，实现了高性能、低延迟和可靠的数据传输。

2. 云原生存储

演进关系：从 SDS（软件定义存储）发展而来，支持容器化部署（Kubernetes CSI 接口），更适合云原生环境。

技术优势：与业务容器混合部署能力突出，支持冷热数据分层存储（内存 /EVS/ 对象存储）。

挑战：大对象存储带来的写放大问题与小对象存储增加的元数据开销需权衡。

3. 专用硬件方案

适用场景：对延迟敏感的核心交易系统。

局限性：扩展性不足，与 AI 场景的弹性需求存在矛盾。

■ 程宗憬 某银行 存储架构师

架构选型要结合实际情况考虑，从业务需求反推技术选型。

选型和实际需求场景高度相关，比如是高性能的计算需求，大数据海量文件存储分析需求，微服务容器化需求，甚至备份恢复需求。确定需求场景后一般就可以做技术的选型和方案规划了。对于存储来说，主要有分布式存储、集中式存储。然后需要对平台的关键能力进行分析，主要包括：

1. 性能需求，IOPS、带宽等指标：除了峰值性能，更需关注长时运行下的性能稳定性（即尾延迟控制），这对于交易系统至关重要。

2. 平台扩展、高可用等特性：需明确是线性扩展还是存在瓶颈点，故障域如何隔离，数据重建速度等。

3. 投入成本：需建立 TCO（总体拥有成本）视角，综合评估硬件采购、软件许可、机房空间、电力消耗、运维人力等全生命周期成本。

4. 兼容性：是否支持已有资源、其他类似容器平台的支持等，特别是与现有数据库、中间件及运维监控体系的集成能力。

架构选型很大程度要与实际情况结合考虑，所以更多时候需要从业务需求反推技术选型，并通过概念验证（PoC）对候选方案进行严格的可行性论证与测试。PoC 不应仅是性能跑分，而应模拟真实的业务压力、故障场景和运维操作，全面评估方案的综合表现。

■ 吕利文 某证券 存储架构师

AI 数据治理需求的匹配性。

围绕存储算分离架构存在多种技术路线，其实关键在于具体使用场景，不同场景技术方案或路线选择也不同。

1. 训练场景：Checkpoint 写放大 。近期了解在万卡训练时，单轮 Checkpoint 在 3~6TB，单节点写带宽需求≥ 100GB/s。这时选用分布式存储，必须确认缓存到对象存储的 flush 策略是异步后台流式而不是同步阻塞。

2. 推理场景：首 token 延迟。最近了解到线上推理大模型（70B+）场景，权重 140G，一次 load耗时 10s 就超时。这时通常有两种玩法，可以将权重预取到 GPU 节点的本地 NVMe 盘，或者通过GDS+NVMe-oF 绕开 CPU（但对外设网络环境要求较高 100G 起）。除了场景考虑，成本方面也需要考虑，特别是 GPU 的利用率。通常做法是采用分离架构部署、 CPU池化及调度优化，来实现成本节约。同时，有效区分离线训练和在线推理，实现混合调度，进一步实现成本控制。

议题共识总结

存算分离架构的选型是一项复杂的系统工程，需要从多个核心维度进行综合考量。基于本次研讨，形成了以下几个关键维度的共识，为金融同行选型决策提供系统化框架：

1. 业务场景驱动维度

选型必须始于业务场景的精准分析。需要明确区分核心交易系统与创新业务场景的不同需求：核心交易系统追求极致的稳定性和低延迟，而 AI 训练、大数据分析等场景则更注重弹性扩展和吞吐能力。建议建立业务场景与技术方案的映射矩阵，确保选型与业务目标保持一致。

2. 技术特性评估维度

性能指标方面，除关注 IOPS、带宽等常规指标外，更要重视尾延迟控制能力，这对交易系统至关重要。扩展性评估需区分线性扩展与存在瓶颈的架构，明确单集群最大支持节点数。可靠性要求应包括故障域隔离策略、数据重建速度等具体指标，确保 RTO/RPO 目标可达。

3. 信创合规实施维度

在信创背景下，需要建立国产化替代的成熟度评估体系，包括产品稳定性验证、生态兼容性测试、服务支持能力评估等。建议采取“分级分类”的推进策略：先在业务容忍度较高的场景验证，再逐步向核心系统推广。

4. 成本效益平衡维度

应建立全生命周期TCO分析模型，综合考虑硬件采购、软件许可、运维人力、能耗空间等成本因素。资源利用率是关键衡量指标，需要通过资源池化、弹性伸缩等技术手段提升整体投资回报率。

5. 网络基础支撑维度

网络是存算分离架构的“中枢神经系统”，必须提前规划低延迟、高带宽的网络基础设施。建议部署RDMA、 无损网络等先进技术， 并为存储网络预留足够的性能余量， 避免网络成为系统瓶颈。

6. 数据治理与安全维度

需要建立贯穿数据全生命期的治理体系，包括数据分级分类、访问控制、加密传输、审计追踪等。在 AI 场景下，特别要关注训练数据的质量管理和推理数据的隐私保护，确保符合监管要求。

实施路径建议：

建立跨领域的架构决策机制，由存储、数据库、网络等多领域专家组成评审委员会。制定详细的选型评估矩阵和评分标准，通过严谨的PoC验证，全面测试性能、可靠性、兼容性等关键指标。

采取“试点先行、稳步推进”的实施策略，确保架构转型的平稳有序。最终，成功的存算分离架构选型需要在技术先进性与业务实用性之间找到最佳平衡点，既满足当前业务需求，又为未来技术演进预留足够空间，从而构建面向数字化转型的下一代数据基础设施。