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

如果无法正常显示，请先停止浏览器的去广告插件。

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