滴滴在大模型时代的数据湖存储探索实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 大模型时代
滴滴OrangeFS数据湖存储探索实践
黄春华 滴滴 高级专家工程师/文件存储部门负责人
史明亚 滴滴 专家工程师
DataFunTalk # 2024
2. 上半节：大模型领域存储系统探索实践
--- 黄春华
项目背景 & 可行方案探索
新一代数据湖存储实践
下半节：大模型领域存储系统踩坑之旅
--- 史明亚
3. 01
项目背景介绍
4. 大模型、机器学习等业务场景面临的问题？
•
大模型数据非常多，百PB级别，主要小文件为主，基本上每个卷文件数达
到几千万到百亿之间。
•
提供一定性价比。充分利用资源的同时有不错的性能，通常元数据延迟在
10MS以下，带宽吞吐要求百GB以上。
•
大模型数据希望拥有对象存储的易用性，又能支持文件系统，同一份数据能
支持多协议无损访问互通。业务通常会把需要训练的大模型数据通过S3协议
上传，通过机器学习的POSIX协议挂盘训练，过一段时间后自动删除，降低
数据在多存储系统迁移成本、训练效率和数据管理成本。
• 支持云原生，同一块的大模型数据盘，会被1万+个容器挂载读取。
• 多团队之间高效利用同一集群同一份数据且互不干扰。用户使用不同协议
访问数据，不同权限管理数据保持数据不被影响干扰，最典型是A用户上传
数据后，不希望B用户有权限删除。
5. 为了满足大模型、机器学习等业务需求，我们总结了新一代的非结构化存储系统，最少需要满足以下几
个特性：
• 最少要支持百PB以上大模型数据存储。
• 单卷或桶需要支持百亿级别的文件存储。
• 高性能低延迟的元数据存储服务，数据延迟控制10MS以内。
• 高并发高吞吐的存储底座，带宽吞吐要求百GB以上。
• 支持云原生，基于CSI插件可以快速地在Kubernetes上使用。
• 支持多租户，充分利用物理资源，同时支持相应的QoS能力来保证租户之间隔离。
• 多协议无损融合互通，实现Posix、S3、HDFS三种不同存储协议无损访问互通。
• 支持多云架构，充分利用公有云能力，能保证云上云下架构一致，应用与不同的场景，云下可以使用滴滴自研的存储引擎，云上可以使用AWS S3、阿里云
OSS、腾讯云COS、谷歌云等。
6. 02
可行方案探索
7. 探索已有存储
我们对滴滴内部现有的非结构化存储来探索否满足以上特性?
•
GIFT对象存储系统 ：自研的对象存储，起源于滴滴基础平台，项目2016年9月开始建设，目前分成2.0和3.0版本， 2.0支持百亿级小文件系统，3.0兼容S3
协议。这系统支持多租户、百PB以上数据存储、单桶最高支持百亿级文件数、高并发高吞吐存储底座、兼容S3协议。但是不支持POSIX协议、也不支持
HDFSF协议、更不支持多协议融合，所以不满足需求。
• Ceph存储系统 ：提供对象、块、文件等存储系统，但文件和对象是两个独立系统，数据迁移成本高，不满足需求。
• HDFS开源项目：主要离线hadoop大数据生态场景，大文件存储为主，不满足需求。
• GlusterFS开源项目：只POSIX协议的文件存储，性能满足需求，但不支持多租户、不支持HDFS协议、不兼容S3协议、不支持多存储语义、同时单卷容量
也不满足需求。
以过上面单一系统结论，我们发现滴滴内部的单个非结构化存储系统是不满足需求，所以我们是不是可以
考虑多个系统组合支持来解决业务问题
8. 探索多存储组合
GlusterFS+GIFT对象存储遇见问题？
将大批量的大模型训练数据存储到GIFT对象存储系统中，需
业务B
训练集数据写入
要训练时，在将需要训练的数据集复制到GlusterFS文件系统中，
由机器平台挂载训练。
读取需要训练数据集
机器学习平台
业务A
GIFT对象存储
•
间比例越来越长 。
GlusterFS
写入数据
随着训练集数据越来越多，需要 复制数据集占用整体训练时
•
GlusterFS文件系统支持数据盘的容量也越来越不满足训练
需求。
训练结果回写
•
同时数据在GlusterFS和GIFT对象存储都需要 各存储一份，也
比较浪费空间。
9. 探索多存储组合
S3FS + GIFT对象存储方案遇见问题？
我们思考，是不是可以直接用一套系统来实现，上面实现S3和POSIX
协议，这样就解决掉空间浪费和数据复制效率等问题，即： S3FS +
GIFT 。但又带来另外2个新的问题，即：无法提供原子的 rename 和 随
机写，具体如下：
• 基于GIFT对象存储实现的S3FS，可以把 GIFT的 bucket 挂载到系统中
以 POSIX 方式访问，但无法提供原子的 rename。例如：在test桶中
有“/a/a1/a2/1.txt…”等文件，需要rename根目录下的a/文件夹为x/。
• 无法支持随机写，对随机写的操作也非常重，需要对整个先文件下载
下来，修改后在重新上传到对象存储中。
10. 探索多存储组合
Juicefs+RDS+GIFT对象存储方案遇见问题？
JuiceFS 是个非常优秀的分布式文件系统，它兼容Posix、S3和HDFS协
议，同时支持云原生。我们在社区版JuiceFS的基础上支持多租户、黑洞，
超时、异步写等能力，满足了我们DBRPOXY业务日志存储1PB左右需求。
但应用于我们机器学习、大模型训练这类的场景还是有些问题，具体如下：
• 社区版JuiceFS使用 RDS存储元服务，主从同步本身有延迟，所以我们使
用主库写，备库读会读写不一致问题，如果直接切到主库读写压力又非
常大。
• 所有的OP操作都会被转为KV，需要多次与RDS元服务交互，延迟相对
比较高。
• 读写数据块的链路比较长 。读一个数据块，需要经过GIFT多层才能到的
BS存储引擎，同时GIFT本身也需要元服务，在加上JuiceFS元数据，就存
在两份元信息。
• 所有流量都要经过GIFT的DGW服务，而 DGW的带宽是非常有限，无法
最大化的利用机器网带宽。
11. 03
新一代数据湖存储实践
12. OrangeFS新一代存储系统设计吸
收探索方案的经验 ，同时研究并吸取
了 Ceph、HDFS、CubeFS、JuiceFS、
seaweedfs(Facebook haystack思想)
等开源的设计思想 ，结合GIFT对象存
储原架构的设计思想和线上实践经
验基础上 演进。
13. 分析是否能复用现有GIFT技术架构？
GIFT是滴滴自研的对象存储系统，向2017年自研的2.0发版至今
已支撑滴滴千亿级别大小文件存储，单桶最高达百亿级。这个系统
主要由协议层、配置中心，RDS元数据、数据存储引擎等子系统组成。
• 接入服务：提供S3和GIFT V2协议解析的入口服务。
• RDS元数据服务：提供文件的元数据存储。
• 配置中心：提供租户信息、流量控制、桶信息等配置管理。
• BS数据存储引擎：提供对象存储的数据分片存储。
• Pixar图片处理服务：提供简单分布式图片处理服务。包括：压缩、
水印、剪裁等能力。
14. 分析是否能复用现有配置中心？
• 快速存储组件配置变更并自动执行，包括：QPS、流量、开关等。
• 统一桶命名和管理。
• 多租户管理，包括：密钥管理、配置信息管理。
• 快速扩容和管理元服务。
• 快速扩容和管理存储引擎。包括：禁写等能力。
一个集群管理多少个节点？如何做隔离域？快速扩容？
• 一个集群管理N个存储引擎分组，每个分组可以管理M台机器（可配置）。故障
域为一个分组池，异常最大影响一个分组，可随时设只读，分组间数据可自动或
半自动平衡。 所以一个集群最终可管理N*M个节点 。
• 一个集群可以管理N个元服务分组，一个元服务管理N个桶/卷。
• 无论是存储引擎还得元服务，扩容只需要配置中心插入一条记录，10秒以内生效。
15. 分析是否能复用现有协议层？
X Gbit)
我们可以复用GIFT的接入服务设计，提供 兼容S3
X/N Gbit
X/N Gbit
X/N Gbit
协议，可以 节省研发周期同时又能吸取过去经验 ，
为新服务提供稳定的接入层，包括：QoS能力。
Router_2 …… Router_N
DAS_2 …… DAS_N
• 限制总带宽和桶级带宽。
• 桶级QPS限流。
• 快速隔离。
Mbit)
• 容量预估，项目分等级预留资源。
1s
S3 Server Cluster
DAS1
DAS2
……
DASN
QPS
16. 分析是否能复用现有GIFT的RDS元服务和并发问题？
• RDS元数据存储服务，我们采用分库分表，数据存储采用多数据存储引擎DFS进行并发分流。我们通过上传下载来理解下分库分表和并发分流，具
体如下：
17. 分析是否能复用现有GIFT的RDS元服务和并发问题？
start
http://domain/bucket/object
region
shareid
FSKEY
bucket#object) %
Bucket
Object X
bucket_name | region | bucket_name | object | fskey
test | ys | … anything
anything | gz | …
FileStorage
| shareid | …
| test.jpg | 3,04e3394e18ba | 1
|
region | addr
| readonly | shareid | …
gz | 10.0.0.1 | 0 | 0 |
gz | 10.0.9.1 | 0 | 1 | …
……
元信息分库表采用主从模式，如果全部从主库读写压力非常大，如果从从库读，那么就会有主从同步延迟问题，也就是刚写入的文件实时是读不到，产生不一
致现象， 所有这个就无法应用与新的架构中 。
18. 分析是否能复用现有BS数据存储引擎技术？
BS存储引擎是一套自研的数据分片存储系
统，主要是基于facebook haystack论文件实现
的。主要包含两大系统，Master server和 block
server。
• Master server主要负责节点管理、心跳管理
等等。
• block server主要负责数据分片存储。
19. 分析是否能复用现有BS数据存储引擎技术？
•
GIFT的BS存储引擎采用小文件合并，大文件分
片设计。来解决小文件过多造成性能、存储空
间浪费等问题。
•
大于设定块大小的阈值时协议层需要对大文件
进行切片，切到可支持的最大文件片，最后一
片不限制。
•
异步GC设计，主要是回收删除Needle时造成
的空洞。
20. OrangeFS技术架构还差什么？
解决了多租户、配置中心、S3协议层实现、存储引擎一期等能力后，我们还需要解决哪些问题？
• 文件存储结构需要重新设计，能支持多个协议，包括：POSIX和HDFS协议。
• 元服务需要重新设计，支持最终能支持千亿级别大小文件存储。
• 支持云原生，基于CSI插件可以快速地在Kubernetes上使用。
• 存储引擎一期支持完数据分块存储后，还需要继续成本和性能优化。
21. OrangeFS的文件存储结构？
• 我们结合行业相关方案和复用GIFT的大文件拆
块思路，把一个文件拆成多个固定大小段，提
高系统读写的并发性能，我们称之为Chunk。
• 对于文件系统每个Chunk内部都会存在多次写
入或修改的可能，我们把每次写入或修改不固
定的大小块称之为Blob（Binary Large
Object）。
• 一个Blob是由多个固定长的数据块组成，我们
称之为Block。
• Chunk和Blob数据信息我们存储到自研的MDS
元信息存储服务中，而Block分块，我们存储在
自研的数据存储服务或公有云的S3、cos、oss
等产品中。
22. OrangeFS的文件存储结构写操作？
• 文件在写场景时，提高性能减少Blob数量，每个Chunk默认只生成一个Blob。
• 当业务写入或修改的内容对应的数据块与上一个Blob有重叠时，就会生成新的Blob，只要数据不重叠，那么就不生新的Blob。
• 当业务写入数据刚好介于block3 中间部分，那么这类场景也是生成新的Blob，来保证每次写入都是顺序写。
• 当业务写入的数据刚好是在Block5 数据块上，而且新写入的数据与Block 5原内容不重叠，那么可以做append操作。
• 数据块超过设定的值就直接提交到远程。元信息写满足后提交或超时后自动聚合的提交到远程。
23. OrangeFS的文件存储结构读操作？
• 文件在读的场景时，读取到某个Chunk时，会将所有了Blob进行合并，获取到一个新的Blob，在将新的Blob对应的数据块Block返回给上层调用服务。
24. OrangeFS的多协议融合？
我们在OrangeFS实现上封装VFS和PathFS层。VFS提供给Posix协议使用，封装了文
件所有操作接口，包括：打开、创建、读、写、同步等操作。PathFS提供给S3、
HDFS协议使用，主要是单文件多个操作集合，例如：上传文件，就是创建、写操作
集合。
• POSIX(Fuse)：基于相对路径VFS层之上实现，Kernel缓存部分目录路径， POSIX
Client自己缓存其余路径。
• S3：基于绝对路径的PathFS层之上实现，是一个扁平KV结构。
• HDFS：基于绝对路径的PathFS层之上实现，不经过内核层，所以没有缓存目录树，
基于PathFS 构建Libofs动态库与SDK互通。
PathFS
VFS
25. OrangeFS的多协议融合写？
• 按 inode 找到对应文件上下文，然后通过 offset 和 data 长度获得
Chunk固定逻辑块集合。
• 检查Chunk固定逻辑块是否有可复用的Blob，如果存在，那么直接
使用；如果不存在，那创建新的Blob。
• 将Blob偏移offset和data内容拷贝到对应的Block对象存储块中。
• 数据信息拷贝完成后，更新元信息中的长度。异步写请求可以向
FUSE 返回写成功。
• 上传Block对象块到数据存储服务中。
• 提交Blob和更新inode长度/修复时间，也是：版本号。
26. OrangeFS的多协议融合读？
• 按 inode 找到对应文件上下文，然后根据data长度和offset获得
Chunk固定逻辑块集合。
• 获取每个Chunk对应的获取Blob列表。优化从缓存中获取，如果之
前没有缓存会从RDS中获取，并进行缓存。
• 构建每个Chunk 对应的Blob，重叠部分新的覆盖旧的。
• 根据每个Chunk 对应的Blob、offset、读取长度，构建对象存储块
列表Blocks 。
• 根据对象存储块列表Blocks去数据存储服务中获取每块Block内容。
若开启缓存会优先查询本地缓存中的对象，存在则可读缓存信息，
没有则需要向多云数据存储服务发送读请求。如果本地缓存空间足
够，那么会缓存本次数据，并通过LRU淘汰缓存。
• 获取到的Block内容写入到Data中，所有的数据拷贝完成后，向
FUSE 返回读成功。
27. OrangeFS调用链路优化？
相比探索的组合方案，我们直接跳过GIFT中间所有层调用，直接把数据块写入存储引擎中，提高性能，降低链路调用的延迟
28. OrangeFS的MDS元服务？
• Root Server：是个无状态服务，提供中心化的配置管
理服务、快速存储组件扩容配置、变更自动执行，包括：
QPS、BPS、开关、桶/卷的信息、多租户信息等管理。
• Meta Server：元数据存储服务，提供元数据存储和目
录树服务。
ü 每个桶/卷 一组或多组 MS服务集群提供服务，
每组 3+1 模式，保证快速恢复，减少毛刺。
ü 本地引擎通过MULTI-RAFT、RocksDB进行数据
一致性数据存储。
ü 支持内存目录树和 inode cache提高S3或HDFS
性能。
ü 内存事务保证并发正确性。
• PD Server：提供统一的Raft管控和调度服务，支持自
动副本补齐、热点均衡、平滑升级等能力。
29. OrangeFS的MDS元服务结构？
• 一期，不同桶或卷一组raft group支持，但只能Leader读写。
ROOT
• 二期，我们支持桶或卷一组raft group支持，支持全部节点读写。
Bucket OR
Volume1
User1 ……
…… Bucket OR
Volume N
UserN
• 三期，我们支持桶或卷的子目录分区，也就是一个目录级别raft group的读写
Meta Server Cluster
MS
leader
MS
/
Raft Group(一期)
本地KV引擎
MS
Raft Group(三期)
A/
B/
s2/
……
……
MS
……
follower
a1/
learner
follower
我们的MDS元服务结构，一个用户可以申请多个桶或
卷，每个卷或桶是由一组RAFT或多组RAFT提供服务。
30. OrangeFS降低与MDS操作延迟，提高性能
我们客户端或S3或HDFS服务的操作只需要和MDS交互一次，所有的操作转换为本地KV操作，减少网络多次交互的开支。
Meta Server Cluster
OFS Posix
client
所有OP与MDS交互一次
所有OP转换的KV操作都是本地操作
，减少网络开支
MS
leader
MS
本地KV引擎
MS
follower
learner
MS
follower
31. OrangeFS Posix客户端？
OFS Posix是基于 fuse 的文件系统客户端，完全兼容Posix协议。
• 接收与处理 FUSE 的操作请求，与MDS Cluster 交互实现文
件元信息的增删改查及管控操作， 与自建IDC的BS数据存储
引擎或公有云OSS/S3/COS等系统交互实现文件分片数据的
增删改查。
• 支持卷级的QoS，包括：带宽、QPS、黑洞等能力。
• 支持元信息缓存和数据缓存以提高性能。
• 支持秒级热升级能力。
32. OrangeFS数据冗余
Cluster
多副本系统在单AZ部署下，只要集群失效了，那么数据全部不可用。
AZ1
Rack1
……
Host
多副本的3AZ部署模式最多可容忍2个AZ挂掉。
DISK1
Rack2
……
Host
DISK2
Rack3
……
……
Host
DISK3
BS1 BS1 BS1
Blob 1 Blob 1 Blob 1
……
……
33. OrangeFS最终落地和收益
S3
SDK
Posix
Client
Application
HDFS
SDK
GIFT和OFS非结构化存储技术已覆盖全公司所有业务，其中OFS
快速成长，已接入几十PB，包含大模型、机器学习、大数据、金融、
国际化等的业务。
S3 Server Cluster
S3sr 1
S3sr 2
……
Posix
interface
S3sr n
HDFS
interface
• 支持无损多协议融合，包括：POSIX、S3、HDFS等多存储语义。
• 支持多租户，集群支持千亿级文件存储，单桶/卷支持最高百亿级
Meta API
Conf info
BS api
MS Cluster
BS Cluster
Root Server Cluster
META(备)
MS 1
META(备)
RS1
……
META(备)
BS 1
META(备)
RSn
META(备)
BS 1
META(备)
PD Cluster
Raft OP
Raft INFO
PD2
PD1
BS OP
PD3
• 自研MDS，支持 MultiRaft、内存事务、动态调度等技术。
• 支持OFS POSIX客户端秒级热升级技术
• 支持多公有云架构技术
META(备)
MS 1
META(备)
META(备)
MS n
META(备)
别文件存储。
BS INFO
• 支持全新的QOS能力，包括：黑洞，超时、异步写等特性。
• 支持回收站能力。
META(备)
BS n
META(备)
• 支持数据内容加密、压缩等能力。
34. OrangeFS未来规划
与业内同行相比，我们还存在很多不足，BS存储引擎持
续降成本、提升性能；MDS元服务持续三期建设，提高元数
据的扩展性来满足未来业务持续发展需求。
35. 04
踩坑之旅
36. OrangeFS 踩坑之旅
阶段一
阶段二
MDS
元服务
•
•
•
•
低延迟
正确性
扩展性
稳定性
阶段三
POSIX
客户端
•
•
•
高吞吐
读写卡顿
Client数量多
OFS
多团队协作
•
•
权限隔离
误删除
37. 阶段一：OrangeFS MDS 低延迟？
出师不利：大模型训练开始小规模放量，元数据延迟抖到上秒。
训练需求：元数据 Latency < 10ms
全链路优化，15w/s Read P99 < 1ms
• 架构：串行-->并发 55w Set / 7w Mknod
• 网络：GRPC --> TCP 10w QPS，CPU half
• Raft：增大Batch粒度 2 --> 10+
• Metric：延迟异步 6w --> 120w
38. OrangeFS MDS 正确性？
雪上加霜：并发不一致、训练EIO、脏数据，导致线上训练5天任务中断。
训练需求：并发正确性 Create /a/test.txt 和 Rmdir /a
• 方案一：全串行
• 方案二：文件目录读写锁
• 方案三：客户端事务
• 方案四：服务端乐观事务 + Write串行
内存事务，保障S3/POSIX/HDFS多协议并发正确性。
39. OrangeFS MDS 扩展性？
初现规模：单Volume Leader 30w/s Read，CPU掉底，延迟飙升到秒级别。
训练需求：读支持扩展性
Follower Read，线性扩展读，延迟回归1ms
OP粒度支持Follower Read
• 服务端侧：
•
支持线性一致性读、Cache一致性。
•
根据和Leader的LogIndexGap实时开关Follower Read。
• 客户端侧：
•
管理多个节点TCP连接池，黑名单、重连等机制。
• 管控侧：
•
单节点动态开关Follower Read。
•
Volume粒度动态开关Follower Read。
• 运维侧：
•
1 Leader + 2 Follower + 1 Learner。
•
扩容Learner来提升读能力。
40. OrangeFS MDS 稳定性？
问题暴露：线上磁盘90%容量报警，部分Follower写入失败。
稳定保障：Leader持续发Snapshot，导致Follower磁盘爆满
Raft恢复机制问题？
• KV粒度Recover速度太慢 • Snapshot Ingest SStable，快速恢复
• Log Compaction阈值死板 • Snapshot期间 暂停恢复 Log Compaction
• Follower恢复时触发Leader限流 • 隔离Recover限流状态，避免影响Propose
• Multi-Raft共用资源池，隔离不好 • 支持Busy队列，减小故障面
Ingest SStable
41. OrangeFS MDS 高效 Rename？
1、POSIX/HDFS 文件组织结构是 目录结构。
2、S3 是一种扁平KV结构。
/
/a/
a/
INTERNAL USE ONLY
/a/1.txt
INTERNA
L USE ONLY
绝对路径为 key
b/
1.t
xt
父目录 inodeID + 文件名为 key
42. OrangeFS MDS 高效 Readdir？
一次Scan+多次点查 vs 一次Scan（Dentry/Inode混合存储） ？
43. 阶段二：OrangeFS POSIX 高吞吐？
持续铺量：大模型训练经常反馈读带宽抖动，不稳定。
训练需求：稳定高吞吐读带宽
元数据数据分级缓存，数十GB/s带宽
44. OrangeFS POSIX 读写解耦？
线上边写边读卡顿？
内存快照
45. OrangeFS POSIX 热升级？
一定规模：线上运行版本众多，升级流程复杂，近10w客户端。
内部需求：急需解决客户端 可维护性 问题。
热升级 + 管控
46. 阶段三：OrangeFS 多团队协作（权限隔离）
使用场景：多个团队共享同一个Volume，多端读写，数据有时效性，且有误删除⻛险。
支持多团队高效协作
OFS支持S3 Lifecycle规则并且做了拓展，整体基于Lifecycle来管理子目录需求。
• TTL 过期删除 ：支持子目录级别的过期数据删除。比如大模型训练在界面上 配置 /user/didi/ 30天之后自动删除数据。
• Readonly：支持Bucket/Volume粒度的只读，以及子目录粒度只读。比如训练通过S3接口在某个子目录生产完数据之后，设置只读。
• 权限管理 ：S3 AK/SK 认证、POSIX、Mknod、Read、Write OP粒度管控。
47. OrangeFS 多团队协作（误删除）
线上经常有用户反馈误删除数据，OrangeFS提供回收站功能，已帮助用户恢复误删除的数百万个文件。
• 过期删除：默认回收站保留7天，不同集群可配置，回收站也过期之后，会被CUS清理服务并发的删除元数据和数据。
• 误删恢复：支持恢复单个文件、单个目录、根目录下某个时间点删除的文件。
回收站 扁平KV结构
48. 扫码关注 了解更多
49. THANKS
DataFunTalk # 2024