百度沧海MetaDB入选NSDI 27：打造EB级云存储元数据底座

近日，百度沧海 · 存储团队联合北京大学、阿姆斯特丹自由大学完成的论文《MetaDB: Putting File-System Structure Back into Distributed Databases》，正式入选计算机系统与网络领域顶级学术会议 NSDI'27 Operational Systems Track。

自 HopsFS（FAST'17）验证该方向可行以来，使用分布式数据库承载文件系统元数据，已逐步发展为行业主流技术路线：底层数据库负责元数据存储，提供一致性、高可用与横向扩展能力；上层 Namespace 服务负责实现文件系统语义，整体架构分层明确、职责清晰。

不过，这条主流路径也伴随着一个长期被忽略的成本：数据库本身并不知道自己保存的是一棵目录树。元数据在数据库中通常被当作普通表和行来处理，文件系统负载中最关键的结构化信息，在进入数据库的那一刻被“抹平”了。

MetaDB 给出的核心答案是：一旦这些结构信息被抹去，数据库就失去了将元数据操作做得更快、更节省资源的依据，只能采用最通用、同时也是代价最高的方式处理每一次请求。把文件系统结构重新还给数据库，节省的正是这部分被通用性消耗掉的系统资源。

MetaDB 让底层数据库真正理解文件系统目录结构与元数据语义，解决了通用分布式数据库在超大规模文件存储场景下性能不足、资源开销偏高的问题。在生产环境中，其在高并发同目录操作下吞吐最高提升 10.7 倍，所需机器数量降至原来的一半以下，为 AI 训练、大数据分析等场景背后的海量数据存储、管理和处理提供了更快、更稳、更省的基础设施底座。

这并不是一个停留在实验室阶段的原型系统。MetaDB（内部原名 TafDB）是百度沧海 · 存储统一的元数据底座，已在百度智能云生产环境中稳定运行超过 5 年，峰值可处理数百万 QPS，管理十万亿级元数据记录，支撑 EB 级存储规模，也是公开系统论文中首个系统性阐述云存储元数据负载如何驱动分布式数据库设计的生产级系统。

据了解，NSDI 长期聚焦网络化系统、分布式系统和云基础设施，是该领域最具影响力的 CCF-A 类顶级会议之一。其中，Operational Systems Track 主要收录那些在真实生产环境中长期运行、经受大规模检验，并能够为行业提供可复用经验的系统成果。百度智能云存储团队这篇论文的核心观点，是把文件系统结构重新放回分布式数据库之中。这也是对近十年来业界主流技术路线的一次重新思考与审视。

三个「看不懂」：通用分布式数据库到底差在哪里？

云存储元数据的负载特征非常鲜明：面向 POSIX 和 HDFS 语义的层级 Namespace，需要在超大规模数据与高并发访问条件下高效维护一棵目录树；而无论是层级 Namespace 还是平坦 Namespace，都要持续面对大量连续批量删除操作。被当作通用黑盒使用的数据库，恰恰错过了这些工作负载中的三类关键信息：

第一，数据库“看不见”目录树。在真实生产负载中，超过 97% 的目录修改操作只涉及单个目录，本来应当在本地就近完成。但通用分布式数据库并不理解目录树的拓扑结构，往往会把同一目录下的数据拆分到不同分片中，导致一次局部操作被放大为跨分片分布式事务；即便数据恰好位于同一分片，也可能依然引入多轮网络交互。

第二，数据库“分不清”元数据主次。一次目录操作中，除了必须严格一致的主元数据，还会同步更新父目录属性、配额统计、二级索引等辅助信息。通用事务模型通常将它们一并纳入同一事务处理：父目录属性因此成为热点，辅助更新又带来额外的跨分片协调，最终让真正关键的执行路径被非关键工作拖慢。

第三，数据库“不了解”元数据生命周期。云存储场景中存在大量连续批量删除，而在通用存储引擎里，被删除的数据通常不会立即消失，而是留下层层“墓碑”标记。随着墓碑持续累积，listdir 这类范围扫描操作会越来越慢：已经删除的数据，依旧在持续拖累在线访问性能。

看不见、分不清、不了解，这三个问题共同指向同一个结论：承载云存储元数据的数据库，必须真正理解目录树结构、元数据语义以及删除生命周期。

MetaDB：让数据库真正「看懂」文件系统

面对这些典型却棘手的“看不懂”问题，MetaDB 选择了一条跨层协同的设计路线：将上层 Namespace 服务掌握的文件系统信息逐层下沉，精准传递给底层分片、事务与存储引擎。通过解析目录树结构，直接指导数据分片与请求执行，确保同一目录下的操作可以本地闭环；依据元数据主次关系进行事务分级，让关键路径摆脱辅助更新的影响；再利用删除操作的生命周期规律优化存储引擎空间回收，彻底减少“墓碑”对扫描性能的长期干扰。

由此，数据库不再只是一个通用黑盒，而是演变为真正理解文件系统语义的元数据底座，为大规模云存储提供可扩展、高性能、低成本的元数据支撑能力。

一篇论文背后，是一套「统一」的元数据新架构体系

MetaDB 也并非一项孤立的研究成果。作为百度沧海 · 存储的统一元数据底座，它通过同一套元数据数据库，向上支撑对象存储的平坦 Namespace，以及两类层级 Namespace：包括并行文件存储所需的 POSIX 语义 Namespace，以及面向数据湖场景的对象存储、百度内部类 HDFS 文件存储 AFS 所需的 HDFS 语义 Namespace。

为什么要通过一套底座实现“统一”支撑？这背后体现的是对长期架构演进的系统性判断。平坦 Namespace 与层级 Namespace（POSIX、HDFS）虽然面向不同产品和访问语义，但在规模扩展、事务一致性、高可用、性能表现以及成本效率等方面，存在高度共通的基础诉求。MetaDB 将这些共性能力下沉到数据库底座，把产品差异和语义差异保留在上层，因此系统演进的最小单位不再是单一产品，而是整个产品体系：底座完成一次性能优化、一次扩展升级或一次可靠性增强，多条产品线都能同步受益，新业务也可以直接复用经过超大规模生产验证的成熟能力。

这种统一复用覆盖代码资产、架构能力、生产经验以及演进成果：一次故障治理、一次性能突破、一次架构升级，都会沉淀为整个产品体系的共享资产。技术投入不再是多套系统的重复建设，而是随着产品覆盖范围扩大不断累积的“架构复利”。

围绕这一元数据底座，已经逐步形成持续演进的成果序列：

CFS（EuroSys'23）：面向 POSIX 语义，解决了 POSIX 兼容性与扩展性，尤其是写扩展性长期难以兼顾的问题，实现了文件规模扩展到百亿乃至千亿级时，性能不随规模下降、语义不打折扣。相关技术已应用于百度智能云最新发布的自研并行文件存储系统 PFS L3。

Mantle（SOSP'25）：面向 HDFS 语义，让对象存储的层级 Namespace 同时具备可扩展性与高性能，使对象存储真正成为数据湖场景的存储底座，为大数据上云进一步扫清障碍。该技术已在面向数据湖场景的对象存储 BOS 和类 HDFS 文件存储 AFS 中实现大规模落地。

MantleX（论文投稿中）：作为 Mantle 的后续演进，重点解决层级 Namespace 的规模自适应问题。Mantle 主要面向大规模分布式场景设计，但在单机即可承载的小规模场景下，会引入额外的跨节点通信和分布式事务开销。MantleX 采用“单机-分布式一体化”架构，使元数据在小规模场景下保留单机路径的高性能，并在规模增长后平滑切换至分布式模式。一套架构同时兼顾小规模场景的高性能和大规模场景的扩展能力，目前已完成研发并实现规模化落地。

随着 MetaDB 入选 NSDI'27，百度沧海 · 存储持续演进多年的云存储元数据架构体系，也以更加完整的形态展现在业界面前。

注：阿姆斯特丹自由大学任泽槟博士与百度智能云高级架构师曹彪为共同第一作者，北京大学陈康老师与曹彪为共同通讯作者。其中，曹彪同时也是 MetaDB（NSDI'27）系统的架构师。

免责声明：本文由本 出于商业信息传播目的转载发布，文中内容并不代表本 的观点或立场。文内涉及的文字、图片、音视频等资料，其全部权利及相关法律责任均由材料提供方享有并承担。本 对其中咨询文字、图片等全部信息的真实性不作任何保证或承诺，相关内容亦不构成任何购买、投资等建议；如据此操作，风险需自行承担。