LLM 的潮流方兴未艾，智能 Agent 的时代又将到来。存储系统作为支撑人工智能发展的关键基础设施，不仅需要处理海量的数据存储需求，还要保证数据的高速访问和处理能力，以支持复杂的机器学习模型训练和推理任务。
大模型时代，我们需要什么样的存储系统？日前 InfoQ《极客有约》X QCon 直播栏目特别邀请了 DatastratoFounder & CEO 堵俊平担任主持人，与字节跳动技术专家李经纶、JuiceFS 合伙人苏锐、OPPO 分布式存储专家常亮，在 QCon 全球软件开发大会 2024 上海站即将召开之际，深入探讨下一代存储系统的设计与挑战。
部分精彩观点如下：
AI 中的计算瓶颈主要在于计算节点间的通信，而不是存储本身。
文件存储服务的核心是客户端、元数据管理和数据管理。
把数据持久化的任务交给对象存储服务。
利用数据生命周期的搬迁能力，实现数据的冷热迁移。
用户在选择存储方案时，不必追求极致的性能。
在 10 月 18-19 日将于上海举办的 QCon 全球软件开发大会上，我们特别设置了【下一代 DataforAI 技术架构】 专题，讨论如何识别和管理数据资产，掌握数据治理的新方法，通过真实案例和实践经验，了解不同行业如何利用数据技术和 AI 进行创新和转型。
在该专题论坛中，李经纶老师将分享《云上数据湖在 LLM 场景的挑战与解决之道》；苏锐老师将分享《拥抱 AI，我们需要什么样的存储系统？》；常亮老师将分享《为大规模 AI 构建高效数据基础设施的技术挑战与实践》。查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2024/shanghai/schedule
以下内容基于直播速记整理，经过不改变原意的编辑。
堵俊平：近年来，AI 技术（尤其是大模型和生成式 AI）对存储系统提出了哪些独特的挑战？在这个背景下，大家认为传统存储架构在哪些方面最需要调整？
苏锐： 存储系统是开发者日常频繁接触的工具，但它的关注度通常不如数据库。我们实际使用的存储系统主要分为三类：块存储、对象存储和文件存储。文件存储的历史甚至比对象存储还要悠久，它的发展可以追溯到上世纪 80 年代，但在很长一段时间内被大家忽视。这导致我们在 AI 领域寻找合适的文件存储产品时，发现市场上的选择非常有限。
我认为，AI 在存储领域提出的首要挑战是，早期的 TensorFlow 或 PyTorch 设计主要是为了单机训练，而随着大型语言模型的出现，训练逐渐转向了分布式。这就对存储类型提出了新的要求，更不用说存储细节的需求了。
李经纶： 以云上的数据湖为例，数据通常存储在对象存储服务（如 TOS）中，存在几个关键问题。首先是源数据问题，对象存储是一个扁平的元数据结构，当需要列出或查找文件时，它实际上是一个键值对（KV）扫描操作，性能相对较差。其次其 IO 效率并不高，包括读写吞吐量都受到限制。这不仅体现在账户级别的限流，还体现在单个对象的读写限流，这些都难以满足 AI 场景的需求。此外，对象存储的读取延迟大约为 10 毫秒，但在需要 0.1 毫秒延迟的极端场景下，这显然是不够的。
在元数据层面，数据湖中有 catalog 和 table formation 等高级功能。但在 AI 场景中，数据集的管理相对欠缺。许多客户或公司有类似的需求，比如需要一个集中的地方来查找数据集的位置，希望在管理数据集时具备多版本能力，以及在更新时不影响读取等。尽管需求相似，但在实现上还没有一个统一且优秀的解决方案。
常亮： 自 2019 年开源以来，到目前 CubeFS 已经进入了 CNCF 毕业的最后阶段。以我们 OPPO 为例，面向大数据和 AI 等业务场景，面临的挑战之一是海量小文件的存储，可能达到百亿级别的单卷，这在元数据扩展性能方面，CubeFS 于 SIGMOD 曾发表过一篇论文，提出了强一致的可扩展的弹性元数据解决方案。此外，CubeFS 可以作为数据湖的存储底座，除了 POSIX，也兼容了一个名为 HDFS、S3 接口，可以与大数据对接，为 AI 的一站式的存储解决方案提供了基础，从代码开发到数据清洗、再到训练加速以及模型分发，都可以在 CubeFS 找到解决方案。
堵俊平：在 AI 业务中，大量随机 IO、延迟、带宽等问题变得尤为重要。每位嘉宾的存储系统在性能优化方面做了哪些努力？面对高并发数据访问，您的系统如何应对挑战？
常亮： 我们这边 AI 领域中出现的挑战主要是大量的读取带宽需求。在训练过程中，有些场景需要反复读取相同的数据，因此，缓存解决方案就显得尤为重要。数据可以自动加载到客户端单机上，或者我们可以通过分布式部署缓存节点来满足用户在反复训练中的性能提升需求。
在写入方面，AI 训练中的 checkpoint 逻辑可能会涉及到瞬间大量写入。在公有云到私有云的环境中，跨 Pod 网络的性能提升是有限的，但如果我们能够在私有云中利用 RDMA 硬件特性，就可以显著提高吞吐量，从而节省各个阶段的读写时间。
除了缓存策略和硬件加持，我们还进行了内部优化，关注了 P99 延时等指标。CubeFS 的多协议都是基于内部 SDK 的，以 S3 服务为例，内部支持目录查询的路径加速。对于不同的 S3 协议请求，我们也可以实现加速。而 HDFS 是一个基于 SDK 可以直接使用的插件，客户端的优化都可以直接收益。但我们更推荐直接使用 SDK 方式，这样用户可以在用户态进行更多的定制和优化。
苏锐： 过去，高性能计算主要依赖 MPI 范式，这要求计算和存储之间频繁通信，对存储性能和网络稳定性要求极高。但随着 MapReduce 和 AI 的发展，我们开始采用更分布式的系统设计。在 AI 训练中，数据访问模式的变化也带来了新的存储需求。例如，早期的 CNN 模型需要多次迭代使用同一个数据集，可以通过缓存机制来优化数据访问。然而，对于大型语言模型，由于其训练过程中数据的随机抽样特性，传统的缓存策略可能不再有效，需要新的数据预热和存储策略来保证数据访问的低延迟和高吞吐。
在设计存储系统时，我们更注重提供良好的扩展性和性价比，而不是追求极致的性能。因为极致性能往往需要极致的硬件和软件投入，这可能超出业务需求和客户预算。我们认为，AI 中的计算瓶颈主要在于计算节点间的通信，而不是存储本身。因此，我们的策略是深入理解训练负载，确保存储系统足够满足需求，而不是过度投资。
堵俊平：在支持 AI 的分布式存储系统中，如何实现高效的数据调度？是否存在最佳实践，能在保持性能的同时降低成本？
李经纶： 火山引擎对外提供的方案主要还是以 VPFS 这种高性能文件系统为主，它会在训练前将数据预先加载，与 GPU 节点等紧密结合。
我们有遇到过一个案例，一个客户的数据处理流程是一个 pipeline，前一个阶段的输出需要被下一个阶段读取，而这个中间读取的过程会将数据写入对象存储。但这些写入的文件在处理完毕后就不再需要，因此实际上是临时文件。这种情况下，客户遇到了 TOS 的限流问题。我们通过仅缓存的方式帮助客户解决了这个问题，虽然这可能与数据到训练的过程不是特别相关。
常亮： 我们更多地考虑了分布式缓存和数据预热的能力，这实际上与大数据训练中的模型分发密切相关，也涉及到数据调度的问题。未来的应用场景可能会需要一个数据生命周期组件来管理云上数据的迁移，同样，云下的数据也可能需要一个生命周期工具来迁移到云上。
堵俊平：面对越来越多的 AI 任务从私有云延伸至公有云，您的存储系统是如何适配多云或混合云环境的？
李经纶： 在多云功能方面，客户通常自行处理相关的需求。我认为缓存在这方面能够帮助客户解决一些问题，尤其是在他们需要将自己的数据从 IDC 迁移到云端进行训练时。如果客户自己开发程序来管理这些数据，他们需要在训练完成后手动删除数据，这需要自己编写程序来实现。而如果使用公有云的缓存产品，客户可以配置数据的过期时间，数据在第一次访问后到最后一次访问结束，可以设定在多长时间后自动被清除，从而简化数据管理。
堵俊平：在 AI 场景中，数据的安全性与高可用性至关重要。您的存储系统是如何保证在大规模数据处理时的高可用性和容错能力的？在容灾备份、数据冗余等方面，是否有特别的技术突破？
苏锐： 文件存储服务的核心是客户端、元数据管理和数据管理。我们认为对象存储服务如 S3 已经非常成熟，因此我们决定在 S3 的基础上构建服务，将 S3 视为一个大硬盘。为了实现高可用性，我们使用 Raft 协议，通常以 3 节点模式运行，也支持扩展到 5 节点。对于处理大规模文件，我们采用子树分片方法，每个分片都是独立的 Raft group。在容错方面，我们采用全内存元数据管理，实现多副本，并且有额外的异地灾备，确保数据持久性高达 10 个 9 的水平。
常亮：CubeFS 是一个一站式存储系统，适用于 AI 和存算分离等多种场景，注重读写性能，也认为利用 RDMA 硬件提升性能可以给 AI 的一站式服务带来收益，这种收益体现在用户的代码编辑、数据集导入、分布式缓存支持混合云训练、私有云 AI 存储计算服务过程。CubeFS 的元数据子系统是一个基于 RAFT 的强一致性系统，元数据是分片的、使用三副本策略来管理，以提高性能和可靠性。数据层面，我们提供了多副本和纠删码两种存储方案，以平衡成本和耐久性。数据耐久度有多方面的因素，除了副本算法，也涉及快速校验和修复机制，以增强数据的耐久度，我们追求至少 10 个 9 的数据耐久度，但也可以根据需求提供更高的耐久性，用户根据需求来选择。此外，CubeFS 支持跨 AZ 容灾功能，以支持在多个可用区部署数据，确保在某个 AZ 宕机时数据依然可用。
堵俊平：火山在存储系统、数据湖的容错方面，有没有特别的设计？
李经纶： 我们的产品 Proton 是一款数据湖加速器，它在火山引擎上提供透明加速服务。在这款产品中，对象存储是数据的最终来源。我们提供的缓存模式是集群模式，通过云主机节点来缓存之前读取过的数据。如果某个 data Server 宕机，用户最多是无法访问缓存的数据，但仍然可以退回到对象存储中读取数据。
在集群内部，我们通过心跳机制来监测节点状态。一旦发现某个节点宕机，系统会将对该节点的读请求重定向到其他健康的 data Server 上。与 HDFS 的 data NODE 不同，我们的 data Server 存储哪些数据块完全基于客户端的请求。客户端请求什么，data Server 就会根据内部的策略自主决定，包括批量处理策略和 LRU（最近最少使用）以及 LFU（最少频繁使用）算法来支持缓存决策。系统会根据请求来判断哪些数据应该被缓存。在可靠性方面，我们完全依赖于 TOS。
堵俊平：在 AI 训练和推理任务不断变化的场景下，存储系统如何动态调整资源以应对需求波动？您的系统是如何设计扩展机制，支持业务从小规模到大规模的无缝扩展的？
苏锐： 在 AI 领域，文件大小不一，从 100KB 的小图片到 100GB 的大文件，文件数量对存储系统的影响很大。我们把数据持久化的任务交给了对象存储服务，这样我们就专注于元数据的扩展性。
我们的社区版支持多种元数据引擎，适合不同规模的需求。对于大规模文件存储，我们推荐使用分布式 KV 存储，如 TiKV，它能够处理高达数百亿的文件数量。企业版则是为大规模数据和高负载计算场景设计的，拥有自研的元数据引擎，支持元数据的横向扩展。我们采用了一种简单的分区方案，可以根据需要将目录树划分到不同的元数据分区。我们还开发了自动算法来平衡分区选择，以及手动调整接口，以便在线迁移和重新平衡负载，确保不影响业务运行。
常亮： 存储系统在元数据管理上一般采用了两种扩展算法：ALLOC 和哈希。ALLOC 算法支持水平扩展，而哈希算法需要处理键的分裂和迁移，也有两种算法的相互结合，例如先 ALLOC 再次哈希。为了应对元数据的海量存储、解决目录子树高负载热点问题，CubeFS 未使用亲和性组织划分，最终选择了打散形式的元数据管理，以保持使用上的均衡和减少热点问题。对海量大规模文件支持的更好办法是创建多个分区以充分利用资源。为了更好的解决元数据访问的性能问题，使用了内存化 B 树方式来管理元数据信息，同时，CubeFS 也支持基于 rocksdb 的元数据引擎，以节约成本并处理海量小文件。
堵俊平：不同 AI 场景（如自动驾驶、金融、生成式 AI 等）对存储系统有不同的需求。您如何看待存储技术在这些不同场景中的演变？是否需要针对不同场景开发专门的存储解决方案？
常亮： 在 AI 领域，数据收集和存储的场景多种多样，数据可能来自不同的领域，因此数据源也各不相同。这就需要一个数据搬迁的过程，以及可能的持续数据收集。在这种情况下，可能需要本地缓存来处理这些数据，同时还需要一个数据割接的过程。
对于数据训练阶段，不同的算法和模型会对文件系统或存储接口提出不同的挑战。这些挑战与之前提到的大模型生成 AI 的挑战相似，包括处理小文件和保证吞吐性能等，这些都是非常基本且关键的因素。
苏锐： 我们在 AI 领域支持多种行业，包括自动驾驶、生成式 AI、量化金融和生物科技等。这些行业在数据收集和存储上各有特点，比如自动驾驶需要处理来自车辆传感器的大量数据，而量化金融则需要高吞吐量来支持大规模数据分析。
不同 AI 应用对存储系统的要求也不同。例如，自动驾驶模型中要处理上百亿的小文件，量化金融领域则因为研发团队规模大而需要更高的数据吞吐量。我们的存储系统通过缓存和存储解耦，允许数据预热到缓存中，并支持按业务需求划分缓存组，以提高吞吐量，这样既经济又易于实现。
我们还注重提升存储系统的观测能力，帮助维护人员优化存储和计算平台的性能，以适应不同行业的特定需求。尽管行业间的数据处理流程差异很大，但我们都致力于提供能够满足它们吞吐量、IOPS 和读写模式要求的存储解决方案。
堵俊平：在存储系统设计中，有没有做一些冷热数据的调度管理的规划？
李经纶： 在公有云环境中，数据治理策略主要依赖于产品矩阵的解决方案，我们使用了一个名为 Data Leap 的工具专门负责这块。Data Leap 的治理功能能够发挥作用的前提是能够收集到数据的度量指标，这方面的工作主要集中在引擎层面，从 catalog 和数据集层面收集这些度量指标，并将它们提供给 Data Leap。
苏锐： 在处理用户关于自动冷热分层的需求时，我们发现虽然文件系统层面尚未原生支持这一特性，但底层对象存储实际上具备这种能力，在 JuiceFS 可以直接利用，只是用户体验方面还有待提升。我一直在关注用户的需求，希望能够更好地理解他们的想法，并欢迎他们提供反馈。对于冷热分层，首先需要确定哪些数据是冷的，哪些是热的。这可以通过业务管理视角来实现，也可以期待存储产品能够自动提供这些信息。例如，JuiceFS 中的访问时间默认是关闭的，为了性能考虑，但我们可以通过元数据进行离线分析来帮助客户识别冷热数据。
常亮： 为了响应用户对于自动冷热分层的需求，我们的下一个版本将引入数据分层的能力。要实现分层，首先需要了解数据的冷热状态。为此，我们将从文件访问时间获取数据分布，并通过一些细节优化来减少系统的压力。具体实施方面，我们将在卷维度上，从根目录开始，允许用户针对特定目录或文件后缀设置冷热分层规则。这些规则将由生命周期模块驱动，定期触发任务来执行数据的清理、迁移或整合。
我们的目标不仅仅是实现数据的冷热迁移，还希望能够在未来的版本中支持从冷数据迁回热数据，以及考虑跨地域的数据分布。利用数据生命周期的搬迁能力，我们相信这是一个具有很大扩展性和前景的方向。
堵俊平：存储之外，还看到哪些 Data for AI 的趋势？
李经纶： 我们目前面临的一个迫切需求是 Catalog 功能。对于大型模型公司而言，它们本身就是数据公司，运营着 APP 和传统数仓，因此对数据治理的需求是切实存在的。治理这些数据的首要任务是能够有一个统一的平台来查找、查看数据，并了解它们的访问情况，同时管理数据权限，这是至关重要的。其次，在 Catalog 层面，我们发现数据集还缺少类似 table formation 这样的功能，这种功能能够支持多版本的 Sidecar 数据。即使是非结构化数据集，也需要这样的管理能力。目前，我们的客户大多是自行开发系统来管理这些需求，但如果公有云或开源社区能够提供一个标准化的系统，我相信他们会非常愿意使用。
苏锐： 我第一反应也是 Catalog。每个行业都有自己的元数据，并且还在使用文本文件、JSON 或 XML 等格式来管理这些元数据。随着数据量的增加，这些传统方法在灵活性上出现了问题，因此，我认为现在有很多行业都需要一个更先进的 Catalog 系统。
堵俊平：大模型时代，我们需要什么样的存储系统？
常亮： 分布式的种存储系统要迎合这个大模型时代，尽量做一站式的存储服务，同时也要考虑差异。
苏锐： 对于存储的选择，我认为灵活性是至关重要的。我建议用户在选择存储方案时，不必追求极致的性能，也不需要期待一个系统能够永久解决所有问题。关键在于选择一个能够满足当前需求的解决方案，并且能够灵活地适应未来的变化和需求。
李经纶： 在当前的公有云环境中，对象存储已经成为一种事实上的存储标准。各种数据，无论是结构化的还是非结构化的，都趋向于汇集到对象存储中。然而，由于上层应用负载的多样性，对于存储的需求也变得越来越复杂。为了支持这些不同的负载，引入了一层透明的缓存层，如 Pro 层，来支持这些应用场景。这种缓存层最初是为了支持大数据场景而设计的，但现在已经发展到可以支持 AI 场景。这种解决方案可以提供更好的数据访问性能，同时降低延迟，提高数据处理的效率。