当前位置：首页 > news >正文

知乎：多云架构下大模型训练，如何保障存储稳定性?

news 文章来源：https://blog.csdn.net/JuiceFS/article/details/137109990 2024/11/15 21:07:49

知乎，中文互联网领域领先的问答社区和原创内容平台，2011 年 1 月正式上线，月活跃用户超过 1 亿。平台的搜索和推荐服务得益于先进的 AI 算法，数百名算法工程师基于数据平台和机器学习平台进行海量数据处理和算法训练任务。

为了提高系统的易用性和灵活性，知乎实施了多云混合部署架构，允许不同云上的作业和服务透明地处理文件，且用户可以在容器中灵活与文件交互，无需关注文件的具体存放位置。

面对多云混合部署架构的需求，知乎于 2022 年引入了 JuiceFS 社区版，创建了一个可跨多个公有云使用的分布式文件系统。这一系统在性能上满足了大规模读写操作和用户实时交互的需求。针对大规模的 LLM 训练等高性能需求场景，知乎又采用了 JuiceFS 企业版，以保障 Checkpoint 写入的稳定性，并提升 GPU 效率。

目前，知乎已在 JuiceFS 社区版上存储了 3.5PB 的数据，主要用于机器学习应用，而企业版则用于性能要求更高的任务。本文将分享知乎如何在多云混合部署架构中构建存储层、保障 LLM 训练稳定性以及跨云 PB 级数据迁移的经验。

01 机器学习平台的业务需求与挑战

机器学习平台架构

知乎的机器学习平台服务于知乎及面壁智能的数百名算法工程师，这个平台依托于先进的数据处理和机器学习技术，使工程师能够有效地处理海量数据，并进行复杂的算法训练与推理任务。

应用层：知乎的核心推广业务涵盖了首页推荐、广告和搜索功能。作为一个丰富的图文生态系统，知乎不仅包含文本内容，还拥有大量图像资源，因而在视觉和自然语言处理（NLP）方面均需机器学习技术支持。自去年起，大型语言模型（LLM）的需求持续上升。

机器学习平台内部组织：用户通过界面（UI）与命令行工具使用机器学习平台的各种功能。这些功能模块覆盖了数据集管理、模型训练、笔记本、推理服务和镜像构建。

知乎与面壁智能公司展开深度合作，共同开发大型语言模型。面壁智能，同时还运营了 BMB 社区，BMB 社区提供了专门针对大型模型训练的框架 BMTrain 训练引擎，同时还有一些算法同学使用 DeepSpeed。在网页搜索和推荐场景中，我们广泛应用了 PyTorch 和 TensorFlow。在模型推理方面，目前涵盖了多种在线服务组件，包括 vLLM 、NVIDIA Triton 和我们自主研发的 CPM server，这些组件均部署在多个 GPU 集群上。

底层存储：我们采用 HDFS、JuiceFS 和云盘作为基础的物理存储解决方案，支撑整个机器学习平台的存储需求。

业务需求

POSIX 协议支持：在模型训练，特别是使用笔记本进行新模型探索的过程中，经常出现对大文件读写的需求，如读取样本数据和写入 checkpoint。此时，通常会利用各种开源训练引擎或框架直接从文件系统读写数据，这就使得对 POSIX 协议的支持变得至关重要。这也解释了尽管我们最初采用了 HDFS，但由于其在 POSIX 协议支持上的不足，我们没有对其进行持续的迭代。

为了实现支持 POSIX 协议，我们期望以简单的挂载方式将文件系统直接集成进容器，允许程序通过标准 Linux IO 接口进行文件操作。这样不仅可以保证所有容器中文件内容的一致性（即使是在弱一致性的条件下），而且还能满足随机写的需求，这对于我们的应用场景至关重要。此外，从系统管理角度，我们不仅需要实现配额和权限控制，还希望提供可观测性指标以便于问题诊断。
扩展性：对于大型模型未来规模的扩大或其他潜在变化尚属未知，故而扩展性成为我们考量中至关重要的因素。
性能和成本：在当前的降本增效的大环境下，成本控制成为了一个关键因素。
系统管理：我们希望多租户的文件系统能够实现权限和配额管理。作为一个支持多租户的文件系统，我们希望它能够有效地进行权限和配额管理。

技术挑战：多个云端并发访问

对于没有自建机房进行大模型训练的公司，依赖公有云的 GPU 资源成为必然选择。然而，单一公有云服务商往往无法提供充足的 GPU 配额，导致必须跨多个云平台分散 GPU 资源。在这种情况下，为了避免在不同云平台之间进行数据的重复拷贝，我们迫切需要一个能够在多个云环境中同时运行的文件系统。

理想的多云架构如下所示，能够实现数据的单一集群存储，跨多个云平台访问和处理。目前，知乎已经在使用四家公有云服务商的资源。

JuiceFS 相关调研

部署方式

在选型时，我们期望找到一种适合云原生部署的解决方案。在这方面，JuiceFS 展现出了领先的优势。同时，我们也考察了 JuiceFS 的一些竞争对手，发现基于容器存储接口（CSI）的部署方案尚未达到完善，而 JuiceFS 的实现相当不错。

系统可观测性

JuiceFS 提供了一个功能丰富的内部指标监控看板，使得查看系统性能变得十分便捷。社区版已包括若干关键的全局统计指标，如吞吐量、I\O 操作和延迟等。企业版提供了更细致的监控指标，能够对每个缓存服务和客户端的性能指标进行详细跟踪。这对于故障排除和性能监控尤其有价值。

02 多云混合部署存储架构设计

我们目前管理四个不同的云环境，每个都有自己的 Kubernetes 集群。我们的数据分为两部分：一部分存储在 HDFS 中；另一部分则由 JuiceFS 的元数据驱动和 S3 共同构成 JuiceFS 集群。

不同的集群能够通过网络访问 JuiceFS 和 HDFS。为了优化访问速度，我们将 JuiceFS 和 HDFS 部署在同一云环境中，实现内网访问，而其他云环境则通过专线访问。这一部署策略在云环境跨地理区域部署时，对性能有一定影响。例如，若前三个云部署于北方地区，如内蒙古或北京附近，性能通常较好。相反，如果第四个云部署在西南地区，可能导致更高的延迟。

集群面对两种主要需求：离线训练任务和配备交互式笔记本的任务。这些任务在 Kubernetes 环境中通过 JuiceFS CSI Driver 直接挂载，使得整个过程更为高效优雅。虽然 Alluxio 采用的是本地存储（Local Storage）方式，相对来说较为简单直接，但实际上仍然可行。关键在于容灾能力——需要保证物理机上的进程运行稳定，这是一个至关重要的考量。如果稳定性不佳，可能会导致服务不可用的情况发生。

HDFS 以存储样本数据为主，算法工程师和数据工程师一般在大数据平台上完成数据的处理和准备工作后，上传至 HDFS，Alluxio 负责管理这些 HDFS 数据。这部分数据在模型训练和交互式访问期间处于只读状态。

JuiceFS 则被用作保存 checkpoint 的输出目录，同时也为交互式 Notebook 提供统一的存储解决方案，包括 Notebook 中的临时内容，如模型下载、软件安装及编译结果等，都存储于 JuiceFS 中。由于 Notebook 具有状态，容器的任何故障重启都可能导致大量状态信息的丢失。通过挂载 JuiceFS，我们能够保留存储部分，这对于使用交互式应用的用户而言更为友好。

03 大语言模型训练的挑战

写 Checkpoint 卡住问题

我们的集群内同时运行着交互式任务、SFT\Alignment Job 和 Pretrain Job 等多种作业，这些作业生产 checkpoint 的数据量通常超过 100GB，有大规模模型加载的需求。初始时，我们采用 JuiceFS 社区版本应对这种大规模文件读写需求。但是，我们注意到在执行写操作期间，CPU 使用率急剧上升（如下图所示），最终导致集群变得不可用。这个问题使得团队成员在使用笔记本和执行其他任务时遭遇了严重的系统延迟，严重影响了整个集群的运行效率。

在深入排查集群性能问题时，我们发现 CPU 资源耗尽主要是因为使用的数据库引擎 Redis 的 CPU 资源被完全占用。同事在审查 Redis 的日志时注意到一个特殊的审计通知，该通知表示在文件检查完成之后会自动触发一次扫描操作。这个扫描会针对所有超过 6.4GB 的文件，不管是通过手动操作还是 API 调用设置的文件大小，均会启动此扫描。在 Redis 单线程模式运行下，这种扫描在 CPU 资源已经达到使用极限的情况下会阻塞其他所有请求。

稳定性问题复盘与解决方案

在排查系统卡顿原因的过程中，我们识别出系统延迟是由于 setattr 操作执行时间长达约 577 秒所致。通过审查 JuiceFS 的代码，我们注意到 JuiceFS 每项操作都伴随着相关信息的打印，这些信息帮助我们迅速定位到了问题操作及其大致耗时。然而，日志中存在一项小瑕疵：它仅展示了文件的 ID 而非路径。尽管这一点增加了问题解决的难度，但我们最终还是成功地确定了问题所在。

深入分析问题根源后，我们还研究了 PyTorch 的源代码。我们发现在 PyTorch 保存数据时，每个 Tensor 被作为一个记录增量存储至 zip_file 中。在这一增量写入过程中，会导致文件大小的修改，并触发文件的 truncate 操作。这种对文件大小进行重置的需求激活了之前的扫描操作，并导致它持续了相当长的时间。

同时，我们了解到 JuiceFS 会对文件拆分，一个文件首先被拆分成固定大小的 Chunk。每个 Chunk 可以由一个或者多个 Slice 组成，每个 Slice 的长度并不总是相同，这意味着无法简单地通过累加 Slice 长度来计算文件的总大小。因此，每当文件末尾添加或修改内容时，都需要重新计算文件的整体大小，这一过程涉及到遍历文件中的所有内容。

面对这一挑战，我们考虑了两种解决方案。

第一种是避免对大文件进行增量写入，不使用 PyTorch 的 save_checkpoint 接口，而是首先将数据写入本地文件，然后通过移动（move）操作将其传输到 JuiceFS 中，以此保证数据的连续性和完整性。

第二种解决方案是采用 JuiceFS 企业版来彻底解决这一问题。JuiceFS 企业版元数据引擎性能更优，能够更有效地管理大规模文件操作。

我们最终决定采用 JuiceFS 企业版。主要考虑是，我们无法完全避免潜在的问题，也不可能强制所有人都遵循避免增量写入 checkpoint 的规则。一方面，由于参与人员众多，实现全员一致行动较为困难；另一方面，社区代码不断迭代更新，我们的许多代码是基于开源项目的，用于后续的原型验证。在这种情况下，修改他人的代码并不是一种可行的长期策略。

JuiceFS 企业版元数据服务性能

关于元数据的性能，我们最关心的是其并行度是否具有可扩展性。下面这两张图分别显示了 JuiceFS 企业版 Rename 和 Delete 操作的性能，即事务处理速率（TPS）随并发线程数增加的变化情况。分别对比了 OSS 、HDFS 和 JuiceFS。

JuiceFS 在执行重命名操作时，随着并发线程数的增加，TPS 呈现出稳定的线性增长，远超 HDFS 和 OSS 。

JuiceFS 在执行删除操作时也表现出类似的趋势，其性能同样显著优于 HDFS 和 OSS。

基于这些数据，我们选择了 JuiceFS 企业版，因为它在处理并行操作时显示出优越的扩展性。尽管性能报告中未提供我们最为关心的 truncate 类型操作的数据，但从这些图表中我们可以推断，随着并发度的提高，JuiceFS 能够有效地扩展其事务处理能力，表现出比 Redis 社区版更强的性能，因此我们选择企业版来解决我们在 LLM 训练时遇到的性能问题。

04 PB 级数据跨云间数据迁移

随着对对 GPU 的需求量增加，我们也陆续引入了新的机房；同时由于主数据中心的变动，我们还需要将之前小型机房的存储迁移到更大的存储系统中。

社区版

迁移工作主要包括两个阶段：全量迁移和增量迁移。在全量迁移阶段，我们主要采用离线备份方法，即将 S3 中的数据迁移到新的存储系统中。在这个过程中，必须确保有专用的带宽，以防数据迁移过程中影响正常业务。

同时，我们还需要考虑两个云平台之间可能存在的带宽限制，因为这些限制可能影响到集群的整体稳定性。因此，必须提前确认可用的带宽情况。还要注意，S3 网关可能对账户、IP 或其他条件有所限制，这要求我们与相关方进行沟通，争取获得尽可能大的带宽限额以保障离线备份工作的顺利进行。以往的经验显示，大约 4PB 的数据需要一周时间来完成备份。

T0- T1 阶段

旧集群：含有从 T0 到 T1 时段的所有数据以及原始数据。
新集群：从 T0 时刻开始包含所有数据，但不包括该阶段增量数据和元数据。
注意事项：考虑增量备份。离线备份过程可能因为几百 TB 数据量而耗时约一天，时间受限于 S3 网关可能的进出限制。

T1- T2- T3 阶段

新集群：到 T1 时刻，新集群应更新至包含 T1 时刻的所有数据。随后的增量数据量相对较小，仅有一天的数据量，简化了迁移过程。
注意事项：
离线备份过程中，数据扫描是主要耗时环节，可能需数十小时处理 3.5PB 的数据，而非数据传输。因此，提高带宽对加速备份帮助不大。需要进行细粒度的迁移，并确保两边数据的一致性。
中断文件的访问：这时需要摘掉存储并发送通知，告知所有用户暂时停止使用。然后开始进行元数据的拷贝以及从 T1 到 T2 的增量拷贝。根据我们的经验，200TB 数据可能需要数小时的时间来处理，直到 T3 时刻，整个集群才能满足需求。新旧集群是完全相同，恢复应用。

企业版

企业版的迁移过程与先前的方法相似，但显著的差别在于企业版的双写功能。在完成首次增量迁移后，需要利用这一功能来进行数据同步。此时，必须暂停所有文件访问，然后重新启动任务和笔记本，并配置双写设置。在双写阶段，系统仍将使用原有的存储，此操作对业务的影响仅限于几分钟。新存储将在 T3 时刻启用，我们完成这个过程大约用了两天时间。

接下来的步骤是切换双写中的组件，并把业务 Pod 节点指向新的集群。这个切换需要服务短暂中断，对业务的影响同样是分钟级别的。当到达 T4 时刻，过程将会很快，此时业务方已经开始使用新存储，完成对齐后需要关闭并重新配置双写功能。

我们发现增量迁移是迅速的，实际测试结果显示也仅需几分钟。这一增量迁移可以在启动作业和笔记本后进行，不会影响业务运行，但需要注意的是，在许多关键任务中，重新启动可能是不被接受的。因此，重新启动的时机通常不取决于迁移的完成情况，而是由业务方的工作中断能力决定。

尽管整体迁移时间没有缩短，但企业版的影响对业务运行的干扰更小。特别是在企业内部，如果操作影响到整个平台，那么企业版的优势会更加显著。

跨云间数据迁移注意要点

全量数据拷贝：需要考虑的关键因素包括数据拷贝的并行程度、公共网络带宽以及双方 S3 网关可能的流量限制。而在进行增量数据拷贝时，关注点在于离线任务的耗时，旨在一次性完成而无需重复执行。

增量数据拷贝：主要的时间消耗发生在对 S3 数据的扫描上，而不是数据的实际拷贝。如果能预先知道用户写入的具体目录，那么将大幅缩短增量拷贝所需的时间。此外，JuiceFS 的同步工具能够实现对指定文件目录的精确同步。

流程优化：最理想的做法是在网络断开后执行元数据的拷贝。我们在使用社区版进行同步的初次尝试中，并没有先行断网，结果在元数据同步后发现数据丢失的问题。JuiceFS 强调数据完整性，以元数据为准确依据。因此，在社区版中进行迁移时，我们必须确保在业务完全停止后才开始元数据同步。

社区版 JuiceFS 与企业版 JuiceFS 迁移方案对比：在执行文件系统的迁移过程中，我们同时对 JuiceFS 社区版和企业版进行了迁移操作。社区版分别采用了以 Redis 和 MySQL 作为元数据管理的两种配置。经过全面的比较后发现，社区版在迁移期间的影响业务时间较长，且迁移过程极易受到增量数据量的影响。

与此相反，企业版的迁移能够保持 JuiceFS 服务的持续可用性，尽管这要求业务方进行 3 次重启。正确选择重启时机是至关重要的，如果处理得当，对业务的影响可以降至最低。

05 小结

目前，知乎已在 JuiceFS 社区版上存储了 3.5PB 的数据，主要用于机器学习应用；针对那些对性能有更高要求的任务，如 LLM 训练的 Checkpoint 写入阶段，知乎采用了 JuiceFS 企业版。基于 JuiceFS 确保了跨多个公有云的数据操作的灵活性和高效性。JuiceFS 提供完全的 POSIX 兼容性，支持内部多样化的数据写入需求，性能方面能够实现实时交互的文件读写、与主流 Kubernetes 集群的无缝集成，并且提供了详尽的云应用文档及部署案例。

希望这篇内容能够对你有一些帮助，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。