存算一体 vs 存算分离，银行交易类业务系统分布式块存储技术选型探讨

各位线上的嘉宾大家好 我是来自英特尔的郭镭，今天很高兴有机会在这里跟大家一起探讨一下关于软件定义存储、关于分布式存储的一些话题。存算一体还是存算分离？

我们先来看一下整个软件定义存储市场的情况。从目前市场的情况来看，从我们的视角看见分布式软件定义存储在各行业已经进入到了快速落地的阶段。当前的分布式软件定义存储市场已经不是一个简单使用某种开源的框架，经过简单的封装形成简单的产品这样的形态了 , 而是在很多的场景里面，非常多的厂商在进行一些深度的开发，从开源到闭源，从简单的软件迭代到展开深度的存储技术优化，这里面有涉及到非常多的 IO 通道优化技术的使用 ，包括 SPDK IO_uring DPDK PMDK RDMA 、 NVME over Fabric 以及下一代的总线技术 CXL ，还有下一代的存储介质包括 Optane 以及 QLC 。通过这样一些技术的迭代优化，使得我们的产品能够更好的满足各类型应用的需求。从云化的计算平台到大数据的处理平台、以及围绕着新兴的从 HPC 到 AI 的这样的需求。

我们的需求来自于非常广泛的市场，无论是什么行业 , 目前在考虑原有存储的替代方案 , 都是考虑使用分布式存储这样的技术，或者这样一种架构。另外一点值得注意的是，全闪的架构目前在关键行业或者关键应用领域加速落地。传统的分布式存储，使用最多的是磁盘的技术，磁盘技术在性能上无法满足行业应用的需求，特别是关键应用的需求。全闪架构的快速落地，也能够使分布式存储，或者分布式的软件定义的产品能够适应更多的场景。

回到今天的主题场景，银行行业。我们可以看到银行行业实际上也是一个对于软件定义存储解决方案具有广泛需求的一个领域。银行业有几个非常明显的特点，首先是创新非常的多。比如前端系统，尤其是渠道系统，目前有非常多的新兴的扩展业务渠道 以及新兴的互联网化的业务场景。在中台系统，我们也看到大量的创新。银行行业是最早的提出敏态 ，稳态 双轮驱动的行业，也是各行业里面的较早的使用了容器化技术以及云源生技术的行业，这对于其他行业来说都是非常领先的。

但是我们同样又看到在银行行业、在后台系统部分实际上相对是保守的，他要求后台系统是稳定性为先，而且具有众多合规性的要求，特别重视数据备份，容灾这样一些合规性的要求。所以总体来讲，银行行业实际上是既有创新又有比较传统的一些诉求。但是未来整个行业实际还是总体向着互联网化的方向去发展。通过互联网化的转型，更多的强调的是 IASS/PASS 以及 SAAS 各层有明确的分工。前几年我们可能在提一些智慧银行的概念，现在更多的银行行业的从业者， IT 管理者，包括行业内的一些咨询公司、一些架构的设计机构，更多的是从这种互联网化的角度去重构整个银行在未来下一代的架构，更强调基础的底座以及中台以及前台的各层次的一个清晰的分工。在这个过程中的实际上就引入了非常多的分布式的技术体系，从分布式的处理，分布式的缓存，分布式的负载均衡，分布式的微服务到底层的分布式存储，分布式计算实际都是在个过程中会发挥非常重要的作用。

实际上我们可以看到在发展到一个阶段之后，会强调数字化底座是支撑整个行业应用云原生化的基础，所以云原生化，云化的进一步深入，是这个行业下一步的诉求。基于这样一个大的背景，基于银行行业需求的特点，我们来分析一下具体在选择分布式存储的时候，有哪些影响性的因素，以及我们从哪几个角度去做相应的考量。

第一个角度，因为今天的主题实际上是涉及到交易系统的使用场景，所以第一个考虑的角度，要从数据库的角度去看，如何去选择一个存储系统？如何选择分布式存储的系统？在整个金融、银行行业里，现在能看到的数据库场景或者是我们能够选择到产品主要有三类，一类是传统的 OLTP 的数据库，第二类是新兴的分布式的 OLTP 数据库以及 HTAP 混合架构的数据库，第三类是在未来一段时间里面可能会大量涌现的分布式内存的数据库。这三类数据库都可以承载整个银行行业的应用，但是选择不同的数据库的产品，实际上对未来存储架构的选型还是有巨大的一个差别。

如果使用传统的数据库，一般普遍的做法是对多业务系统进行数据库的整合，把多套数据库整合成一套数据库，然后通过多租户的模式进行业务的分担和处理。这样可以极大的简化在数据库方面的管理成本，但前提是要求所有的系统的都使用同样的一个数据库的架构和同样一个数据库的产品。在这样一种需求下，实际上对存储性能的要求是很高的，用分布式软件定义存储，来替代原有的磁盘阵列的或者原有的全闪的存储，对优化的需求实际上更多的会转移到这个平台层，比如在云平台或者超融合平台。第二和第三种这两个数据库的架构类似，就是分布式的 OLTP ，包括分布式的内存数据库，在很大程度上要求重构整个交易系统，以适应新型数据库的要求，比如 MYSQL 或 PostgreSQL 接口和分布式的架构的需求，所以对业务的变动相对来讲是比较大的。现在看到的行业内最成功的一些使用新型数据库的案例， 实际上都是对业务进行了巨大的重构，这样的一个环境下，还包括网络性能的优化需求，无论是数据库本身，还是分布式存储系统，都对网络的性能和延迟有巨大的一个需求，需要通过网络延迟的缩减来提高系统整体的性能。很多新型的分布式数据库，其实都预留了存储系统的管理接口，也就是说很多产品其实本身是想做存储管理的部分，但是因为数据库厂商在这个方面还有一些不足，或者说还没有那么多精力去完成，但是他们通过预留一些接口能够使数据库产品更好地和一些第三方的分布式的存储，去结合或者配合使用，这是我们看到的一个比较显著的特点。

如果使用的是分布式内存的数据库，实际上又面临另外一类情况，内存数据库的特点是整个的交易的压力，包括业务处理的压力，都在 CPU 和内存层，相对来讲，对于存储层的要求就会低一点，而存储层的稳定性和可靠性和扩展性会成为更重要的部分。三类不同的数据库的需求和特点导致了我们对存储有不同的诉求。此外银行类的业务，其实它的处理逻辑是非常复杂的。举个简单的例子，一个典型的银行业务事物 SQL 语句的条数一般是在几十个甚至上百个 SQL 语句形成一条交易，这是一种非常复杂的业务逻辑，所以我们不能用单纯的数据库吞吐能力来衡量我们整个系统的一个优势或者是劣势，这跟互联网行业是不一样的。互联网行业的业务逻辑相对简单，大概可能只有几条或者十几条 SQL 语句形成一个交易，，它的复杂度跟银行是完全不能比，即使是在互联网的场景上吞吐量非常好的数据库也不见得在银行行业就能有到一个非常好的一个使用的效果。

新一代数据库对于分布式存储的依赖性会越来越高，在刚才的部分的实际也阐述过。当数据库自身不具有存储管理能力的时候，或者存储管理能力不强的时候，就需要跟第三方底层的分布式存储系统进行对接。这个接口的效率以及数据库存引擎层和存储层之间的性能调试和适配就变成一个非常关键的因素了。

我们再看影响分布式存储架构的因素 , 就是一个交易系统的整体系统架构，从客户的选择来看，我们的架构一般会有三种基本的形态：第一种是数据库的一体机，也就是相对架构比较稳定的客户，他可能处在一个业务架构比较稳定的阶段，会优先选择数据库一体机这样一种方式，通过端到端的优化来解决整个业务处理的需求。第二种，实际上有些客户可能会选择超融合系统 HCI ，那这样的客户普遍的特点是他们可能处于从传统的硬件架构向新型的分布式硬件架构过渡的一个阶段，即从传统架构向云架构过渡，这时候超融合系统可能会成为一个比较好的选择。第三个架构就是全面的云化的平台，这个时候是基本上是存算分离的模式为主，也就是说计算层，网络层，存储层成分别去设计和优化，然后有机地在一起进行配合。这个一般是架构处于变革期的客户进行选择的一个方式。

我们回顾一下不同客户对于整个交易系统的选择，平台的选择，总体来讲虽然架构不同，但是对于分布式存储对底层的软件定义存储来说，其实需求基本是一致的，都是要求高性能和低延迟。架构的不同我们选择的平台和数据库不同，存储系统也可能不同，从我们的经验来看平台和应用的优化其实才是更加关键的因素。为什么这么说呢 因为我们有很多的案例，或者是和客户和合作伙伴一起做的一些综合的测试表明硬件的性能的高低，或者说理论上各种不同的平台性能的高低，其实并不一定是决定的因素。

我给大家举三个例子，第一个例子是我们曾经做过一个交易系统的案例，也就是一个三节点的超融合平台对比传统的物理机加上传统的全闪存储阵列，我们看到最后的结果是超融合平台无论是在存储 IO 能力、响应的延迟能力以及最后基于数据库的测试结果，其业务处理能力已经全面超过了传统的架构，这是一个比较典型的例子，证明超融合或者云化平台虚拟机加上分布式存储架构这样一套应用的承载器，实际上已经能够超越传统的物理化部署的性能。

第二个例子 实际上是超融合之间的对比。我们曾经用两个超融合平台来进行某个交易系统的测试。两个超融合平台使用同样的硬件 差别在于底层的分布式存储的架构不同，性能也有差异。平台 A 的存储的性能可以达到 50 万个 IOPS 这样一个级别，平台 B 可以达到 100 万 IOPS 的级别别， 如果没有我们最终的测试结果，主观想象平台 B 一定会比平台 A 具有更好的交易性能，但是最终我们测出来的结果是平台 A 和平台 B 能够达到的性能其实是一样的，就是在满足业务需求的情况下，两者并没有本质的差别。

第三个例子 实际上是我们在超融合系统以及和物理机运行数据库的一个性能的对比。我们传统的理解或者说我们主观的理解都会认为物理机在跑数据库的时候会有更好的性能，如果是虚拟化平台，因为有虚拟层的开销，所以相应的平台性能会稍微差一点。但实际上我们测出来的结果，恰恰相反，我们看到最后的业务表现是二者的性能几乎是一样的，而且在某些延迟方面虚拟机的性能会更好。这证明了另外一个问题，就是虚拟机有的时候在做系统优化的过程中，在针对数据库和应用优化的过程，因为有非常好的 NUMA 优化设计，所以反而比物理机跑出更好的性能，这个跟底层的存储平台底层的网络平台所采用的架构介质或者是成本就关系就比较小了。所以综合来讲回到我们最开始的结论：无论是我们使用什么样的硬件，无论我们使用什么样的架构，最终平台和应用的优化其实才是最关键的一个因素，不能只是简单的对网络计算存储的某一个单体做测试，最终的整体的应用的优化测试才是我们要看到的结果。但是如果在整体的这个系统都是比较优化的情况下，我们怎么样来做高性能低延迟的分布式存储设计？这个是在前页的 PPT 里我们预留的一个问题。因为所有的平台都对存储的要求都是高性能和低延迟，那分布式存储怎么设计呢？

我们过去几年跟很多合作伙伴有过相关的研发合作，总体来讲大家的方法都比较趋同，比如说 Cache 层的设计优化、协议层的简化、网络层的优化，通过 RDMA 的技术来降低网络延迟 , 使用全闪的这种介质来减少存储的瓶颈 , 还有就是充分利用硬件的特性等等。右边这张图中，实际上英特尔提供了一个简单的参考架构设计，这也是英特尔自己的一个文件系统，比较清楚的解释了我们的一些设计理念。

首先就是在 Cache 层上会有一些比较好的变化。我们把对性能影响最高或者说性能敏感度最高的原数据以及一些小的 IO ，通过新的 cache 设计使用新的物理的介质去承载，同时把小的 IO 合并成大的 IO 来优化 IO 的性能，节点之间通过 RDMA 的网络的设计来优化延迟性能 , 所以总体通过这样的一套设计 , 在理论上就可以非常明显的提高系统的整体的性能和运行的效果。目前我们看到已经有不少的产品根据这样的一套理念的进行产品的重构和演进，市场上也能看到这样一些解决方案，大家可以去尝试一下。

我们讲刚才讲的一些基于全闪的优化，如何去构建一个全闪的新一代的分布式存储的产品。但这样的一个前提实际上是来自于整个介质层技术的一个变革。因为英特尔前几年提出了傲腾™技术，它是介于内存和传统 NAND 闪存之间的一层技术，分为内存的形态和固态板的形态。英特尔 ® 傲腾™ 技术的核心价值实际上是对于传统的闪存相比拥有更好的寿命，与内存相比有更大的容量，且有非常好的响应的性能。使用英特尔 ® 傲腾™ 技术可以带来非常好的加速能力，同时又具有更好的写寿命，它非常适合做新一代分布式存储的缓存优化 。上页介绍的如何去做高性能低延迟存储的一套架构，实际上就是基于新一代英特尔 ® 傲腾™ 介质去设计的。

当前我们也看到越来越多的软件开发商、存储厂商在基于这样的介质、这样的架构里面去升级他们的产品，同时我们看到得出的效果也是非常显著的。还有一个可能在当前和未来几年去深度影响整个存储行业，或者整个这个分布式架构演进的一个方向的就是 IPU 技术。在这张图里我们可以看到在未来的数据中心里，每一个物理的服务器节点都会有 IPU ，实际上相当于把原来在网络，存储以及安全方面的一些负载，通过 IPU 进行卸载，释放 CPU 的算力资源，放到 IPU 里面去做。所以我们可以想见，有了 IPU 这样的一个物理设备和技术能力之后，未来下一代整体的云化软件设计，包括分布式存储软件的设计，都会考虑 IPU 所带来的影响和 IPU 在整个架构里面的位置 。

如何利用起来、如何利用好 IPU 、如何利用 IPU 去增加存储方面的性能，如何利用 IPU 去增强存储和计算之间的融合，会成为我们下步需要考虑的问题。

基于刚才我们介绍的在介质方面，协议方面的演进，硬件方面的演进，目前的英特尔有一个面向未来的分布式存储平台的硬件推荐思路。

可以看到在这个方案里面基本上是一个全闪的架构，服务器里面使用英特尔 ® 至强 ® 可扩展处理器，目前英特尔 ® 至强 ® 可扩展处理器这两代其实还有非常多的演进，我们可以看到越来越多的存储加速器，包括网络加速器，计算加速器都会以独立的运算单元的形式存在于英特尔 ® 至强 ® 可扩展处理器之中，所以把英特尔 ®至强 ® 处理器用好也会在存储和计算方面提供非常好的性能加持 。

在磁盘方面分为两层：一层是基于新一代的比如说英特尔 ® 傲腾™ （ Intel® Optane™ ）技术来构建的新一代的缓存池来处理原数据，处理最热的数据 ，底层的容量层基本上会被大容量的闪存盘 , 特别是 TLC 、 QLC 这样的闪存盘所取代， 所以未来全闪架构实际上现在已经是可以被我们广泛采用的这样一套架构。另外，在这样的平台里面的还有两个比较关键的因素，一个是网络的连接器 也就是网卡，网卡可以是普通的网卡，也可以是智能网卡。但是未来会有一个比较普遍的诉求， RDMA 的高性能低延迟的网络来减小在网络层面的一些开销，因为分布式系统对网络的依赖性非常高。还有一个就是一些专用的数据服务的加速卡。这个里边有一些智能网卡或者是 IPU 的影子，很多在存储方面我们需要进行处理，原来非常耗费 CPU 资源的这样的一些数据处理包括压缩、包括纠删码的保护，包括路径的优化等等，都可以通过数据服务加速卡来实现，英特尔也陆续提供了参考方案。

最后总结一下我们的几个观点和未来会面临什么样的挑战。存储一体还是存算分离？我觉得这是一个比较开放式的问题，我们可能都没有一个非常直接的答案，因为它取决于非常多的因素，比如说我们要看客户的场景，比如使用的场景，它的云化和云原生的程度是怎样的，存算一体和存算分离实际目前都在同步的演进的过程中。在云原生的环境里面，大数据，数据库，存储这些原来都在容器平台之外的系统，逐渐都在被纳入到 K8S 进行统一的管理和部署，所以又变成了一个融合的一个状态 。所以我们没有一个特别明确的一个答案。

第二个就是看服务的系统是只有交易类的系统还是做综合类的应用，如果只有交易的系统的话，高性能低延迟是我们追求的终极的目标，但是我们前面的页面也介绍过，实际上系统的整体优化是最关键的一个问题。另外如果我们是综合应用的话，那可能考虑的更多，除了性能和延迟之外，还要考虑更多容量的问题、扩展性的问题以及并发性能的问题。

第三个是看我们选择分布式存储系统，到底是要使用硬件加速，还是使用一个纯软件栈？硬件加速刚才我们也提过，实际近几年硬件加速技术演进的非常快，我们看到通用的 CPU 里，或者未来的 IPU 产品里面，都会有非常多的硬件的加速技术，包括计算的加速以及存储的这个加速的能力，所以如果是存算分离的架构，有可能我们会浪费一些 CPU 在计算方面的加速能力。所以我们也不能说存算一体或者是存算分离哪一种更好，从系统整体的管理角度来讲，或者说从扩展性的角度来讲，存算分离可能是一个大趋势里面我们会优选的一个架构，可能更适合于扩展，但是如果从系统优化的角度来讲，存算一体也有它的优势。

在整个银行行业，还是有比较明确的挑战，在使用这样的系统的时候，因为目前产品的成熟度，无论是技术成熟度还是软件成熟度，还没有达到一个非常高的水平，跟整个银行业务的架构、系统的架构的演进，包括业务的创新速度、中间还是有一定的距离。所以如何能加速产品的演进以及以适应业务的需求会成为一个挑战，在这个过程中过渡期是必不可少的。另外一个就是根据行业的特殊性的考虑，因为在金融的整个的场景里面，稳定性是第一位的，性能可能都是放在其次，稳定性产品的成熟度以及厂商的服务能力实际上是非常非常重要的。而且很多都是非常复杂的业务逻辑，所以他对存储产品的要求也是比较特殊的，我们以前有一些经验，很多在开源领域 、在互联网的应用环境里面运行的很好的分布式系统，放在金融行业使用反而有很多的问题，就是因为他们的业务逻辑不同所造成，所以我们还是要提出之前的观点，系统优化其实是更加重要的，无论我们采用存算一体还是采用存算分离，最终我们要达到最好的系统应用效果，通过软硬件的协作和优化才是我们达到这个最佳结果的一个必由之路。

相关视频：
存算一体vs存算分离，银行交易类业务系统分布式块存储技术路线