人工智能时代，滴滴 OrangeFS 数据湖存储的探索与实践

原创

于 2024-09-05 20:30:45 发布 · 2.1k 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能

项目背景

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

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

机器学习等业务数据非常多，最少百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文件系统中，由机器平台挂载训练。