项目背景

随着人工智能技术的飞速发展，机器学习训练已成为推动行业智能化转型的关键力量。这些大模型以其强大的语言理解和生成能力，在自然语言处理、图像识别、智能推荐等多个领域展现出极大的潜力。然而，机器学习的训练与部署对存储系统提出了前所未有的挑战。海量的训练数据、复杂的模型结构以及高频的数据读写需求，使得传统的非结构化存储方案难以胜任。

滴滴不断致力于提升用户体验，积极拥抱人工智能技术，在探索过程中，也遇到了数据存储与处理的瓶颈。 传统的存储系统往往只支持单一协议，数据在不同协议间的转换不仅耗时费力，还极大地影响了机器学习模型的训练效率和部署速度。具体问题表现如下 ：

• 机器学习等业务数据非常多，最少百PB级别存储量，主要小文件为主，基本上每个卷文件数达到几千万到百亿之间。
• 提供一定性价比。充分利用资源的同时有不错的性能，通常元数据延迟在10MS以下，带宽吞吐要求百GB以上。
• 机器学习等业务希望拥有对象存储的易用性，又能支持文件系统，同一份数据能支持多协议无损访问互通。业务通常会把需要训练的大模型、机器学习数据通过S3协议上传，通过机器学习的POSIX协议挂盘训练，过一段时间后自动删除，降低数据在多存储系统迁移成本、训练效率和数据管理成本。
• 支持云原生，同一块的机器学习数据盘，会被1万个容器根目录或子目录挂载读取。
• 多团队之间高效利用同一集群同一份数据且互不干扰。用户使用不同协议访问数据，不同权限管理数据保持数据不被影响干扰，最典型是A用户上传数据后，不希望B用户有权限删除。

为了满足业务需求，我们总结了新一代的非结构化存储系统，最少需要满足以下几个特性：

• 最少要支持百PB以上数据存储。
• 单卷或桶需要支持百亿级别的文件存储。
• 高性能低延迟的元数据存储服务，写控制2MS以内，读控制在10MS以内。
• 高并发高吞吐的存储底座，带宽吞吐要求百GB以上。
• 支持云原生，基于CSI插件可以快速地在Kubernetes上使用。
• 支持多租户，充分利用物理资源，同时支持相应的QoS能力来保证租户之间隔离。
• 多协议无损融合互通，实现Posix、S3、HDFS三种不同存储协议无损访问互通。
• 支持多云架构，充分利用公有云能力，能保证云上云下架构一致，应用与不同的场景，云下可以使用滴滴自研的存储引擎，云上可以使用AWS S3、阿里云OSS、腾讯云COS、谷歌云等。
  

方案探索

探索已有存储

我们对滴滴内部现有的非结构化存储来探索否满足以上特性?

• GIFT对象存储系统 ：自研的对象存储，起源于滴滴基础平台，项目2016年9月开始建设，我们2017年4月开始接手，目前分成2.0和3.0版本， 2.0支持百亿级小文件系统，3.0兼容S3协议。这系统支持多租户、百PB以上数据存储、单桶最高支持百亿级文件数、高并发高吞吐存储底座、兼容S3协议。但是不支持POSIX协议、也不支持HDFSF协议、更不支持多协议融合，所以不满足需求。
• Ceph存储系统 ：提供对象、块、文件等存储系统，但文件和对象是两个独立系统，数据迁移成本高，不满足需求。
• HDFS开源项目 ：主要离线hadoop大数据生态场景，大文件存储为主，不满足需求。
• GlusterFS开源项目 ：只POSIX协议的文件存储，性能满足需求，但不支持多租户、不支持HDFS协议、不兼容S3协议、不支持多存储语义、同时单卷容量也不满足需求。

探索多存储组合

通过 上面单一系统结论，发现滴滴内部的单个非结构化存储系统是不满足需求，所以我们是不是可以考虑多个系统组合支持来解决业务问题，我们的组合方案： GlusterFS文件系统 + GIFT对象存储方案 和 类S3FS + GIFT对象存储方案。

将大批量的机器学习数据存储到GIFT对象存储系统中，需要训练时， 再 将需要训练的数据集复制到GlusterFS文件系统中，由机器平台挂载训练。

• 随着训练集数据越来越多，需要复制数据集占用整体训练时间比例越来越长。
• GlusterFS文件系统支持数据盘的容量也越来越不满足训练需求。
• 同时数据在GlusterFS和GIFT对象存储都需要各存储一份，也比较浪费空间。

我们思考，是不是可以直接用一套系统来实现，上面实现S3和POSIX协议，这样就解决掉空间浪费和数据复制效率等问题。所以，我们就开始探索GIFT对象存储基础上直接使用类S3FS的文件系统。但又带来另外2个新的问题，即：无法提供 原子的 rename 和 随机写 ，具体如下：

• 基于GIFT对象存储实现的S3FS，可以把 GIFT的 bucket 挂载到系统中以 POSIX 方式访问，但无法提供 原子的 rename 。例如：在test桶中有“/a/a1/a2/1.txt…”等文件，需要rename根目录下的a/文件夹为x/。

• 同时对随机写的操作也非常重，需要对整个先文件下载下来，修改后在重新上传到对象存储中。

探索业界方案

无论是使用已有单个存储系统，还是多个存储系统组合，都不能完美解决业务问题，所以我们开始探索业界的解决方案： Juicefs+RDS+Gift对象存储系统

JuiceFS 是个非常优秀的分布式文件系统，它兼容Posix、S3和HDFS协议，同时支持云原生。我们在社区版Juic eFS本的的基础上 支持多租户、黑洞，超时、异步写等能力，满足了我们DBPROXY业务日志存储1PB左右存储需求。但应用于机器学习、大模型训练这类的场景还是有些问题，具体如下：

• 社区版JuiceFS使用RDS存储元服务，主从同步本身有延迟，所以我们使用主库写，备库读会读写不一致问题，如果直接切到主库读写压力又非常大。
• 所有的OP操作都会被转为KV，需要多次与RDS元服务交互，延迟相对比较高。
• 读写数据块的链路比较长。读一个数据块，需要经过GIFT多层才能到的BS存储引擎，同时GIFT本身也需要元服务，在加上JuiceFS元数据，就存在两份元信息。
• 所有流量都要经过GIFT的DGW服务，而DGW的带宽是非常有限，无法最大化的利用机器网带宽。

新一代存储

OrangeFS 新一代存储系统设计吸收探索方案的经验，同时研究并吸取了 Ceph、HDFS、CubeFS、JuiceFS、seaweedfs(Facebook haystack思想)等开源的设计思想，结合GIFT对象存储等原架构的设计思想和线上实践经验基础上演进。

复用GIFT技术

GIFT是滴滴自研的对象存储系统，从2017年接手以来，自研的2.0发版至今已支撑滴滴千亿级别大小文件存储，单桶最高达百亿级。这个系统主要由协议层、配置中心，RDS元数据、数据存储引擎等子系统组成。

• 接入服务：提供S3和GIFT V2协议解析的入口服务。
• RDS元数据服务：提供文件的元数据存储。
• 配置中心：提供租户信息、流量控制、桶信息等配置管理。
• BS数据存储引擎：提供对象存储的数据分片存储。
• Pixar图片处理服务：提供简单分布式图片处理服务。包括：压缩、水印、剪裁等能力。

1、是否复用配置中心

• 快速存储组件配置变更并自动执行，包括：QPS、流量、开关等。
• 统一桶命名和管理。
• 多租户管理，包括：密钥管理、配置信息管理。
• 快速扩容和管理元服务。
• 快速扩容和管理存储引擎。包括：禁写等能力。
  
  

一个集群管理多少个节点？如何做隔离域？快速扩容？

• 一个集群管理N个存储引擎分组，每个分组可以管理M台机器（可配置）。故障域为一个分组池，异常最大影响一个分组，可随时设只读，分组间数据可自动或半自动平衡。所以一个集群最终可管理N*M个节点。
• 一个集群可以管理N个元服务分组，一个元服务管理N个桶/卷。
• 无论是存储引擎 还得元服务 ，扩容只需要配置中心插入一条记录，10秒以内生效。

元服务快速扩容：

存储引擎快速扩容：

2、是否复用S3协议

我们可以复用GIFT的接入服务设计，提供S3协议，可以节省研发周期同时又能吸取过去经验，为新服务提供稳定的接入层，包括：QoS能力。

• 限制总带宽和桶级带宽。
• 快速隔离。
• 容量预估，项目分等级预留资源。
• 桶级QPS限流。

3、是否复用元服务

从GIFT技术架构中我们可以看到元服务主要是采用 RDS分库分表模式 ，数据分片存储采用 多组BS数据储引擎进行并发分流 。我们通过上传下载来理解下分库分表和并发分流，上传流程具体如下：

元信息分库表采用主从模式，如果全部从主库读写压力非常大，如果从从库读，那么就会有主从同步延迟问题，也就是刚写入的文件实时是读不到，产生不一致现象，所有这个就无法应用与新的架构中。

3、是否复用存储引擎

BS存储引擎是一套自研的数据分片存储系统，主要是基于facebook haystack论文件实现的。主要包含两大系统，Master server和 block server。Master server主要负责节点管理；block server主要负责数据分片存储。具体架构如下 ：

GIFT的BS存储引擎采用小文件合并，大文件分片设计。来解决小文件过多造成性能、存储空间浪费等问题。大于设定块大小的阈值时协议层需要对大文件进行切片，切到可支持的最大文件片，最后一片不限制。异步GC设计，主要是回收删除Needle时造成的空洞。

OrangeFS架构实践

解决了多租户、配置中心、S3协议层实现、存储引擎一期等能力后，我们还需要解决哪些问题？

• 文件存储结构需要重新设计，能支持多个协议，包括：POSIX和HDFS协议。
• 元服务需要重新设计，支持最终能支持千亿级别大小文件存储。
• 支持云原生，基于CSI插件可以快速地在Kubernetes上使用。

• 存储引擎一期支持完数据分块存储后，还需要继续成本和性能优化。

1、文件存储结构

我们结合行业相关方案和复用GIFT的大文件拆块思路，把一个文件拆成多个固定大小段，提高系统读写的并发性能，我们称之为Chunk。每个Chunk内部都会存在多次写入或修改的可能，我们把每次写入或修改不固定的大小块称之为Blob（Binary Large Object）。一个Blob是由多个固定长的数据块组成，我们称之为Block。具体如下图所示：

Chunk和Blob数据信息我们存储到自研的MDS元信息存储服务中，而Block分块，我们存储在自研的数据存储服务或公有云的S3、cos、oss等产品中。

A、写组织结构

• 文件在写场景时，提高性能减少Blob数量，每个Chunk默认只生成一个Blob。
• 当业务写入或修改的内容对应的数据块与上一个Blob有重叠时，就会生成新的Blob，只要数据不重叠，那么就不生新的Blob。
• 当业务写入数据刚好介于block3 中间部分，那么这类场景也是生成新的Blob，来保证每次写入都是顺序写。
• 当业务写入的数据刚好是在Block5 数据块上，而且新写入的数据与Block 5原内容不重叠，那么可以做append操作。
• 数据块超过设定的值就直接提交到远程。元信息写满足后提交或超时后自动聚合的提交到远程。

B、读组织结构

文件在读的场景时，读取到某个Chunk时，会将所有了Blob进行合并，获取到一个新的Blob，在将新的Blob对应的数据块Block返回给上层调用服务。具体如下图所示：

2、多协议融合

我们在 OrangeFS 实现上封装相对路径的VFS层和绝对路径的PathFS层。VFS提供给Posix协议使用，封装了文件所有操作接口，包括：打开、创建、读、写、同步等操作。PathFS提供给 S3、HDFS 协议使用，主要是单文件多个操作集合，例如：上传文件，就是创建、写操作集合。具体如下图所示：

• POSIX(Fuse)：基于相对路径VFS层之上实现，Kernel缓存部分目录路径， POSIX Client自己缓存其余路径。
• S3：基于绝对路径的PathFS层之上实现，是一个扁平KV结构。
• HDFS：基于绝对路径的PathFS层之上实现，不经过内核层，所以没有缓存目录树，基于PathFS 构建Libofs动态库与SDK互通。
  
  

我们看下对路径VFS层和绝对路径的PathFS层区别，如下所示：

A、多协议融合写

无论使用任何协议，我们解析完协议后，都会得到inode、offset、data三个信息。具体流程如下图所示：

B、多协议融合读

读也是如此，无论使用任何协议，我们解析完协议后，都会得到inode、offset、data三个信息，具体操作如下图所示：

3、OFS链路优化

相比探索的组合方案，我们直接跳过GIFT中间所有层调用，直接把数据块写入存储引擎中，提高性能，降低链路调用的延迟，

4、MDS元服务

MDS元服务存储服务主要提供元信息、配置信息存储服务。主要包含ROOT SERVER、Meta Server、PD等子系统。具体如下图所示：

• Root Server：是个无状态服务，提供中心化的配置管理服务、快速存储组件扩容配置、变更自动执行，包括：QPS、BPS、开关、桶/卷的信息、多租户信息等管理。
• Meta Server：元数据存储服务，提供元数据存储和目录树服务。
• 每个桶/卷 一组或多组 MS服务集群提供服务，每组 3+1 模式，保证快速恢复，减少毛刺。
• 本地引擎通过MULTI-RAFT、RocksDB进行数据一致性数据存储。
• 支持内存目录树和 inode cache提高S3或HDFS性能。
• 内存事务保证并发正确性。
• PD Server：提供统一的Raft管控和调度服务，支持自动副本补齐、热点均衡、平滑升级等能力。

A、MDS元服务结构

我们的MDS元服务结构，一个用户可以申请多个桶或卷，每个卷或桶是由一组RAFT或多组RAFT提供服务（子目录分区），如下图所示：

• 一期，不同桶或卷一组raft group支持，但只能Leader读写。
• 二期，我们支持桶或卷一组raft group支持，支持全部节点读写。
• 三期，我们支持桶或卷的子目录分区，也就是一个目录级别raft group的读写

B、降低MDS延迟

我们客户端或S3或HDFS服务的操作只需要和MDS交互一次，所有的操作转换为本地KV操作，减少网络多次交互的开支。

5、POSIX客户端

OFS Posix是基于 fuse 的文件系统客户端，完全兼容Posix协议，具体如下图所示：

• 接收与处理 FUSE 的操作请求，与MDS Cluster 交互实现文件元信息的增删改查及管控操作， 与自建IDC的BS数据存储引擎或公有云OSS/S3/COS等系统交互实现文件分片数据的增删改查。
• 支持卷级的QoS，包括：带宽、QPS、黑洞等能力。
• 支持元信息缓存和数据缓存以提高性能。
• 支持秒级热升级能力，解决K8S紧急BUG或新功能无感上线问题。

6、数据冗余

多副本系统在单AZ部署下，只要集群失效了，那么数据全部不可用。

多副本的3AZ部署模式最多可容忍2个AZ挂掉。

3.3 最终落地和收益

GIFT和OFS非结构化存储技术已覆盖全公司所有业务，其中OFS快速成长，已接入几十PB，包含机器学习、大数据、金融、国际化等业务。OFS具体架构如下图所示：

• 支持无损多协议融合，包括：POSIX、S3、HDFS等多存储语义。
• 支持多租户，集群支持千亿级文件存储，单桶/卷支持最高百亿级别文件存储。
• 自研MDS，支持 MultiRaft、内存事务、动态调度等技术。
• 支持OFS POSIX客户端秒级热升级技术
• 支持多公有云架构技术
• 支持全新的QOS能力，包括：黑洞，超时、异步写等特性。
• 支持回收站能力。
• 支持数据内容加密、压缩等能力。
  

踩坑之旅

在机器学习训练的过程中，随着用户规模、数据量持续增长，不同阶段也踩了很多的坑。

第一阶段，初步接入机器学习训练，数据量PB级别，小文件很多， MDS元服务 便成为瓶颈，主要从低延迟、正确性、扩展性、稳定性 4个方面来看看踩坑实践。

第二阶段，机器学习训练持续铺量，数据量数10PB级别，大小文件都有， 文件系统客户端 吞吐便成为瓶颈，主要从高吞吐、读写解耦、Client数量多3个方面来看看踩坑实践。

第三阶段，已经有一定规模，数据量近百PB级别，使用团队比较多，主要从权限隔离、收站两个方面来看看如何支持 多团队高效协作 。

4.1 MDS元服务

1、低延迟

研发测试完成，接了一些试点小流量，机器学习训练场景准备小规模放量，业务经常反馈 训练抖动和读取慢 ，元数据整体延迟更是抖到 秒级别 ， CPU内存、Meta延迟 等电话报警不断，苦不堪言。训练也要求元数据延迟要小于10ms，所以我们通过 Profile 、 性能压测 、 Micro Benchmark 等一些工具进行了全链路性能分析和优化，发现问题比较多。

比如：Goroutine数10W太多，核心Goroutine得不到调度；Raft Propose仅仅入队列延迟高到100ms，Raft写入完成需要 300ms，Golang Runtime消耗整机CPU 45%等。

• 链路上 ：最开始Client一个OP会和MDS做多个RPC；优化为一个OP一次RPC，产生的读写KV都在本地执行，精简链路。
• 架构上 ：最开始GRPC收到请求之后，每个请求都占用一个Goroutine。10W 只读请求会有10W Goroutine 并发读KV；写请求并发Propose，串行Commit日志，串行Apply，Apply的时候执行OP， 由于Apply串行执行OP，而且每个OP大小不一，有读有写，一个OP慢，那么整体Apply就慢，进而导致Raft Propose整体延迟升高 。优化为队列+线程池模型，同时 Raft Apply串行执行OP ---> Raft Apply 直接保存OP KV 结果，在Propose前并发执行OP。
• 网络上 ：GRPC换成TCP，队列+ Async  Batch收发包，相同QPS情况下，CPU降低一半。
• Raft上 ： 在其串行本质的基础上通过Batch+Pipeline提升吞吐降低延迟。

2、正确性

延迟高问题解决之后，接踵而来的是数据读错，目录结构乱了 。并发不一致、Read一次EIO、脏数据都会导致训练了几天的任务中断作废，需要重跑。

比如并发的 /a 目录下创建文件和删除 /a 目录，最开始的时候OP是串行执行的，不太用考虑并发问题，现在并发执行OP了，有可能出现在进去 /a 目录里面之后，创建文件的同时把目录删除了， 就可能会出现 在给用户反馈创建文件成功之后，用户看不到这个文件，成为孤儿节点。

有4种方案解决并发问题 ：

方案一：全串行，不可取延迟高

方案二：像CpehFS那样对文件目录等加读写锁，实现难度高，易出错。

方案三： 像支持 客户端分布式事务，但延迟高，难度大。

方案四： 实现单机服务端乐观事务 。我们最终支持单机服务端内存事务 + Write 串行。即对于冲突比较高的POSIX Write和S3 Put操作，同个文件通过Hash到同一个队列的方式 串行执行 。

内存事务分4步 ：

• 第一：并发内存执行，每个Txn OP操作都会涉及读写多个KV，执行Txn OP，内存得到一组待更新的KV buf。
• 第二：串行冲突检测，每个Txn在开始的时候有一个ReadTs，提交的时候有一个CommitTS，当前的Txn和其他正在提交的Txn进行读写Key的重叠判断。
• 第三：Raft落盘：等待Raft apply多副本复制结束。
• 第四：更新Cache：保证KV落盘的数据和更新Cache的顺序是一致的。

3、扩展性

有了一点规模之后，大约几个PB的量，延迟高问题又出现了 ，线上训练有个Volume 30W qps 的Read，导致Leader机器CPU掉底，延迟飙升到秒级别。因为读写都在Leader，即使我们有2个Follower 和 1个Learner，也是一台机器在抗，一台有难，3台围观。

迫切的需要其他节点也提供读的能力，我们支持了OP粒度的Follower Read，可以通过扩充Learner来提供读能力。

实现上，Follower读的时候，会先从Leader拿取CommitIndex作为自己的ReadIndex，然后等待自己的ApplyIndex >= ReadIndex的时候，就可以提供线性一致性读。

• 服务端：
• 支持ReadIndex线性一致性读，以及Cache一致性。
• 支持Follower和Leader的LogIndexGap来动态开关Follower Read。
• 客户端：
• 管理多个节点的TCP连接池，有黑名单、重连等机制。
• 管控侧：