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

自 HopsFS（FAST'17）验证可行性以来，用分布式数据库承载文件系统元数据逐渐成为业界的主流路径：底层数据库提供元数据存储，确保一致性、高可用和扩展能力，上层 Namespace 服务实现文件系统语义，分层清晰、各司其职。

但这条路径有一个长期被忽视的代价：数据库并不知道自己存放的是一棵目录树。元数据被当作普通的表和行来对待，文件系统负载中最重要的结构信息，在进入数据库的那一刻被抹平了。

MetaDB 给出的回答是：这些信息被抹平，意味着数据库失去了把元数据操作做得更快、更省的一切依据，只能以最通用、也最昂贵的方式对待每一次请求。把结构还给数据库，省下的就是这笔被通用性浪费掉的资源。

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

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

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

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

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

第一，数据库看不见目录树。生产负载中，超过 97% 的目录修改操作只涉及单个目录，本应就近完成。但通用分布式数据库不理解目录树的拓扑，常常把同一目录下的数据拆散到不同分片，一次局部操作由此被放大成跨分片的分布式事务；即使数据恰好位于同一分片，仍可能引入多轮网络交互。

第二，数据库分不清元数据的主次。一次目录操作，除了必须严格一致的主元数据，还会同步更新父目录属性、配额统计和二级索引等辅助信息。通用事务模型把它们一视同仁地纳入同一事务：父目录属性成为热点，辅助更新引入额外的跨分片协调，关键路径被并不关键的工作拖慢。

第三，数据库不了解元数据的生命周期。云存储中存在大量连续批量删除，而在通用存储引擎中，被删除的数据不会立即消失，只会留下层层「墓碑」标记。墓碑不断累积，listdir 这类范围扫描随之越来越慢：已经删除的数据，仍在拖累在线访问。

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

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

针对这些「看不懂」的问题，MetaDB 的做法是跨层协同设计：把上层 Namespace 服务掌握的文件系统信息，一层层传递给底层数据库的分片、事务和存储引擎。目录树的结构，用于指导分片与执行，同一目录的操作就地完成；元数据的主次，用于事务分级，关键路径不再被辅助更新拖慢；删除的生命周期规律，用于存储引擎的空间回收设计，扫描不再被「墓碑」拖累。

数据库由此从通用黑盒，变成真正理解文件系统的底座，为大规模云存储提供可扩展、高性能的元数据支撑。

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

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

为什么要以一套底座「统一」支撑？这背后是对长期架构演进的判断。平坦与层级（POSIX、HDFS）两类 Namespace 面向不同的产品和访问语义，但它们对规模扩展、事务一致性、高可用、性能和成本效率的要求高度共通。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）系统的架构师。

文章纠错