AI 场景下的对象存储 OSS 数据管理实践
摘要:本次分享的主题是 AI 场景下的对象存储 OSS 数据管理实践,由阿里云技术专家明锦分享。主要分为两部分:
1. AI 场景下对象存储实践方案
2. OSS 常用工具介绍
今天将为大家介绍 AI 场景下对象存储的相关使用。其主要分为两部分:首先会概述一下典型的数据处理流程;接着会分享一些相关工具的使用和实践经验。
01. AI 场景下对象存储实践方案
1.1对象存储在 AI 场景下的应用与实践
首先简要介绍一下 OSS。OSS 是目前云上存储服务中几乎成本最低且弹性最强的一项。无论是 AI 领域,还是之前提到的临床数据和临床数据库,都广泛采用对象存储作为其在云上的数据存储方案。而在 ADC 场景中,用户可能更倾向于使用 NAS 或 HDFS。
在云端领域,OSS 无疑是一个不可或缺的存储系统。近年来,随着AI 技术的快速发展,大部分接触到的AI 领域客户,都会采用多种存储系统组合使用的策略,这其中包括CPFS、NAS 以及 OSS 等。他们之所以这样做,主要是因为 OSS 具有较低的存储成本,但同时,客户在应用中又有较高的性能要求。因此,他们通常会将大量的原始数据存储在对象存储上,而对于需要处理或分析的数据部分,则会根据业务需求迁移到如 NAS 等其他存储系统上,以便在这些系统上高效地进行 AI 训练。
然而,随着近年来 AI 技术的蓬勃发展,尤其是对数据需求的急剧增加,AI 所处理的数据规模呈现指数级增长。在这种情况下,直接进行数据的迁移在能效比上显得不再那么合适。近一两年来,我们接触到的客户呈现出一种趋势,即他们越来越倾向于直接在对象存储上存储并使用数据,以减少在不同系统间的迁移。因此我们也期望对象存储能成为未来云上 AI 训练和推理服务的数据基石。
1.2对象存储在 AI 场景下的应用与优势
下面介绍一下在 AI 场景中,对象存储如何在整个数据流中发挥作用。在数据获取阶段,大多数客户自然而然地选择了对象存储。相比其他存储服务,如 NAS 或其他系统,它们通常采用 RPC 接口,上传数据相对不便。而对象存储则提供 HTTP 接口,使得通过手机或网页端上传数据变得十分便捷。此外,对象存储还具备跨境数据复制的能力。这意味着,无论你是在海外还是在北京收集的数据,都可以轻松复制到香港、上海等 GPU 集群集中的地区,从而方便你的使用。
此外,在数据处理阶段,特别是数据预处理环节,许多客户仍然更倾向于采用大数据处理流程来处理 AI 数据,例如使用 Spark 等工具,而我们也充分考虑到了客户原有系统的使用情况。许多客户可能已经将他们的技术栈从传统的 IDC 迁移到云端,因此他们可能更倾向于使用 HDFS 这类接口。
现在我们在对象存储上提供了两种接口:一种是对象存储的原生 API,另一种是与 HDFS 兼容的 API。这样,客户在使用大数据程序进行数据预处理时就有了更多的选择。例如,近年来在国外备受欢迎的 ClickHouse 系统,它能够直接连接云上的对象存储,并使用对象存储的 API。而对于一些较老的 Hadoop 版本以及 Spark 版本,它们与 HDFS 的兼容性更好,因此可以通过使用相应的 SDK 来实现较为平滑的迁移。
在数据处理完成后,客户通常会将处理后的数据重新写回对象存储,以供后续的训练阶段使用。在训练阶段,我们向客户提供两种推荐的使用方式。第一种是使用 OSS SDK,这是最常见的方式。例如,如果你使用 Python,那么就可以利用 Python 版本的 OSS SDK。在使用 OSS SDK 时,有一些技巧需要注意。由于 OSS 的 Python SDK 是基于 Python 语言开发的,其效率可能不是特别高。因此,客户可能需要更多的 CPU 核心数来提升数据下载的速度。另外我们即将推出一个名为 “OS Connector for AI and ML” 的工具,这实际上是一个基于高性能库的组件。与 OSS SDK 相比,这个工具的主要区别在于其性能提升上,具体有两个主要方面的优化。
第一点是它显著提升了训练阶段的数据下载速度。举例来说,以往在使用 OSS SDK 时,视频等文件通常是通过单个 HTTP 连接完整下载的。但在 OS Connector 中,文件可以被分割成多个部分,比如一个 100MB 的文件可以通过 10 个并发请求,每个请求下载 10MB 的数据块,从而大幅提升下载速度。在之前的 OSS SDK 中,客户可能需要自行实现这样的功能。
第二个优化则是 IO 方面的改进。以往 SDK 中的 IO 操作是同步进行的,而在 OS Connector 中,根据不同的操作系统,它底层可能会基于 AIO 或 EIO 来实现异步的 IO 操作。这样一来,它对客户端的资源开销会更加友好。
目前在训练阶段更倾向于推荐客户进行大规模训练,并鼓励他们使用新开发的 Always Connect 程序。该程序预计将在八月中旬正式推出,届时欢迎大家进行体验。目前,该程序已经开发完成,正处于最终的发布准备阶段。
在训练阶段,当前的 Check Point 通常会被写入到 NFS 系统中。由于写入 Check Point 的时间越长,训练集群中的 GPU 闲置时间也会随之增加。因此,这一环节对写入吞吐量有着极高的要求。目前,大多数客户在多轮训练过程中,仍会选择将 Check Point 写入到 NFS 中。当然,最终的训练结果判断还是会返回到相应的存储或评估系统中来。
作为整体数据处理流程的一部分,接下来是验证和微调阶段。如果仅是对模型进行验证和微调,实际上还可以选择 OSS 或 OSSFS 这两种方式中的任意一种。其中 OSSFS 的主要特点是能够将 OSS 的存储桶模拟成本地磁盘,这意味着在机器上,你可以通过 Post 接口来访问存储在 OSS 中的数据,仿佛它们就存储在本地一样。
它的缺点是 QPS 会有所放大,因此不太适合在大规模训练阶段使用。比如平时经常能看到很多 PR 强调 AI 训练对 QPS 的高要求,而这类宣传很常见。实际上,背后的逻辑是这样的:比如训练一个图片模型时,需要通过 Post 接口 Open 图片,可能还需要进行一些 State,接着 Read 图片数据,最后再 Close 接口。
它的元数据操作特别多,因此通常得出的结论是,在训练阶段,它对 QPS 的要求会非常高。而 OSSFS 是模拟文件系统接口的,所以它的 QPS 最终都会反映到对象存储上。相比之下,一些专门的 Connector 对 QPS 进行了优化。例如,对于 Open 和 Close 这类操作,在对象存储中并不存在对应的接口,因此这些连接器也不会执行这些操作。总体来说,这些连接器相较于通过 POSIX 模拟的文件系统,其 QPS 会更低,但性能相对来说会更好一些,因为避免了不必要的元数据操作。
最后进入模型的推理阶段。在推理阶段,不涉及大量的文件加载和 QPS 操作。因此推荐的工具包括 OSSFS、OSSDK,以及 OSSUTO,这些都可以在推理阶段使用。此阶段的主要需求是尽快将模型加载到机器上,所以对下载速度有较高的要求。在这里将 OS 提供的主要能力主要分为三个部分。
第一个阶段是数据获取和数据预处理阶段。这一阶段主要强调的是便捷性,包括便捷的上传功能,以及与以往的大数据处理数据库程序的兼容性,这些特性能够很好地帮助客户实现对接。
而在训练阶段,主要的要求则是弹性能力。而 OS 的横向扩展能力非常强大。就像刚才提到的,当我们需要下载 100 个视频文件时,可以将其拆分成 10 个请求并行处理,这就要求后端服务具备很高的横向扩展能力。
此外,在推理和微调阶段,我们要求加载速度较快。同时,系统还支持类似 Final 的接口,便于客户进行小规模文件的使用和操作。
1.3 OSS 在模型推理中的应用及优化
随着数据量的不断增加,训练对带宽的需求实际上也越来越大。然而,在大数据量的情况下,对延迟的需求相对而言并没有那么高。因此在国内的主要区域,如北京、上海、杭州和深圳对 OSS 进行了优化,主要手段是提升了整体的网络带宽能力。在这些区域,针对 UID 维度的账号及带宽流控,都默认设置为 100G。这意味着,无论你在哪个区域开设一个 UID 账号,只要在这些主要大区运行高并发任务,都能够达到 100GB 的吞吐量。这样的优化在训练任务以及以往对延迟不太敏感的离线分析业务,如大数据离线分析中,效果是比较明显的。
02. OSS 常用工具介绍
接下来将主要介绍在整个流程中提及的几种工具,并从中挑选出两种,以供大家在后续的实验中进行实际操作。
这里简要介绍一下各个工具的特点,具体列举如下:
第一个工具是 OSUQ,它是一个命令行工具,主要用于数据的迁移或牵引。比如,当你需要进行某些实验时,可能会希望将数据下载到本地进行使用。需要注意的是,在对象存储 OS 中,并没有传统意义上的文件夹概念,所有内容都是以对象的形式存在。所谓的“文件夹”实际上也是模拟出来的。而 OSUTO 则可以将某个模拟文件夹下的数据整体迁移或复制到你的本地或其他数据系统中,从而让你在进行实验时,数据下载变得更加便捷。
而另一种 OSUTO 的用法是,实际上有些真实客户会使用 YSQ 来下载他们的模型。这些客户会将模型下载到本地后,再通过其他系统从本地加载这些模型。一个比较典型的例子是,某些可能不支持直接从云端访问数据,而默认只能从本地加载数据。因此,如果你需要在这样的 Decision VUI 上进行实验,除非自行修改其源代码以支持云端访问,否则最方便的方式就是通过 OSUTO 将模型或数据下载到本地,然后再进行实验。
而 OSSFS 的一个显著特点是能够提供文件接口。例如,在一些产品化的组件中,它提供了从模型开发、训练到最终微调的完整链路支持。这些组件内部集成了 FS 接口。尽管当前它使用的不是 OSS,而是类似的另一种 FS 系统,但原理是相通的。这一设计使得客户在训练阶段编写程序时,与在推理阶段的体验完全一致。所以你可以将对象存储视为本地磁盘来使用,无论是在进行实验、训练还是推理时,操作方式都相同,从而确保了用户体验的一致性。
第三个是 PYA SDK,它在 Python 框架中被广泛使用。对于大多数中大型、专注于 AI 领域的客户而言,如果他们在使用 OSSFS 并追求高性能时,通常不会选择 OSSFS,而是会采用 OS 的 Python CDK。然而,使用 OS Python CDK 需要较强的开发能力,客户需要自行进行并发控制和文件切片的封装,以达到最佳性能。
第四个是 Python STK 提供的更加便捷且性能优化的接口。而 OSS Connect for AI/ML 无需挂载,它实际上是一个库,与 OSS 的主要区别在于 OSS Connect for AI/ML 可以直接作为 SDK 使用,从而在使用时感觉更加云原生。在微调和线上训练阶段,它的性能也会更加出色。
最后两个工具是最常见的两个工具:一个是 Go SDK ,另一个是 Go SDK V2 。这两个工具的主要区别在于使用方式。在性能方面,它们实际上差别不大。在某些特定的机器学习领域,比如图像检测,数据文件通常都非常大。如果客户对 OSS SDK 的特性,特别是接口特性不够了解,他们可能会直接使用 SDK 来进行上传和下载操作。
在 Go SDK V2 版本与 V1 版本相比中,当客户需要大量下载生物数据时, V2 版本的性能会更好。这是因为 V2 版本做了并发下载的封装。具体来说, V2 会自动将一个 5GB 大小的 DNA 序列文件拆分成大约 50MB 的小块。然后,它利用 Go 语言的 Goroutine 实现高并发,将这些小块数据并发下载下来,从而达到更好的性能。
下面重点介绍一下在后续实验中可能会用到的两个工具。第一个是OSSFS。 OSSFS 的使用方式主要有三种。第一种是默认模式,其原理是:当客户从 OS 下载数据时, OSSFS 会默认将下载的数据临时缓存在本地,并在关闭时清理这些缓存数据。因此,在默认模式下,数据会首先被写入到本地的磁盘上。
第二种模式是缓存模式。在这种模式下与默认模式类似,写入数据同样会先落盘。但不同之处在于,关闭时它不会清理这些数据,而是将它们保留在磁盘上。这样,当下次进行重复访问时, OSSFS 可以从磁盘上直接读取数据,以提高访问效率。
这两种模式实际上都受到本地磁盘性能的影响。在阿里云上,不同磁盘类型的性能是有限的。例如, P10 和 PL1 类型的磁盘性能就存在差异。通常,性能较差的磁盘可能只有大约 150MB/s 的读写速度,而性能较好的磁盘则可能达到几百 MB/s 甚至更高。因此, OSSFS 的性能与所使用的磁盘类型直接相关。
第三个模式是自动模式,旨在避免上述两种模式受磁盘性能限制的问题。在自动模式下,数据实际上不会落盘。它会直接从对象存储上下载并缓存到内存中。当关闭时,数据会从内存中释放。这种模式能够有效避免磁盘性能的影响,特别是在连续下载大文件时,自动模式的效果尤为显著。
在此对 OSSFS 在模型加载性能方面也进行了优化,分别对 5.6GB的 CKPT 模型和 8.5GB 的 SafeTensor 模型进行了加载测试。与 1.9.1 版本相比,在 1.9.3 版本下,模型的加载性能得到了显著提升,大约提高了 3 到 4 倍。
接下来要介绍的是 PSDK 。客户实际上可以通过自己封装并发 SDK来提升其性能。这里有一组简单的测试数据:在并发数为 10 和并发数为 1 的情况下, SDK 的平均带宽性能大约提升了 10 倍,而峰值带宽则提升了约 6 倍。但需要注意的是,这种方法需要客户具备一定的开发和维护能力。
Python Connector 实际上是将之前提到的需要客户自行操作的一些功能封装成了库。它与 S3 的库有相似之处。去年, S3 推出了一个派生 Compute 功能,而在今年八月中旬,我们也会推出 OSS 的类似功能。该功能的主要作用是提升数据处理速度,并避免了数据的挂载过程。
上图是 OSS 常见工具的一些资料。所有的工具现在都是开源的,大家可以去 GitHub 上查看我们的代码。如果有一些特殊的修改需求,也可以自行下载代码进行修改。同时,如果大家对工具有更好的建议或意见,也欢迎向我们提出。