滴滴在大模型时代的数据湖存储探索实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-05 16:34
浙ICP备14020137号-1 $bản đồ khách truy cập$