百度沧海·存储 Mantle 系统架构演进之路，SOSP'25 论文背后的故事¶
Ch01.1175 百度沧海·存储 Mantle 系统架构演进之路，SOSP'25 论文背后的故事¶
📊 Level ⭐⭐ | 5.1KB |
entities/百度沧海存储-mantle-系统架构演进之路sosp25-论文背后的故事.md
百度沧海·存储 Mantle 系统架构演进之路，SOSP'25 论文背后的故事¶
来源: 百度Geek说
发布日期: 2026-02-09
原文链接: https://mp.weixin.qq.com/s/WeBt3XgsqbwnbTtciZooDg
。
点击蓝字，关注我们
在技术深水区，最大的障碍往往不是未知，而是那些我们深信不疑的已知。¶
这篇文章 清晰还原了创新的真实路径： 问 题从何而来、传统方案为何失效，以及 Mantle 新的系统设计思路是如何一步步成形的。¶
在技术高度成熟的存储领域，百度沧海·存储团队做了一件极具勇气的事：回归第一性原理，持续地怀疑一切被视为理所当然的假设。¶
他们不再迷信所谓的行业标配，当这些标准开始成为性能负担，他们选择推翻教科书式的最优解 ， 重构系统边界，用跨层协同设计，重新 找回效 率的本质。¶
这不仅是一次技术突围，更是对惯性思维的决裂。它真实呈现了创新是如何发生的：在扩展性与局部性的张力中反复权衡，基于真实负载而非技术教条，做出关键取舍。
正文共计 1 万 5 千余字，建议留出一段完整的时间阅读。
在 AI 与大数据爆发的时代，云存储面临新的挑战：如何在保持对象存储低成本优势的同时，构建出能超越 HDFS 性能的文件系统语义？¶
SOSP'25 上的 Mantle 论文 给出了百度智能云的答案。论文链接：https://dl.acm.org/doi/epdf/10.1145/3731569.3764824¶
本文将讲述那些论文里没写的幕后故事：我们是如何打破惯性思维，在一个成熟的技术领域里走出一条新路的。希望这篇架构演进的复盘，能给业界提供一份有价值的参 考。同时，本文也系统性地补充了 Mantle 的完整设计思想，其中部分关键设计取舍和实现细节，受限于论文篇幅，未能充分展开。¶
1. 背景¶
多年以来，HDFS 一直是大数据存储的代名词。然而，随着数据规模的日益增大，其固有缺陷愈发凸显：首先，三副本机制导致存储成本高昂。其次，传统单 NameNode 架构将文件规模限制在数亿级别，难以满足 AI 时代单桶百亿甚至更大规模的扩展性需求。最后，复杂的运维工作对技术团队提出了极高要求。
在此背景下，具备「低成本、无限扩展、云原生免运维」等优势的对象存储，迅速成为构建新一代数据湖存储底座的共识。然而，随着大量大数据分析、AI 训练等数据驱动的计算业务在对象存储上铺开，新的瓶颈开始出现：在很多场景下，对象存储的性能远弱于 HDFS。
问题的根源在于，大数据计算严重依赖文件系统语义，而传统对象存储采用的「平坦 Namespace」对此支持极其不友好。在这种模式下，系统不具备真正的目录逻辑，而是以对象的全路径作为 Key 进行元数据存储。这导致所有看似简单的目录类操作，都会被放大为成百上千次的底层对象操作，性能急剧下降。具体表现为：
Read dir 效率极低：HDFS ls /logs/ 操作，只需查找 /logs 目录的子节点列表（如 2023/、2024/），瞬间完成。而对象存储没有“目录”概念，ls /logs/ 操作会遍历所有以 /logs/ 为前缀的全路径 Key。这意味着为了找出下面的子目录，系统可能需要扫描数亿个文件（如 /logs/2023/01/01/file.txt……）的索引，造成了巨大的读取放大，效率极其低下。
Move 代价高昂：Move 是大数据计算（尤其是
→ 原文存档
关联¶
- 相关概念: Harness Engineering