前情提要：
本文是《FAST26 云本地存储论文精读》专题系列解读第1篇
阿里云本地存储的技术演进与创新
定位：本文是深度论文精读，适配技术爱好者、存储领域研发、行业研究者，兼顾技术原理、架构迭代与创新价值。需要有一定的存储基础知识。
引言
本地存储（实例存储）是云厂商提供的一种高性价比、近物理性能的块存储服务，但其弹性与可用性一直是软肋。近日，在FAST'26（USENIX Conference on File and Storage Technologies）上，阿里云与上海交通大学、Solidigm联合发表了一篇论文《Here, There and Everywhere: The Past, the Present and the Future of Local Storage in Cloud》，这篇论文首次系统披露了阿里云本地存储从2017年至今的三代架构演进——从软件栈到硬件卸载再到软硬协同，并前瞻性地提出了突破物理架构天花板的混合存储方案。本文将深入解读这篇论文的核心技术思想、设计取舍与实践价值。本文将从本地存储的核心矛盾、三代架构（ESPRESSO、DOPPIO、RISTRETTO）的演进、以及未来的LATTE混合方案的主要脉络，带您深入解读这篇论文的核心内容。
（一）云本地存储的技术背景与核心痛点
在拆解三代架构之前，我们需要理解云本地存储的核心价值与天生短板。
1.云本地存储的核心价值
云本地存储（或称实例存储、临时存储）是指直接物理挂载在计算服务器上的SSD/HDD，通过虚拟化技术以虚拟磁盘（VD）的形式提供给云虚拟机或裸金属实例。它与计算存储分离的弹性块存储（如AWS EBS、阿里云EBS、移动云EBS）最本质的区别在于：数据无需经过网络，I/O路径短，延迟可低至数十微秒，性能几乎等同于物理盘。通过如下表格我们可以直观地比较 物理SSD、云本地存储、EBS云盘之间的差异。
| 指标 | 物理 PCIe Gen4 SSD | 阿里云 RISTRETTO (Local VD) | EBS 高性能云盘 (ESSD) |
|---|---|---|---|
| 4KB 随机读 IOPS (K) | 1000 | 900 | PL3: 1000K ;PL2: 100K ;PL1: 50K |
| 4KB 随机写 IOPS (K) | 180 | 180 | PL3: 1000K ;PL2: 100K ;PL1: 50K |
| 顺序读吞吐量 (GB/s) | 6.941 | 6.740 | PL3: 4 ;PL2: 0.75 ;PL1: 0.35 |
| 顺序写吞吐量 (GB/s) | 4.1 | 4.0 | PL3: 4 ;PL2: 0.75 ;PL1: 0.35 |
| 读延迟 (μs) | 75/15 | 77/17 | 200 |
| 性能定位 | 物理硬件上限 | 接近物理 SSD | 分布式高性能云盘 |
| 架构 | 本地物理介质 | 云原生本地存储 | 分布式块存储 |
| 弹性与可靠性 | 无弹性 | 无弹性、无快照 | 高可靠、支持快照 / 扩容 |
| 成本 | 硬件成本高 | 远低于高性能云盘 | 规格越高价格越贵 |
| 典型场景 | 高性能计算 | CDN、大数据 Shuffle、AI 推理中间结果 | 数据库、核心业务持久化存储 |
| 成本（美元/GB/月） | 约 $0.20 - $0.38 / GB/月 (估算值，基于1TB型号生命周期折算) | 定价不公开，需咨询阿里云 (通常远低于ESSD，接近物理硬件成本) | PL0: $0.08 / GB/月 ;PL1: $0.15/GB/月 ;PL2: $0.31/GB/月 ;PL3: $0.62/GB/月 |
从表格中可以看出 阿里云第三代本地存储RISTRETTO的单VD 4KB随机读IOPS达900K，顺序读吞吐6.7GB/s，读延迟77μs，与物理PCIe Gen4 SSD的差距已微乎其微。正因如此，本地存储成为CDN缓存、大数据Shuffle、AI推理中间结果存储等场景的刚需，且价格远低于同规格的高性能云盘。
2.云本地存储的局限
尽管 RISTRETTO 实现了接近物理设备的性能，并支持灵活的云功能，但其在部分场景中仍存在局限性。
三个无法回避的局限（论文中定义为LDL_1-3）：
- 可用性不足（LDL_1）：本地磁盘的年故障率约为 0.44%，由于其典型应用场景为缓存数据存储（如 CDN），用户通常可容忍数据丢失，但实际中，用户往往会遭遇小时级的服务不可用。原因在于，用户可能部署多块本地固态硬盘，且服务运行依赖所有磁盘正常工作；此时，即便可重新分配搭载固态硬盘的新节点，用户仍需将其余正常磁盘的数据迁移至新节点，产生高昂开销。因此，本地存储用户对磁盘的高可用性需求日益迫切。（本地盘存储与高可用是否相矛盾）
- 弹性不足（LDL_2）：近年来，许多应用场景对存储容量的弹性要求极高（如临时检查点持久化、大语言模型系统的模型参数和键值缓存读取），而本地磁盘的物理共置架构使其扩展能力受限于固态硬盘的实际容量。
- 可访问性受限（LDL_3）：一个易被忽视的问题是，本地存储仅部署在本地存储用户密集的特定区域（拥有超 1000 块磁盘）。这是因为与云磁盘的计算 - 存储解耦架构不同，本地存储的物理共置特性限制了其可访问性，若用户数量不足，极易导致资源利用率低下。
阿里云本地存储的三代演进，就是先解决"如何把硬件性能吃满"的技术矛盾，再尝试突破“物理架构天生短板”的系统矛盾。
核心研究问题：如何最大化发挥 NVMe SSD 性能，同时平衡资源利用率、云特性支持与可用性
论文研究范围：以阿里云为实践样本，梳理三代架构 + 提出 EBSX/LATTE 方案，填补云本地存储 “性能 - 可用 - 成本” 平衡的技术空白。
（二）三代架构迭代：
从软件优化到软硬件协同的技术演进
首先，我们先从全局视图看下这三代架构的差别： 首先，我们先从全局视图看下这三代架构的差别：
| 对比维度 | ESPRESSO（2017 年，第一代） | DOPPIO（2019 年，第二代） | RISTRETTO（2023 年，第三代） |
|---|---|---|---|
| 核心架构（技术底座） | 基于 SPDK 的用户态软件协议栈，内核态迁移至用户态，采用轮询机制 | 基于 ASIC 的硬件卸载架构，将 I/O/ 虚拟化卸载至商用 ASIC-DPU | ASIC+SoC 软硬件协同设计，PCIe 扩展板集成双组件，ASIC 负责加速、SoC 负责灵活功能 |
| 核心硬件依赖 | x86 主机 CPU 核心（专属绑定）、PCIe Gen3 NVMe SSD | ASIC-DPU（单 DPU 管理 2 块 SSD）、PCIe Gen3 NVMe SSD、PCIe Gen3 总线 | 定制化 ASIC+4 核 ARM Cortex-A72 SoC（64GB DRAM）、PCIe Gen4 NVMe SSD、32 条 PCIe Gen4 总线 |
| 主机 CPU 占用 | 依赖，需专属绑定 CPU 核心（12 块 SSD 需 6 核），无法释放 | 无依赖，I/O 处理完全卸载至 DPU，主机 CPU 零占用 | 无依赖，全 I/O 栈卸载至 ASIC+SoC，主机 CPU 零占用 |
| 裸金属实例支持 | ❌ 不支持（占用主机核心，无法提供完整物理资源） | ✅ 支持（硬件卸载，主机资源完全开放） | ✅ 支持（软硬件卸载，主机资源无损耗） |
| 核心性能表现（单服务器 12 块 Gen3 SSD） | 最大 38.4GB/s 吞吐量、5760K IOPS；单 VD 572K IOPS | 最大 38.4GB/s 吞吐量、6000K IOPS；单 VD 661K IOPS | 8 块 Gen4 SSD：48GB/s 吞吐量、7200K IOPS；单 VD 949K IOPS（Gen4） |
| CPU 利用率 | 低，99 百分位实际利用率约 60%，核心专属绑定无复用 | 无主机 CPU 消耗，ASIC-DPU 自身处理能力有限 | SoC 单核效率提升超 50%，8 块 SSD 仅需 4 个 ARM 核心，资源利用率最优 |
| 云功能支持能力 | ✅ 基础支持（软件栈灵活，可扩展 LVM/RAID）（基于 SPDK 开源框架，易定制） | ❌ 弱支持（ASIC 硬件逻辑固化，无法适配 LVM/ZNS 等新兴功能） | ✅ 全量灵活支持（SoC 块抽象层实现 LVM/RAID/FTL/ZNS 适配，兼容新型硬件） |
| 存储设备演进适配 | ✅ 软件栈易适配，但受主机 CPU 性能限制 | ❌ 适配差，ASIC 迭代周期长，跟不上 SSD 性能升级（如 Gen4 SSD） | ✅ 深度适配，ASIC 重构支持高并行执行，可充分发挥 Gen4/Gen5 SSD 性能 |
| 上下文切换优化 | ⚡ 部分优化，解决内核态高频切换，仍存在 VM 与主机的软件中断切换 | ⚡ 大幅优化，硬件中断（MSI）替代软件中断，基本消除切换开销 | ⚡ 完全优化，ASIC 直驱 VM 硬件中断，结合轮询机制，无额外切换开销 |
| 核心优势 | 1. 基于开源 SPDK，开发成本低、社区支持丰富；2. 相比内核栈，软件开销降低 82.35%；3. 性能远超传统 HDD 内核架构 | 1. 主机 CPU 零占用，释放计算资源；2. 支持裸金属实例，适配高性能业务；3. 硬件中断降低延迟，性能接近物理设备 | 1. 兼顾高性能（ASIC 加速）与灵活性（SoC 软件）；2. 支持 Gen4 SSD 及 ZNS 等新型硬件；3. 裸金属 + 云功能双支持，资源利用率最优；4. 接近物理设备的极致性能 |
| 核心局限性 | 1. 不支持裸金属实例；2. 主机 CPU 利用率低、资源浪费；3. 仍存在软件上下文切换，高队列深度下性能衰减 | 1. ASIC 处理能力有限，无法适配高性能 SSD；2. 硬件逻辑固化，云功能扩展困难；3. PCIe Gen3 总线限制吞吐量提升 | 1. 仍存在本地存储固有缺陷（可用性 / 弹性 / 可访问性不足）；2. 定制化 ASIC+SoC，硬件研发成本高于前两代 |
| 部署规模 | 数万台物理服务器 | 数千个节点 | 数千个节点（2023 年上线后快速扩展） |
| 核心设计目标 | 解决内核态协议栈在 NVMe SSD 上的性能瓶颈，实现用户态高性能 I/O | 解决 ESPRESSO 的主机 CPU 占用问题，实现硬件卸载与裸金属支持 | 解决 DOPPIO 的灵活性不足 + ESPRESSO 的性能上限问题，实现性能 + 功能双优 |
第一代 ESPRESSO：用SPDK把性能从内核中“解放”出来
核心矛盾：NVMe SSD性能飙升（2017年PCIe Gen3 SSD已达500K IOPS），但传统内核存储栈成为瓶颈。论文实测显示，内核栈方案最多只能发挥NVMe SSD9.54%的IOPS能力，CPU占用却高达140%。
阿里云最初的本地存储协议栈基于机械硬盘设计，采用基于 KVM 的半虚拟化技术 Virtio，实现虚拟机中虚拟磁盘与主机操作系统内核存储协议栈之间的 I/O 传输。虚拟机可挂载由单块或多块机械硬盘（分区）提供支持的虚拟磁盘，其控制流 / 数据流及详细流程 如图 2 (a) 所示。该协议栈在机械硬盘上表现良好，但在 NVMe 固态硬盘上无法提供满意的性能。原因在于NVMe 固态硬盘的性能远超机械硬盘，IOPS 提升数个数量级且延迟大幅降低，这会触发频繁且耗时的上下文切换，进而导致严重的 CPU 竞争和同步开销。图 2 (a) 中存在三类由以下操作引发的上下文切换：虚拟机退出（步骤 1、7）、系统调用（步骤 3、6）和中断（步骤 5）。
图2（a）虚拟机向虚拟磁盘（/dev/vda）发起写请求：
1.客户操作系统通过 Virtio 驱动操作虚拟 I/O 队列，与主机内核中的 KVM 模块交互；
2.KVM 模块激活虚拟机监控程序，解析 Virtio 请求，再通过内核协议栈向底层磁盘发起 I/O 请求；
3.机械硬盘向数据缓冲区执行直接内存访问（DMA）写操作；
4.写操作完成后，磁盘产生中断通知主机内核，内核将 I/O 完成信息返回至虚拟机监控程序；
5.虚拟机监控程序调用 KVM 模块，向客户操作系统产生中断，告知 I/O 操作完成。读操作流程与之类似。
核心设计：
ESPRESSO的核心思路是把I/O处理栈从内核搬到用户态，基于SPDK（存储性能开发套件）实现： ESPRESSO 最核心的改进是基于存储性能开发工具包（SPDK）将协议栈从内核态迁移至用户态。 轮询替代中断：用户态进程通过轮询主动获取I/O请求，彻底避免高IOPS下的频繁上下文切换。 CPU核心绑定：每个I/O线程绑定专属CPU核心，采用无共享数据结构，消除锁竞争。 成熟开源生态：基于SPDK快速构建，社区支持丰富。
图2（b）虚拟机向虚拟磁盘（/dev/vda）发起写请求：
1.vhost-user 进程主动轮询来自客户操作系统虚拟 I/O 队列的入站 I/O 请求；
2.vhost 通过用户态协议栈将新的 I/O 请求转发至底层固态硬盘；
3.固态硬盘向数据缓冲区执行直接内存访问（DMA）写操作；
4.同时，vhost-user 持续主动轮询固态硬盘的 I/O 完成状态；
5.最后，vhost-user 与 KVM 模块交互，向客户操作系统产生中断，告知 I/O 操作完成。 成果：
2017年上线后，ESPRESSO部署规模达数万台。单机（12块PCIe Gen3 SSD）实现38.4GB/s吞吐、576万IOPS，软件开销较HDD栈降低82.35%。
局限（SWL_1-3）：
不支持裸金属：需占用主机CPU核心（12块SSD需6核），无法将全部物理核心租给用户。
CPU利用率低：专属核心的99分位实际利用率不足60%，且无法用于其他任务。
仍有上下文切换：I/O完成需通过eventfd通知虚拟机，引入5-12μs额外延迟。
第二代 DOPPIO：ASIC DPU硬件卸载，让主机CPU“零参与”
核心矛盾：ESPRESSO虽释放了SSD性能，但占用了宝贵的主机CPU资源，且CPU利用率低下。
核心设计：
DOPPIO的核心思路是将整个I/O栈卸载到ASIC-based DPU：
每个ASIC DPU管理2块NVMe SSD，通过SR-IOV将物理盘以PCIe直通方式挂载给虚拟机。
I/O请求由DPU硬件处理，使用DMA和硬件MSI中断，全程无需主机CPU参与。
成果：
2019年上线后，DOPPIO部署数千节点。同12块SSD配置下，性能略高于ESPRESSO（600万IOPS），且实现裸金属友好，并为虚拟机多释放6个vCPU。
局限：“敏捷性”的缺失
- 性能敏捷性的缺失-跟不上SSD演进：ASIC迭代周期长，而SSD性能两年翻一番（从2017年500K到2023年1.5M IOPS）。DOPPIO的DPU最多只能发挥Gen4 SSD 130万IOPS，无法跑满新盘性能。无法与时俱进地吸收最新的硬件红利。
- 功能敏捷性的缺失-云特性支持困难：ASIC功能固化，难以灵活支持逻辑卷管理（LVM）、ZNS等新特性。无法灵活地响应技术和市场的快速变化。虽然FPGA能缓解灵活性问题，但功耗和资本支出（CapEx）会大幅上升，完全不适合公有云的大规模落地。
补充说明：
1.跟不上SSD演进：好比“买了法拉利，但只让开80码”
投资浪费：当用户为服务器插上2023年最新的、标称150万IOPS的高速SSD时，通过DOPPIO访问，实际体验到的速度被“锁死”在了130万IOPS。对于追求极致性能的用户（如实时数仓、高频交易），他们为最新硬件支付的溢价，无法转化为实际的业务处理速度。
产品代际脱节：云厂商推出新机型的速度会被DPU的迭代周期拖累。当SSD已经进入Gen4甚至Gen5时代，DOPPIO可能还只能充分发挥Gen3盘的性能，导致新产品发布延迟，或在竞争中处于劣势。
规格复杂化：为了“适配”DPU的能力，云厂商可能不得不推出各种“降频版”的本地盘规格，比如“基于Gen4 SSD但性能上限为Gen3水准”，这会让产品选型变得复杂，用户体验下降。
云特性支持困难：好比“买了一台无法安装新App的智能手机”- 创新滞后：ASIC的逻辑在芯片制造时就已经用电路“写死”了。当行业推出ZNS SSD时：由于DOPPIO的ASIC逻辑不支持ZNS所需的命令集和交互方式，它根本无法识别和管理这种新盘。
用户需求无法满足：当用户需要LVM功能时，在DOPPIO的方案里，盘是ASIC通过SR-IOV直接透传给虚拟机的，中间没有软件层来执行LVM的逻辑。这就好比你想给手机扩容，但手机硬件不支持插SD卡，系统也不支持文件管理，你完全无能为力。
生态封闭：ASIC方案更像一个“黑盒子”，第三方开发者很难为其开发新的功能或驱动，形成了一个封闭的生态，不利于社区的共同创新。
对于追求长期发展、需要不断推陈出新的云厂商来说，这种“敏捷性”的缺失，最终会导致产品竞争力下降、用户流失。这也正是为什么阿里云要放弃纯ASIC路线，转向RISTRETTO的ASIC+SoC协同设计——用SoC的可编程性来补足ASIC固化的短板，从而同时获得高性能和高灵活性。
第三代 RISTRETTO：ASIC+SoC 的软硬件协同设计
核心矛盾：ESPRESSO灵活但占CPU，DOPPIO卸载但固化。能否两全其美？
核心设计：
RISTRETTO的答案是软硬协同，各司其职。它是一块定制PCIe卡，内部集成两大模块：
ASIC模块：负责性能敏感的数据面，包括NVMe控制器模拟、DMA引擎、硬件中断注入。支持超1000个VF，实现I/O路径硬件加速。
ARM SoC模块（4核Cortex-A72+64GB DRAM）：运行基于SPDK的Runtime软件栈，提供可编程的块抽象层（BDEV），灵活实现LVM、RAID、FTL等云特性。
关键数据流：虚拟机I/O → ASIC解析 → 通过虚拟队列转SoC处理云特性 → ASIC封装后下发给SSD → 完成后ASIC直接向虚拟机注入硬件中断。全程不经过主机CPU和内存。
如论文的Figure 8所示，整体分层结构从下到上分别为：
| 层级 / 模块 | 核心组件 | 功能与职责 |
|---|---|---|
| 底层硬件层 | NVMe SSDs | 提供物理存储介质，执行实际的读写操作 |
| ASIC 驱动层 | ASIC-based SSD Driver | 作为与物理 SSD 交互的核心驱动，负责将上层请求转换为 NVMe 协议操作 |
| PRP/SGL Constructor | 将 SoC 层的块请求重新构造成 NVMe 协议要求的 PRP/SGL 格式 | |
| NVMe QPairs | 管理与物理 SSD 通信的 NVMe 队列对，用于提交命令和接收完成通知 | |
| DMA Control | 控制与物理 SSD 之间的 DMA 数据传输，实现高效、零拷贝的数据搬运 | |
| SoC 抽象层 | Block Abstraction Layer | 提供块设备抽象，实现逻辑卷管理（LVM）、闪存转换层（FTL）、缓存（Cache）等高级存储服务 |
| （中间层角色） | 连接上层虚拟化与下层物理驱动，负责将虚拟 I/O 请求转换为对物理块设备的操作 | |
| ASIC 虚拟化后端（Ristretto） | Ristretto | 运行在 DPU/ASIC 上的虚拟化层，是整个存储虚拟化的核心 |
| SR-IOV | 实现 SR-IOV 规范，将物理存储资源虚拟化为多个虚拟功能（VF），使每个 VM 独占一个 VF | |
| NVMe Controller | ASIC 上的硬件 NVMe 控制器，直接处理来自 VM 的 NVMe 命令 | |
| Doorbell Monitor | 监控 VM 的门铃（Doorbell），及时发现并处理新的 I/O 命令 | |
| PRP/SGL Parser | 解析 NVMe 命令中的物理区域页（PRP）或散列表（SGL），获取数据地址 | |
| DMA Control | 控制 DMA 操作，实现数据零拷贝传输，提升 I/O 性能 | |
| VQ（Virtual Queue） | 虚拟队列，用于与 SoC 层异步通信，高效传递 I/O 请求和完成状态 | |
| Guest 层 | VM | 运行应用程序，通过虚拟 NVMe 设备（nvme 0 到 nvme N）访问存储资源 |
| NVMe Driver | 虚拟机内的标准 NVMe 驱动，与虚拟设备交互，生成并提交 NVMe 命令 |
成果：
2023年上线，已部署数千节点。单实例（8块PCIe Gen4 SSD）实现53GB/s总吞吐、738万总IOPS，单VD IOPS达94.9万（较DOPPIO提升80%），性能无限接近物理盘。管理8块SSD仅需4个ARM核心，硬件效率远超前两代。
局限（LDL_1-3）：
可用性、弹性、可访问性受限。
- 可用性不足（LDL_1）：本地磁盘的年故障率约为 0.44%，由于其典型应用场景为缓存数据存储（如 CDN），用户通常可容忍数据丢失，但实际中，用户往往会遭遇小时级的服务不可用。原因在于，用户可能部署多块本地固态硬盘，且服务运行依赖所有磁盘正常工作；此时，即便可重新分配搭载固态硬盘的新节点，用户仍需将其余正常磁盘的数据迁移至新节点，产生高昂开销。因此，本地存储用户对磁盘的高可用性需求日益迫切。
- 弹性不足（LDL_2）：近年来，许多应用场景对存储容量的弹性要求极高（如临时检查点持久化、大语言模型系统的模型参数和键值缓存读取），而本地磁盘的物理共置架构使其扩展能力受限于固态硬盘的实际容量。
- 可访问性受限（LDL_3）：一个易被忽视的问题是，本地存储仅部署在本地存储用户密集的特定区域（拥有超 1000 块磁盘）。这是因为与云磁盘的计算 - 存储解耦架构不同，本地存储的物理共置特性限制了其可访问性，若用户数量不足，极易导致资源利用率低下。
补充说明： 共置架构：把硬盘和CPU放在同一台物理服务器里 优点：
性能极致：数据不用经过网络，I/O路径极短，延迟能低到几十微秒，吞吐和IOPS几乎就是物理盘的极限。
成本可控：省去了复杂的网络和分布式存储软件开销，所以价格比同规格的高性能云盘便宜得多（论文里提到EBSX价格是本地盘的20倍）。
缺点：
弹性差：你买了多大容量的盘，就只能用多大，没法像云盘那样随时扩缩容。因为物理盘就在那里，拆不下来。
可用性弱：一旦那块硬盘坏了，数据就丢了（除非应用自己做冗余），而且修复需要换整台机器，恢复时间很长。
部署受限：因为需要大量用户聚集在同一区域才能摊薄成本，所以并非所有地域都提供本地盘服务。
这也引出了论文最核心的前瞻思考：本地存储的未来，能否与云盘融合？
三代架构核心对比：技术选型与设计权衡
核心维度对比：技术路线、性能、资源利用率、云特性支持、部署成本；
| 对比维度 | ESPRESSO（第一代） | DOPPIO（第二代） | RISTRETTO（第三代） |
|---|---|---|---|
| 技术路线选型（核心权衡） | 纯软件优化（SPDK 用户态栈）▷ 权衡：轻研发、易落地，放弃对主机 CPU 的完全解耦 | 纯硬件卸载（商用 ASIC-DPU）▷ 权衡：解耦主机 CPU、提性能，放弃软件层功能灵活性 | 软硬件协同设计（定制 ASIC+ARM SoC）▷ 权衡：前置定制研发成本，实现性能与功能的双重兼顾 |
| 性能设计权衡 | 内核态→用户态迁移降软件开销▷ 权衡：释放 Gen3 SSD 性能，高队列深度仍因软中断有性能衰减 | 硬件卸载 + 硬件中断消切换开销▷ 权衡：性能逼近物理设备，受 ASIC 算力限制无法适配新一代 SSD | ASIC 高并行 + 协议栈全卸载▷ 权衡：充分发挥 Gen4/5 SSD 性能，全队列深度无衰减，需定制化硬件设计 |
| 资源利用率选型（核心权衡） | 主机 x86 核心专属绑定保障 I/O 稳定性▷ 权衡：简化调度逻辑，牺牲 CPU 利用率（99 分位仅 60%），资源易浪费 | I/O 全卸载至 ASIC-DPU释放主机 CPU▷ 权衡：主机资源零消耗，ASIC 自身算力有限、硬件调度灵活性低 | ARM SoC 轻量核心 + 功能解耦▷ 权衡：主机零占用，单核效率提升 50%+，需适配 ARM 架构软件栈 |
| 云特性支持选型（核心权衡） | 选基于开源 SPDK 扩展▷ 权衡：低成本实现基础云功能（LVM/RAID），功能扩展受主机 CPU 性能制约 | ASIC 固化硬件逻辑做基础处理▷ 权衡：提升硬件处理效率，完全丧失新兴云特性（ZNS/FTL）扩展能力 | SoC 软件层块抽象层做功能承载▷ 权衡：支持全量云特性灵活扩展，需在 SoC 端做软件栈开发与优化 |
| 部署成本选型（核心权衡） | 开源框架 + 通用 x86 硬件▷ 权衡：研发 / 部署成本低，长期因主机 CPU 消耗推高运营成本 | 选商用 ASIC-DPU + 通用 SSD▷ 权衡：单台硬件成本低，ASIC 迭代慢导致 SSD 升级 / 功能扩展成本极高 | 选定制化软硬件协同架构▷ 权衡：前期研发成本偏高，软硬件解耦让后续运营 / 升级 / 扩展成本最优，适配规模化部署 |
迭代逻辑总结：从 “软件减开销” 到 “硬件卸负载” 再到 “软硬件协同提性能 + 扩能力”。
选型思路：第一阶段-低成本开发快速实现、暂时忽略资源浪费推高运营成本；第二阶段-提升性能与资源利用率，快速推广占领市场并降低运营成本；第三阶段：逐步补齐全量云特性扩展支持。
（三）核心创新：LATTE——本地盘与云盘的融合
云本地存储的三大固有局限：LDL1（可用性弱）、LDL2（弹性差）、LDL3（可访问性受限）；
高性能云盘方案 EBSX：基于 PMem+100Gbps 网络的 EBS 升级，30µs 延迟、1M IOPS，高可用但成本高（20 倍于 RISTRETTO）；
既然本地盘有物理天花板，高性能云盘（如阿里云EBSX）虽能提供30μs延迟、1M IOPS，但价格是本地盘的20倍（4TB容量规格下），其高可靠性对缓存类场景又属“性能过剩”（EBSX的架构是什么样的，它为什么是高可靠的）。论文提出的LATTE混合架构，试图在性能、成本、可用性间找到最优平衡。
选型过程：
1.为什么没有选已有的分层 / 混合存储方案？
-
Ziggurat：它需要修改内核文件系统层的逻辑来实现分级。而阿里云从第一代ESPRESSO开始，就已经彻底转向了用户态SPDK协议栈，以规避内核瓶颈。如果再为了Ziggurat改回内核，无异于开倒车，会重新引入上下文切换等性能问题。
-
NOVA：针对PMem的文件系统，主要面向持久化内存（PMem）和非易失性内存的混合架构，与阿里云基于NVMe SSD和EBS的块存储生态不完全匹配。
-
Flashield：基于 Memcached 构建，是为键值（KV）缓存设计的，其核心是管理内存和闪存之间的对象。而阿里云的本地存储需要处理的是传统的块I/O（Block I/O）请求（如EXT4、XFS文件系统发来的读写）。如果强行适配，等于要在块存储协议栈上再搭建一个KV转换层，不仅性能损耗巨大，而且无法保证与现有虚拟化生态（如Virtio）的兼容性。
2.为什么选择CSAL？
CSAL原本的设计是：用高性能傲腾（Optane）做写缓存，吸收所有写入，然后以固定大块（Chunk）的方式顺序追加到底层的QLC SSD上。这个设计恰好为LATTE提供了完美的起点：
-
架构同源，都在SPDK用户态
-
- CSAL本身就是阿里云和Solidigm基于SPDK开发的。这与阿里云本地存储的整个技术栈（ESPRESSO、RISTRETTO都基于SPDK）是同宗同源的。选择CSAL，意味着LATTE可以无缝接入现有的用户态I/O路径，无需引入任何内核模块。
-
核心机制高度契合：日志结构（Log-structured）
-
- CSAL的核心是“先写缓存，再顺序追加到后端”，这是一种典型的日志结构（LSM）思想。
- 这对LATTE至关重要，因为它天然解决了混合存储中最棘手的“顺序一致性”问题。所有写入在缓存层先排好队，再一起刷到后端，保证了写操作的顺序不乱序。这正是论文中提到的“避免了传统写回模式的数据不一致问题”。
- 缓存层可以“偷梁换柱”
-
- 原来CSAL的缓存层是傲腾（Optane），这是一种价格昂贵的持久化内存。而LATTE的构想是，既然阿里云已经有了性能无敌的RISTRETTO本地盘，为什么不用它来替代傲腾呢？
-
- 这样一换，缓存层从“昂贵的小块PMem”变成了“相对便宜的大容量本地SSD”，性能和容量都得到了提升，成本反而可能下降。这是LATTE能实现高性价比的关键一步。
| CSAL的原貌 | LATTE的创新 | 解决了什么问题 |
|---|---|---|
| 只有写缓存（所有写都进缓存） | 增加ML智能分发器（判断是写缓存还是写直通） | 避免缓存污染和拥塞，提升整体I/O效率。 |
| 无读缓存准入控制 | 增加S3-FIFO读缓存准入与淘汰 | 解决“one-hit-wonder”问题，将读命中率从可能很低提升到82%-90%。 |
| 需要自己管理GC | 移除日志合并与GC | 后端是EBS，它自己有分布式GC能力，LATTE无需重复造轮子，简化了设计。 |
LATTE的核心设计（基于开源SPDK缓存框架CSAL构建）： 分层架构：前端用RISTRETTO本地盘做高性能缓存，后端用标准经济型EBS做持久化存储。
轻量级ML I/O调度器：基于线性SVM模型，根据I/O大小、队列深度、缓存/后端延迟等特征，基于 Solidigm AppendCache 实时决策“走缓存还是走后端”。推理延迟仅200ns，每60秒自动重训适应负载变化。
S3-FIFO缓存管理：采用三队列FIFO结构，有效过滤“一次命中”的冷数据，实测读命中率超82%，最高达90.23%。
写流程（图 9 (a)）包含写缓存和绕开缓存两种路径：
1.应用发起写 I/O 请求后，首先路由至机器学习调度器模块；
2.对每个 I/O 请求进行推理，指导请求进入写缓存路径或后端路径，该设计可在前端磁盘故障时，自动将请求路由至后端，提升可用性；
3.写 I/O 操作完成后，更新逻辑 - 物理（L2P）地址表，记录数据存储于后端还是缓存，并向虚拟机发送通知；
4.此外，前端会定期聚合写操作并刷写至后端。
读流程（图 9 (b)）采用 S3-FIFO 的三队列结构，将弹性块存储中频繁访问的数据块提升至基于 RISTRETTO 的本地缓存：
1.读请求首先检查逻辑 - 物理（L2P）地址表，确定数据存储位置（前端或后端）；
2.若数据在缓存中，直接返回至虚拟机；若不在，则由准入控制器评估是否应将该数据块提升至缓存；
3.若数据块访问频率较高，在将其返回至虚拟机的同时，插入至缓存；
4.当缓存空间不足触发压缩时，系统评估数据块是否值得保留在缓存中，若无保留价值或已失效，则将其驱逐至后端；
5.无论数据块被提升至缓存还是驱逐至后端，都会及时更新对应的逻辑 - 物理（L2P）映射，确保数据一致性。 需注意的是，LATTE 可保证写操作的顺序性：写缓存和刷写至后端的路径均采用追加写模式，且压缩过程中二者的写顺序保持一致，避免了传统写回策略中无序驱逐和数据不一致的问题。此外，与 CSAL 的数据管理方式一致，逻辑 - 物理（L2P）映射会持续跟踪数据的最新存储位置，确保读一致性。
LATTE的颠覆性价值（已通过PoC验证）：
- 性价比：性能与EBSX持平，价格仅为其 1/5到1/10。自动IOPS弹性模式下，4TB容量价格仅为RISTRETTO的2.1~4倍（EBSX是19倍）。
- 高可用：数据最终持久化在EBS，本地盘故障时业务可无缝切至后端，并支持O_DIRECT写透模式保证一致。
- 弹性与可访问性：容量可借力EBS扩容，且单块SSD可切分给多个LATTE实例，降低部署门槛。
| 方案 | 价格（以RISTRETTO为1） | 成本构成 | 核心能力 |
|---|---|---|---|
| RISTRETTO | 1 | 物理SSD + ASIC/SoC卡 | 极致性能，但可用性、弹性弱 |
| LATTE | 2.1 ~ 4.0 | RISTRETTO成本 + 标准EBS成本 + 智能调度软件 | 性能接近本地盘，兼具高可用与弹性 |
| EBSX | 19 | 高性能硬件 + 三副本/EC + 网络 | 高可用、高弹性、高性能，但价格极高 |
补充说明：
LATTE的成本介于纯本地盘和纯高性能云盘之间。这个2.1~4倍的溢价，主要流向了以下几个地方：
1.后端标准EBS的持久化存储成本：这是最核心的新增成本。在LATTE架构里，RISTRETTO本地盘只负责临时缓存，所有数据的最终归宿是后端的标准EBS。EBS本身是分布式系统，自带多副本冗余和强一致性保障，这部分可靠性的实现是有硬件和软件成本的。虽然标准EBS比论文中提到的“性能版EBSX”便宜得多（后者贵了20倍），但它依然是构成LATTE成本的大头。
2.智能调度与缓存管理的软件开销：LATTE不是简单地把两块盘拼在一起。它包含了轻量级机器学习调度器和S3-FIFO缓存管理逻辑，这些都需要额外的计算和内存资源来运行。虽然论文说开销很小（推理仅200ns），但在大规模部署下，这部分“智力成本”也会体现在最终定价中。
3.弹性IOPS能力的预留成本：这是导致价格在2.1~4倍之间浮动的原因。论文提到，如果用户选择“LATTE Auto”（自动弹性），后端EBS的IOPS是按需分配的，价格就更接近2.1倍。但如果用户要求“LATTE Max”，即始终为其预留最高1M IOPS的后端能力，那么云厂商需要锁定这部分资源，价格自然就涨到接近4倍。
这个定价区间其实很巧妙，它反映了一个成本与收益的平衡点：
相对于RISTRETTO（纯本地盘），LATTE确实更贵，因为它多买了一整套“保险”和“扩展包”——后端EBS提供了数据持久化（解决可用性问题）和弹性扩容能力（解决弹性问题）。
相对于EBSX（纯高性能云盘），LATTE又便宜得多，因为它不用为“用不上的性能”付费。EBSX为了达到30μs延迟和1M IOPS，用了昂贵的持久化内存（PMem）和100Gbps网络，而LATTE大部分读写由本地盘扛住，后端只需接入门级的标准EBS即可。这就像自己带杯子去咖啡店接拿铁，比直接买一杯带精美包装的，省去了包装和服务的溢价。
所以，LATTE的溢价本质上是在为“云的特性”（高可用、弹性）付费，但它用混合架构的精巧设计，绕过了为实现这些特性通常所需的高昂硬件成本，从而把价格控制在一个相对亲民的区间。
（四）实验验证：全维度测试下的技术方案有效性
1.实验环境与测试对象
一台配置Intel Xeon 2.90GHz（64核）CPU、1TB内存的服务器，搭载8块3.84TB PCIe Gen4 NVMe SSD。测试对象包括：
物理盘：企业级NVMe SSD，作为性能上限基准
三代本地盘：ESPRESSO、DOPPIO、RISTRETTO
云盘方案：标准EBS、高性能EBSX、LATTE混合方案
2.微基准测试：聚焦技术性能，验证底层能力极限
微基准测试采用FIO工具，以4KB随机读写和128KB顺序读写为主要负载，重点考察IOPS、延迟、吞吐量三个核心指标。
在4KB随机读测试中，LATTE的表现呈现出明显的“命中率驱动”特征。
在4KB随机读测试中，LATTE的表现呈现出明显的“命中率驱动”特征。
| 指标 | 测试结果 |
|---|---|
| read latency | |
| write latency | |
| IOPS | |
| Throughout | |
| Latte read IOPS and latency（with diff hit rates） | |
| Latte read Throughout and latency（with diff hit rates） |
75%缓存命中率下，实现8.9GB/s顺序读吞吐、7.8GB/s顺序写吞吐，超过EBSX和物理SSD
3.宏基准测试：贴合实际业务，验证场景适配能力
微基准测试的标准化负载无法完全模拟真实业务的 I/O 特征，因此通过宏基准测试将性能验证从 “实验室” 推向 “实际业务场景”，核心采用真实迹回放和MySQL/Sysbench 数据库测试两种方式，验证各方案在实际业务中的性能表现。
- 真实迹回放：采用阿里云三大生产集群的实际 I/O 跟踪数据（社交网络、AI 模型推理、大数据混洗），覆盖 TB 级数据量、2-8 小时的持续负载，模拟真实业务的突发 I/O、热数据分布等特征，验证各方案在实际业务中的延迟控制、缓存命中率等核心指标。
- MySQL/Sysbench 测试：搭建 240GB 的实际数据库环境，测试只读、只写、混合读 - 写三种典型数据库负载下的 QPS（每秒查询数）和请求延迟，验证各方案在企业级核心业务（数据库）中的适配能力，这也是云存储最核心的应用场景之一。
4.资源 / 成本评估：聚焦商业落地，验证规模化部署价值
云存储架构的技术设计最终需服务于商业化部署，因此资源利用率和部署成本是核心评估维度，也是判断架构设计权衡是否合理的关键，实验从 “硬件资源消耗” 和 “资本性支出（CapEx）” 两方面完成评估。
- 资源利用率：主要测试 CPU 核心消耗、单核处理效率（如 ESPRESSO 需 8 个 x86 核心，RISTRETTO 仅需 4 个 ARM 核心）、DPU 等硬件资源的调度效率，验证各架构对计算资源的利用效率，是否存在资源浪费。
- 部署成本：基于各方案的商用标价，以 RISTRETTO 为基准完成标准化对比，涵盖研发成本、硬件成本、运营成本、扩展成本，重点验证 LATTE 的成本优势，以及三代架构迭代的成本效率变化。
总结
纵观阿里云本地存储的三代演进，我们可以清晰地看到一条技术演进路径：
- ESPRESSO（软件栈）：解决“性能释放”——用SPDK突破内核瓶颈。
- DOPPIO（ASIC卸载）：解决“CPU占用”——用硬件卸载实现裸金属友好。
- RISTRETTO（软硬协同）：解决“性能与灵活兼顾”——ASIC扛性能，SoC做功能。
- LATTE（混合架构）：突破“物理天花板”——本地盘与云盘融合，兼得性能、成本、可用性。
这篇论文的价值，不仅在于它首次系统公开了阿里云大规模生产环境的架构实践与取舍，更在于它指明了一个方向：本地存储的未来，或许不再是“物理直连”的单体架构，而是“本地+云端”的智能混合体。这种融合，可能正是云基础设施迈向更高效率与弹性的一步。
