购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

3.1 可计算存储

什么是可计算存储?SNIA(全球网络存储工业协会)的定义:可计算存储为一种将计算功能与存储耦合以卸载(Off load)主机处理或减少数据搬移的架构,该架构通过集成主机与存储驱动器之间的计算资源,或直接集成存储驱动器内的计算资源,提高应用程序性能或优化基础设施的效率,目标是实现并行计算,或减轻对现有的计算、内存、存储和I/O的限制。

通俗地讲,可计算存储是在原有存储设备(比如NVMe SSD)上叠加专有芯片,并由该专有芯片直接加速与数据存取相关的计算任务,实现CPU计算任务卸载或数据的搬移。

图3-1a所示是当前传统的计算/存储架构,图3-1b所示是可计算存储的两种架构:左边所示架构是在CPU和存储设备上增加专有芯片,右边所示架构是在存储设备内部集成专有芯片。

3.1.1 可计算存储的诞生背景

我们正处在一个前所未有的数字化转型的进程中,各种新兴技术的产生和使用都会面临一个共同的问题——数据产生和使用呈爆发性增长,这会给底层的计算和存储技术带来巨大的挑战。

图3-1 传统存储架构与可计算存储架构

1.存储面临的挑战

在过去的几十年中,存储技术从卡带到磁盘,再到固态硬盘,容量和性能都得到了巨大的提升,但提升的速度远远赶不上数据增长的速度。我们把2020年全球存储的产能加起来大约是20ZB(相当于20亿张10TB的硬盘),这已经是比较惊人的产量。但到了2025年,根据国际数据公司(IDC)的预测,全球数据量将会达到175ZB,而那时存储的产能只能达到22ZB,可想而知这将是存储方面面临的巨大挑战。

2.算力面临的挑战

英特尔创始人提出的摩尔定律在20世纪70年代到21世纪00年代神奇般有效,CPU的性能每隔18个月翻1倍,价格下降50%。但是在过去的10多年里,由于CPU的性能提升逐渐接近物理极限,摩尔定律逐渐失效,CPU的性能每隔18个月的提升已经不足2倍,与此同时数据的增长量却呈爆发式增长。这种情况下算力也将面临巨大的挑战。

当传统的计算与存储方式难以满足数据增长需求的时候,就必须通过创新来解决计算和存储的效率。提升计算和存储效率最有效的解决方案就是将计算分流,例如:

❑ 可以将AI的计算分流到GPU、TPU、DPU等计算AI数据效率更高的专有芯片。

❑ 随着高带宽、低延迟智能网卡的出现,CPU在网络上的计算开销越来越大,此时可以将网络相关的计算分流到智能网卡芯片。

❑ 尝试将存储中与数据相关的计算任务下推给存储本身的芯片(例如:数据压缩与解压、数据过滤、数据加密与解密等)。

在上述计算分流方案中,将存储的数据处理分流到存储设备内部,理论上不但能节省主机CPU算力资源,而且能不来回复制数据浪费系统总线资源。随着存储容量的扩展,通过计算分流方案还能线性扩展在存储设备内处理数据的能力,甚至可以利用多块盘内的专有芯片并行处理更多的计算任务。

综上,催生带计算能力的存储设备势在必行,所以可计算存储应运而生。

3.1.2 可计算存储的应用探索

可计算存储的基本原理并不复杂,下面与传统存储架构进行比较说明。

1.传统存储

数据从存储设备复制到主机内存,由主机CPU处理完成之后,再经由主机内存复制回存储设备内。当数据量不断增长或数据的处理需求不断增长,当前设备无法满足计算需求时,有效的解决方案是扩展硬件(如采购更大的存储设备、更快的CPU、更多的服务器等)。但硬件扩展的速度往往跟不上数据增长的速度,而且更快的数据增长意味着存储设备中需要存放更多的数据,有更多的数据需要从存储设备移动到主机内存,CPU需要处理更多的数据。这时CPU算力、存储容量以及系统总线带宽都可能成为瓶颈,所以扩展硬件的方案在这种情况下就显得捉襟见肘了。

2.可计算存储

可计算存储可拉近数据存储端(存储设备)与数据运算处理端(专有芯片)的距离,盘内集成的专有芯片可直接在盘内完成数据的处理运算。如此一来,不但可大幅减少数据的搬移量,还可大幅提升计算的性能(专有芯片的计算性能远远高于通用芯片)。如果在一台服务器中插有多块可计算存储设备,甚至还可以利用多块可计算存储设备中的专有芯片来大幅提升计算的并行度。

在可计算存储领域,来自ScaleFlux的CSD 2000系列NVMe SSD(下文简称CSD 2000)就是一款自带专有芯片与计算引擎的可计算存储产品。为便于大家更好地了解这款产品,下面我们对其进行简单介绍。

在产品形态上,CSD 2000支持U.2(见图3-2左侧)和AIC(半高半长,见图3-2右侧)两种标准的物理接口,支持NVMe协议。

图3-2 CSD 2000 U.2(左)和AIC(右)接口的产品形态

如果把CSD 2000的盘拆开来看(以U.2接口形态的产品为例,见图3-3),CSD 2000与普通NVMe SSD并无多大区别,都包含存储芯片(闪存颗粒)和主控芯片,不一样的地方在于可计算存储的主控芯片内包含了计算加速引擎以及配套的核心软件与固件,可以更好地发挥底层硬件的性能,以便更好地服务上层核心应用(如数据库应用等)。

那么,在完成CPU计算任务卸载的同时还能够大幅提升应用性能的“隐形之手”——计算加速引擎。这究竟是什么黑科技呢?

在CSD 2000这款产品中,可圈可点的计算加速引擎当属透明压缩/解压和计算下推。新技术的应用探索过程通常都少不了蜿蜒曲折,可计算存储的应用探索过程也是如此。下面对这两种计算加速引擎的应用探索过程进行简单介绍。

3.透明压缩/解压

透明压缩/解压是利用可计算存储缓解容量压力的探索。

图3-3 CSD 2000的内部架构

SSD的出现极大地提升了存储性能(如提升IOPS并降低延时),成本也在不断下降,但是这依旧跟不上数据量的爆炸式增长。SSD自身的特性决定了其容量不仅会影响成本,也会影响性能。

对于空间复用(这里指删除旧数据之后,在腾出的空间中写入新数据),SSD并不能像内存和传统机械硬盘那样直接覆盖旧数据。在SSD的使用场景中,当上层应用删除了某些数据之后,向旧数据占用的空间写入新的数据时,SSD内部需要先对旧数据占用的闪存块执行擦除操作,之后再在“干净”的闪存页中写入新数据。

在执行擦除操作的闪存块中,如果全部是旧数据(无效数据),则可以直接执行擦除操作,但在真实的应用场景中同一个闪存块内除了旧数据之外,也有可能存在正常文件的数据(有效数据),这个时候并不能直接擦除。在执行擦除操作之前,必须将这些有效数据搬移到其他空闲的闪存块中,然后才能执行擦除操作,这个过程叫垃圾回收。在这个过程中可能会产生写放大(Write Amplif ication)。

一旦SSD剩余空间显著变少,且出现大量数据碎片时,可能会频繁地触发垃圾回收,这个过程会产生严重的写放大。严重的写放大会严重影响SSD性能(如人们会显著感知I/O延时变大、IOPS降低)。对于SSD内部的I/O延时(非应用感知的I/O延时),单个擦除操作的延时是写操作延时的几倍,而写操作的延时又是读操作延时的几十倍。在混合读写的场景中,垃圾回收会引发延时抖动,进而影响应用性能。

为降低垃圾回收的频率,SSD不仅会优化垃圾回收的算法,还会预留一部分空间(预留空间通常称为OP空间,即Over Provision)专门用于腾挪垃圾回收过程中的数据。企业级SSD通常将OP设置为28%,消费级SSD通常将OP设置为7%。SSD内部空闲的空间越多,写放大系数就越小,而写放大系数减小可显著提升SSD的性能并降低I/O延时。

对数据进行压缩,可在不改变应用架构的前提下立竿见影地增加SSD内部空闲空间,这不仅能节省空间,更能优化性能。

目前业界提供了丰富多样的成熟算法,比如zstd、zlib、brotli、quicklz、lzo1x、lz4、lzf、snappy等。基于这些压缩算法,现行的解决方案可简单归纳成软压缩(即消耗主机CPU的方案)和硬压缩(这里指可计算存储压缩方案)两种。为便于大家理解两者的区别,接下来我们对这两种解决方案进行介绍。

软压缩方案(架构如图3-4所示)的压缩和解压能力完全由CPU提供算力。本质上以牺牲CPU资源来换取存储空间,因此该方案存在如下几个突出的问题。

CPU抢占 :会占用大量CPU资源,同时也会跟应用抢占CPU资源。

图3-4 软压缩方案架构示意图

数据复制导致的带宽抢占 :在 主存和 CPU 之间频繁引入大量 的数据复制(DRAM<-->三级缓存<-->二级缓存<-->一级缓存<-->寄存器),抢占服务器PCIe带宽和内存带宽,同时带来潜在的CPU缓存未命中问题,进一步影响计算效率。

延时不稳定 :因为CPU抢占和带宽抢占,当操作系统负载较高时,操作系统中的时钟中断和任务调度会增加延时的不确定性,这是I/O密集型业务很难忍受的。

硬压缩方案(架构如图3-5所示)能够很好地解决软压缩方案中的突出问题。

CPU负荷卸载 :采用内置的专有芯片完成压缩和解压缩计算,实现CPU负荷卸载。专有芯片在低延时上具备天然的优势,非常适合计算密集型任务(比如矩阵运算、压缩和非对称加密)。专有芯片通过片上集成缓存和DRAM接口来减少与CPU的交互,这可使操作系统的进程调度和进程间不互相干扰,从而提供可预测的延时。同时,专有芯片是基于定制流水线MIMD设计的,同时拥有流水线并行和数据并行特性,这可进一步降低延时。

零复制 :内置专有芯片进行压缩和解压缩时,不会改变原有的数据路径,完全在盘内进行压缩和解压缩任务,这在避免额外的数据复制的同时,也大大降低了I/O的延时。这也是可计算存储又称近存储计算的原因。

可线性扩展 :每个可计算存储设备都内置了压缩/解压缩引擎,在扩充存储容量的同时也能够线性扩展压缩/解压缩能力。

图3-5 硬压缩方案(透明压缩)架构示意图

采用CSD 2000硬压缩方案,应用对数据压缩与解压缩的整个过程是毫无感知的,相比使用普通NVMe SSD的应用,使用CSD 2000的应用在数据的读和写操作上没有任何区别。当应用写数据时,数据在写入盘之前保持着未压缩状态,当数据写入盘之后,通过盘内置的压缩引擎,结合内置的专有芯片进行压缩,完成压缩之后再写入NAND闪存颗粒进行持久化;当应用读数据时,先从NAND闪存颗粒读出数据,然后通过内置的解压引擎,结合内置的专有芯片进行解压,完成解压之后再返回给上层应用。

4.计算下推

利用可计算存储实现数据库查询过滤的探索。

通过上文提到的压缩技术,虽然能够大幅缓解存储产能不足的问题,但实际存储介质的容量和数据量增速的剪刀差会越来越明显,这就不得不探索更多可以降低存储负载压力的新技术,以便更好地为应用提速。

下面先简单罗列目前的硬件技术能够提供的数据传输速率。假设读取1PB数据,仅考虑数据从存储介质传输到主存(DRAM),PCIe 3.0、PCIe 4.0和PCIe 5.0分别耗时多久?如果数据存放在存储阵列上,使用100Gb/s存储网络,耗时多久?具体如图3-6所示。

图3-6 100Gb/s存储网络以及PCIe 3.0/4.0/5.0分别读取1PB数据的耗时

在现代处理器系统中,CPU高速缓存处于内存系统的顶端,其下是主存(DRAM)和存储介质。CPU高速缓存通常由多级组成(L1、L2和L3)。基于时间的局部性,CPU数据读取时将访问各级缓存直至到达主存(DRAM)。如果需要访问的数据在CPU高速缓存中被命中,将不会访问主存(DRAM),这样可以缩短访问延时。访问流程如图3-7所示。

图3-7 数据访问流程示意图

在联机分析(OLAP)场景中,如果同一作业的运行频率低,不同作业之间数据的关联度也低,那么现有缓存体系将极为低效甚至失效,比如热数据被换出引发缓存未命中,会导致应用性能急剧下降。在数据库领域对此有不同的解决思路,以Oracle为例。

缩短数据量的移动路径 :数据库默认总是先将数据读取到自己维护的高速缓冲,Oracle 11g开始采用直接路径来扫描大表读取数据(默认为2%×缓冲器高速缓存),从而绕开缓冲器高速缓存,避免热数据被换出引发缓存命中率下降。

减少移动的数据量 :Oracle Exadata Smart Scan特性能可将大部分SQL操作下推(又叫卸载)到存储节点,从而极大地减少了存储节点和数据库节点之间传输的数据量。

那么,如果要在数据库中使用计算下推,可计算存储如何与之结合呢?为方便大家理解,这里以MySQL特性Index Condition Pushdown(指数前提下推,简称ICP)为例,对数据库中使用计算下推的基本原理进行简单介绍。

1)关闭ICP时的查询执行路径 :未启用ICP特性时,会按照第一个索引条件列到存储引擎查找数据,并把整行数据提取到数据库实例层,数据库实例层再根据Where后其他的条件过滤数据行,如图3-8所示。

2)启用ICP时的查询执行路径 :启用ICP特性后,如果Where条件中同时包含检索列和过滤列,且在这些列上创建了一个多列索引,那么数据库实例层会把这些过滤列同时下推到存储引擎层。在存储引擎层过滤掉不满足条件的数据,只读取并返回需要的数据,这样可减少存储引擎层和数据库实例层之间的数据传输量和回表请求量,通常情况下可以大幅提升查询效率。过程示意如图3-9所示。

图3-8 关闭ICP时的查询执行路径示意图

图3-9 启用ICP时的查询执行路径示意图

3)数据库中使用计算下推 :MySQL ICP虽然将MySQL服务器层的过滤下推到存储引擎层,但仍需要消耗CPU资源。严格来说,这不是真正意义的下推。如果要更进一步,可以考虑将图3-10中所示第4步下推到可计算存储设备,理由如下。

收益大 :关键步骤,由它完成实例层向存储引擎层的下推,符合“近”存储计算原则,实现后收益较大。

成本低 :从调用关系看,它对数据库实例层影响很小,绝大部分改动可在存储引擎层完成,修改和验证成本较低。

更友好 :易于并行,对计算密集任务友好(比如压缩、加密、计算、过滤和聚合)。

图3-10 在数据库中使用计算下推的执行路径示意图

要在数据库中使用计算下推,通常需要和应用紧密结合。应用须告知可计算存储需要查询的数据有哪些(应用生成包含查询语句的查询条件,以及涉及的与查询列对应的LBA和Offset下推信息),然后调用计算API将下推信息发给可计算存储设备,可计算存储设备仅读取并返回满足应用查询条件的数据(可计算存储设备收到计算API发来的下推信息后,利用盘内自带的专有芯片进行解析并执行,仅读取并返回满足应用查询条件的数据,不满足查询条件的数据不会被读取)。

3.1.3 可计算存储的成功案例

上文花了很大篇幅讲解可计算存储,那可计算存储实际的应用表现如何呢?

利用FIO(直接压测裸设备)和Sysbench(压测MySQL)等基准测试工具,对可计算存储(以CSD TLC SSD为例)与普通NVMe SSD在同等场景下进行对比测试,结果表明,在应用数据具有较高压缩率的场景中,可计算存储不但能够节省存储空间,还能够大幅提升应用的性能,甚至能够大幅提升SSD设备的使用寿命。

1)如图3-11所示,在数据具有2:1以上压缩率时(意味着能够节省50%以上的存储空间),CSD TLC SSD在透明压缩/解压缩引擎的加持下,与同级别的普通TLC SSD相比,CSD的FIO的随机写负载性能提高了177%以上,FIO的随机读写混合负载性能提高了98%以上。

图3-11 CSD TLC SSD与普通TLC SSD的FIO性能对比

2)如图3-12所示,在Sysbench For MySQL的基准测试中(样本数据压缩率2.96:1)与同级别的普通TLC SSD相比,CSD TLC SSD在Sysbench的多种事务模型、不同并发线程的大部分负载场景中性能都远高于普通TLC SSD。随着并发线程的逐步增加,CSD TLC SSD的性能优势会更加明显。在透明压缩引擎与盘内原子写特性(CSD TLC SSD内置的特性,启用原子写时可关闭MySQL的双写缓冲功能)的加持下,CSD TLC SSD的性能可提升300%以上。

图3-12 CSD TLC SSD与普通TLC SSD的Sysbench For MySQL性能对比

3)数据压缩之后,可计算存储能够大幅减少写入SSD的数据量。与普通TLC SSD相比,同等业务负载下相当于增加了SSD内部的空闲空间,更多的空闲空间能够有效降低写放大系数。写放大系数的降低除了能够带来显而易见的性能提升之外,还能够提升SSD设备的使用寿命。数据的可压性越高,对提升SSD设备的使用寿命帮助就越大。

目前,CSD TLC SSD产品正在与众多的行业头部企业展开广泛的探索与磨合,在对可计算存储应用场景的探索与落地上也取得了一些成就。

❑ 在某头部互联网出行公司,几乎所有业务系统中的MySQL数据库应用都已大量上线可计算存储。

❑ 在南方某头部电商公司,也在多个业务系统的MySQL数据库应用中大量上线可计算存储。

❑ 与国内某第一、第二云厂商也正在展开广泛的探索、磨合,相信可计算存储在不久的将来也能够在这些企业中得到大规模应用。

3.1.4 可计算存储的前景展望

随着半导体工艺技术发展步伐的放缓,传统的基于CPU的同构计算架构越来越难以支撑计算机系统性能的持续提升。但同时以AI/ML与海量数据分析为代表的各种应用对算机系统性能的需求却在不断加速增长。这一矛盾迫使整个计算产业界从传统的同构计算架构逐步向异构计算体系架构转型,如此自然孕育出可计算存储这一新兴领域。可计算存储产品的商业化目前仍然处于开拓、探索的阶段。为了迈出商业成功的第一步,可计算存储产品必须同时满足如下3个条件。

❑ 能够无缝嵌入现有软、硬件系统生态环境内,用户应用程序无须做任何改动。

❑ 所提供的计算服务必须具有足够的通用性,并能带来显著的应用价值。

❑ 必须提供与通用存储器(如NVMe SSD)相当的数据存储功能和性能。

所以在可预见的将来,可计算存储的发展的主要方向为将透明数据压缩、透明数据加密功能集成到高性能存储控制芯片内,以保证与现有软、硬件系统生态环境实现无缝对接,并与NVMe标准完全兼容。同时,NVMe委员会正在推动NVMe标准的扩充,以使用户可以更好地利用可计算存储器内部的透明压缩能力,以达到降低数据存储成本的目的。目前,ScaleFlux公司已经成功将以透明数据压缩、加密为核心的可计算存储产品投放市场,并且有多家企业正在研发类似产品。

毫无疑问,以透明数据压缩、加密为核心的可计算存储产品将会使可计算存储的商业化实现从零到一的突破。从长期发展的角度来看,可计算存储产品可提供的计算服务远不止透明数据压缩、加密。随着软、硬件系统生态环境逐步提升对可计算存储产品的包容性和适应性,系统会将更多的与海量数据高度耦合的计算任务(如查询、过滤、数据预处理等)直接下推至可计算存储器内,达到进一步提高系统整体计算能力和效率的目的。同时,新兴的Chiplet和3D异构集成技术也会带来崭新的可计算存储器主控芯片设计空间,从而进一步提高可计算存储产品的价值。

虽然任何人都无法准确预测可计算存储产品在接下来的十年、二十年的发展路线和轨迹,但有一点是毋庸置疑的,那就是可计算存储在未来的异构计算体系中必将占据非常重要的地位。也许在数十年之后,所有的数据存储器都将提供多或少的计算功能,届时“可计算存储”就完成了历史使命。 2Gv78e+CGroQDEDeG79ZLc2Dy4sJMpWv5SCs0haAYuF0sRs5scOfsHdoiVYW3Box

点击中间区域
呼出菜单
上一章
目录
下一章
×