作者：杉岩数据 花瑞
在算力需求爆炸的AI时代，DeepSeek开源推出的高性能分布式文件系统3FS（Fire-Flyer File System），以单机SSD性能极限挖掘与RDMA网络零拷贝传输为核心，重新定义了AI训练场景的高性能存储标准。
3FS有许多亮点，例如元数据设计、针对基于USRBIO的FUSE客户端、异步零拷贝API、使用FFRecord格式来规避海量小文件性能问题、提供KVCache存储卸载以及区别于常见通用存储系统的链式复制协议等。本文将深度剖析其元数据服务创新，并结合杉岩分布式存储系统架构，揭示分布式KVDB在构建新型文件系统元数据层中的关键作用。
3FS的元数据服务架构设计
下图所示是现代分布式文件系统的典型架构，其中，元数据服务至关重要，在功能、性能、扩展性等诸多方面决定着分布式文件系统的规格和上限。
目前业界基于分布式 KVDB 系统来构建大规模文件和对象存储系统的元数据服务已形成流行趋势，如Google Colossus、Microsoft ADLS、HopsFS、JuiceFS等。这种趋势出现的背景是现代分布式KVDB或NoSQL存储系统技术发展的成熟。利用分布式KVDB的能力，能够极大简化元数据服务的设计，这已经成为很多存储系统，尤其是云存储的共识。分布式KVDB或NoSQL系统在分布式事务支持、扩展能力、高并发性能等方面的优势，使得基于其作为文件系统元数据的持久化层，来构建海量分布式文件系统的开发过程大大简化。3FS采用的正是这种架构，它使用FoundationDB来持久化文件元数据，包括文件路径、属性、目录结构等。其中核心键值对有两种：
通过这样的Schema设计，即可在分布式KVDB中构建出文件系统目录树的结构，文件路径的增删改查操作转化为了分布式KVDB的单key或多key的增删改查操作。
基于这种元数据服务架构的分布式文件系统具体优点如下：
1.高可扩展性和可靠性
分布式KVDB系统天然支持水平扩展，用于保存文件系统元数据，以实现单一命名空间承载千亿甚至更高量级文件或目录数的规格。同时，文件系统元数据服务的可靠性、均衡性可以由其保证。借助FoundationDB已实现的高可用及扩展性，3FS的元数据服务（Meta Service）与元数据持久化存储层实现了“存算分离”，Meta Service可以完全做到无状态，具备了独立扩展能力，Client请求也可以下发到任意节点。
此外，元数据的分散性也可以得以保证，传统文件系统元数据服务器（MDS）经常遇到的部分目录的热点问题以及目录分裂策略问题也得以缓解。
2. 简化一致性模型
分布式KVDB本身支持强一致性事务，基于其开发应用的复杂度大大降低，关于文件系统元数据的所有一致性问题可以下沉给KVDB去解决。3FS基于FoundationDB的 Serializable隔离级别，乐观并发控制和分布式锁等能力保证了各种元数据并发操作（如文件创建、删除、Rename、目录遍历）时的ACID语义。以往文件系统的MDS服务中的经典问题，比如目录树节点的rename成环问题、孤儿节点问题，都可以通过FoundationDB的事务模型来解决，Meta Service只负责文件POSIX语义解析即可。
3FS利用 FoundationDB 的串行化隔离级别事务的元数据操作有：
- 使用只读事务的查询类操作：fstat、lookup、listdir等。
- 使用读写事务的更新类操作：create、link、unlink、rename等。
3. 灵活的数据模型扩展
支持动态添加元数据字段（如自定义标签），无需修改底层存储结构。并且如果扩展新的元数据字段，如3FS的Meta Service，客户端、存储服务等其他组件可以按需单独升级，大大提升在线集群维护灵活性。
然而，任何事物都是有两面性的，在实际工程实践中，使用分布式KVDB存储文件系统元数据仍存在一些挑战：
1. 事务开销大影响元数据性能
分布式KVDB在实现上通常都会把已保存的整个key空间按照从小到大的顺序切分成相连但不交叠的区域，称为分片。每个节点都承载一定数量的分片，跨分片更新多个key的数据时涉及的事务操作开销较大：
- 前述Metadata key的布局特点决定了文件系统的create、rename等常见更新类操作，若严格按照标准POSIX协议实现，在FoundationDB侧等同于一个事务中更新多个key的操作。例如创建一个文件，就会涉及到新增这个文件的inode key、dentry key以及修改其父目录inode key的属性信息。如果多个key被分配到KVDB集群的不同分片上，为保证事务操作的原子性会触发两阶段提交（2PC），相比单个key或者多个key落在同一个分片上的情况（可简化为1PC提交），时延明显增加。
注：3FS在实现上为减少事务冲突，选择在文件创建时不更新父目录属性，以牺牲通用文件POSIX语义来换取特定场景下的性能。
- 由于FoundationDB采用串行化快照事务隔离级别（SSI），这种高隔离级别的事务开销较大，事务冲突场景下性能衰退严重。当两个并行的元数据更新操作发生冲突时，KVDB层检测到事务冲突后会导致一个事务被取消，之后在IO路径上触发Meta Service层的重试事务，可能影响吞吐量。另外，通用文件系统里更复杂的操作（如递归删除目录），会涉及大量事务提交，性能影响更大。
注：3FS采用支持非空目录删除与标记删除来尽力规避这种问题，以牺牲通用文件POSIX语义来换取特定场景下的性能。
2. 元数据的扩展能力有限
因为SSI的串行化隔离级别在KVDB的实现上依赖一个全局的单点TSO时钟，这会成为扩展的瓶颈。在大规模集群场景下，整个文件系统的并发能力的上限受到限制，并且TSO时钟本身的授时开销也会增加元数据访问的时延。
注：3FS通过FFrecord文件来规避这个问题，通过在应用层将小文件合并成大文件，保存在FoundationDB中的元数据量可以大幅减少。
杉岩AgileDB：元数据服务架构的创新设计与高效实践
杉岩非结构化数据分布式统一存储产品的元数据服务也采用了与3FS类似的架构，但使用的不是FoundationDB等通用分布式KVDB，而是全自研的分布式KV存储——杉岩AgileDB。杉岩AgileDB与杉岩文件和对象存储产品的网关层联动配合，继承了基于分布式KVDB的文件系统元数据架构的优点，同时克服了其局限性。相较于通用分布式KVDB（下表以FoundationDB和TiKV为例进行说明），杉岩AgileDB在特性的实现方式上做了一些取舍，并且实现了一些独特功能，简单比较如下：
从前述章节可以看出，使用分布式KVDB作为文件系统的元数据底座，如何既做到POSIX语义尽量的兼容，又降低大规模场景下KVDB的事务开销对性能的影响，是个难题，需要根据实际业务场景作出合理取舍。杉岩数据在平衡这两方面的过程中，自研的杉岩AgileDB发挥了重要作用，以下列举其中两个有代表性的实现机制：
1. 跨分片的元数据操作事务开销优化
杉岩AgileDB的元数据核心键值的设计与3FS整体类似但稍有不同，AgileDB的inode key和dentry key在普通文件和目录下是合并的，只有硬链接场景才会分开。当目录下文件数量过多，可能会导致该目录所有子项的key跨杉岩AgileDB的多个内部分片，此时创建文件时更新父目录的属性信息（已用容量统计、文件数量统计等），必然需要 2PC 事务提交机制来保证 ACID；同时，在同一个目录下的不同文件、子目录的并发创建、删除等操作会对父目录上计数等属性信息的更新带来大量冲突。
为解决这个问题，杉岩设计了自适应的虚拟目录机制：
对于跨AgileDB分片的实际目录，在每个分片中为其放置一个特殊的key（虚拟目录属性key）来标记该分片与真实目录的所属关系，value则存放虚拟目录的属性信息。AgileDB可根据分片的分裂和合并自动更新这个特殊key，业务无感知。
在创建文件的过程中，动态去获取该目录下所有子项分布在哪些分片，找到虚拟目录属性key，如果创建文件的过程中分片正在分裂，则等待分裂完成且AgileDB生成新的虚拟目录属性key后，再获取正确的虚拟目录属性key。创建文件的元数据的key和父目录属性信息（存入虚拟目录属性key）将被组成一个单分片事务提交（1PC）。
实际目录属性信息采用lazy的方式更新：仅当应用获取实际目录的属性信息时，AgileDB通过协处理能力将多个分片中的虚拟目录属性key信息以只读事务获取后合并信息并返回。
通过自适应的虚拟目录机制，将跨区域的实际目录的2PC更新转化为虚拟目录的1PC更新，减少了事务的开销，同时由于每个虚拟目录包含的元数据是实际目录的子集，这种分解方式进一步缩小了冲突域，缓解了实际目录下并发更新操作带来的冲突问题。
2. 单行多列族事务特性，支持文件系统高级功能
文件系统的一些高级功能均依赖按时间序保存的元数据Change log，比如异常场景下元数据的回放、跨站点的数据复制、元数据推送至其它大数据平台进行数据分析与检索等高级功能，这些功能要求Change log与文件元数据在写入KVDB时是强一致的。
全局Change log不能通过在KVDB中简单的增加以粗粒度时间戳为key的Change log记录来解决，这样在文件元数据更新时为保证原子性，就必须通过事务同步更新它，如此以来又会导致2PC提交而增加延迟，同时也会给多并发场景下的元数据更新操作引入性能瓶颈点。杉岩AgileDB通过支持多列族的行事务来解决这类问题：
- 将元数据内容和日志独立存储在不同的列族上，同时对不同列族之间的数据创建映射。通过该映射可以快速获取与某个元数据内容关联的Change log记录，并且在数据库发生数据迁移时，按照映射保证操作数据和日志始终处于同一个节点上。
- 对于Change log列族，AgileDB在内部以时间序建立索引，对Change log 进行有序排列，满足业务对Change log的快速范围访问和删除需求。
单行多列族特性的设计使得元数据的更新和Change log记录在同一个事务中提交时，不需要跨分片走2PC提交即可保证原子性，在AgileDB分片因扩缩容等导致的分裂、合并等场景下也不受影响，在不增加事务开销的同时，很好的支持了通用文件系统的站点同步等高级功能。
基于AgileDB的杉岩分布式存储系统的优势
元数据是非结构化数据存储系统的“灵魂”，杉岩数据的下一代融合对象存储产品、面向工业质检大数据存储的IDM产品都使用AgileDB作为元数据底座。杉岩融合对象存储产品融合了CIFS/NFS/FTP/FUSE/S3协议，提供了比传统分布式文件系统和对象存储系统更大规模的存储能力和并发性能，并且实现了文件和对象协议的原生无损互通。集成AgileDB的杉岩融合对象存储系统有以下特点：
- 全对称架构，元数据存储组件和数据存储组件一样，无单点瓶颈（AgileDB通过HLC避免了事务通过单点授时），提供了更高扩展能力以及安装部署的灵活性。
- 单对象存储桶或单文件系统命名空间轻松支持千亿以上海量小文件的存储。
- 根据不同业务的需要可创建不同类型的对象存储桶：树形结构的文件桶或扁平结构的普通对象桶。两种桶在同一个AgileDB实例上通过不同的schema来实现，互不影响。
- 文件和对象协议原生无损互通，无需协议转换网关。二者共享元数据与Change log日志，通过文件接口写入的数据，可以利用对象接口为其定义业务标签，文件系统命名空间中的数据也可借助对象存储的生命周期管理功能实现数据流动。
- AgileDB作为存储系统的内部的元数据服务，可通过Kafka或消息推送接口与其它外部大数据分析系统或组件连接，支撑更高级的业务元数据分析能力。
总结
3FS的技术实现架构及相关性能数据证明，存储系统的产品中处处存在trade off。只有真正了解自身需求，在整个系统端到端的设计中做出细粒度的解构，在分布式文件系统的核心组件——元数据服务上，这种服务无状态、数据下沉至第三方分布式KVDB的“存算分离”式设计，才不会因为分离带来的网络开销以及分布式KVDB的事务开销而拉低整个系统的性能。
杉岩数据针对客户的应用场景，自研了AgileDB分布式KVDB系统，并且将其应用于自研海量对象与文件融合存储产品上，拓展了分布式KVDB作为大型存储系统元数据底座这一技术架构的应用边界。
