滴滴在大模型时代的数据湖存储探索实践
如果无法正常显示,请先停止浏览器的去广告插件。
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