B站模型训练存储加速实践

随着模型训练技术进入规模化应用阶段，提升训练效率与降低算力成本已成为全球AI竞赛的关键突破口。在以集群为单位的常态化运行的模型训练场景中，底层存储系统面临三重核心挑战：需同时实现亿级文件的高吞吐低延迟访问、PB级数据的高可靠存储，以及全系统级的高可用容错能力。本文将系统性解析B站在大规模模型训练场景中构建的存储体系升级方案与工程实践经验。

^{图 1-1 B站模型训练整体架构}

如图1-1所示，B站模型训练架构采用分层设计理念，整体分为三层：

1. 业务应用层：覆盖模型训练、内容安全审核、搜索推荐、电商广告等核心业务场景。

2. 机器学习平台层：提供从数据预处理、模型训练到推理部署的全生命周期管理能力：

3. 基础存储层：集成多种存储服务形成互补生态：

• HDFS：支撑EB级数据高可靠存储

• NAS：提供低延迟共享访问

• BOSS对象存储：自研分布式对象存储系统

目前B站模型训练对存储的需求主要集中在两方面：

（1）数据归集与预处理阶段

• 高吞吐大容量存储：需提供高吞吐、大容量存储介质，类似大数据批处理场景。

• 统一访问接口：数据清洗过程中会访问多种底层存储，需提供统一高速文件访问接口。

（2）模型训练阶段

• 海量小文件低延迟读取：能高效处理海量 KB 级的小文件，且具备高带宽、低延迟特性。

• 高频 Checkpoint 写入：为避免 I/O 抖动对算力的干扰，写入延迟需稳定在毫秒级以下。

结合上述场景，B 站模型训练场景对存储的总体需求为：

• 存储容量：同时满足大容量存储与海量小文件管理两方面需求；

• I/O性能：提供高并发、高带宽、低延迟访问能力，避免 I/O 瓶颈导致训练任务延迟或停滞；

• 接入成本：提供统一的 POSIX 协议访问层屏蔽底层异构存储，简化上层开发接入与运维管理；

• 系统稳定性：存储系统需保障高可用性与读写性能稳定，避免 I/O 波动、节点故障等异常影响训练任务进度及计算资源利用率。

当前 B 站底层存储以 HDFS 为主，总容量达 EB 级别容量可满足需求。但存在以下瓶颈：

1. HDD 介质吞吐性能显著低于 SSD；

2. DataNode 日常高负载，突发任务易引发性能瓶颈；

3. HDD 日均故障率约 0.05%（5‱），存在可靠性风险；

4. 依赖 Java/C SDK 接入，与训练框架兼容性较差。

综上，现有 HDFS 集群难以全面满足 AI 模型训练对高吞吐、低延迟、高稳定性的核心需求，需通过存储架构升级实现突破。

为适配模型训练场景，我们将自研存储体系与主流高速存储方案进行了多维度基准测试对比（详见图2-1）

^{图 2-1 模型训练存储方案对比}

我们调研了当前公司内部使用的NAS存储和业界一些公司采用的PFS等高速存储方案，全SSD介质构建的I/O性能可满足需求，我们还研究了最近开源的 3fs 存储方案，采用纯 NVME 磁盘，IO 性能有明显提升，但存在成本高昂的问题。在数据规模较小时，整体成本尚在可控范围内，但数据量达到一定程度后成本急剧攀升，从成本上来说都不适用于我们。为解决成本问题，业界也有一些PFS+冷热分层的探索， 但进行技术评估后发现存在以下问题：

1. 数据流转复杂：需跨异构文件系统交互，架构复杂度较高；

2. 一致性保障困难：底层或上层数据发生变化时，数据同步较为困难；

3. 运维成本高：数据迁移需额外人力进行数据运营。

最终我们参考业界的已有的方案（如 PCache，Cubefs 等），最终选定基于缓存加速的技术方案，通过Alluxio实现智能缓存管理。相比其他方案具有显著优势：

• 成本控制：复用现网SSD闲置资源，无需额外硬件采购；

• 运维简化：LRU+LFU混合淘汰策略实现自动化缓存治理；

• 协议兼容：通过FUSE提供POSIX标准接口，业务适配成本降低；

• 风险可控：已在推荐系统等场景完成POC验证，故障恢复机制成熟（MTTR<10分钟）。

^{图 2-2 alluxio 缓存加速方案}

如图 2-2 所示，我们当前采用Alluxio 2.9.4版本构建缓存集群，Worker节点部署于HDFS集群的闲置SSD磁盘资源，底层存储兼容BOSS对象存储与HDFS双后端。模型训练流程主要通过以下 2 步实现，一是数据预加载：将训练依赖数据预热至Alluxio缓存层；二是透明访问：通过Alluxio FUSE服务挂载缓存空间，训练任务就能实现数据访问。该方案充分利用了大数据的闲置SSD资源，硬件成本近乎零新增，有效的提升了资源利用效率，存储服务性能实现显著提升，文件访问场景的吞吐能力均得到突破性增强，如图 2-3 所示，在模型训练高频的小文件访问场景中，实测显示数据块读取带宽增长6.3倍，完全满大规模训练任务对I/O性能的核心需求。在实际的生产环境中，模型训练任务在引入 Alluxio 加速后，整体IO 获得了近 10 倍左右的性能提升，整体训练速度提升约 2.5 倍

^{图 2-3 alluxio 缓与 HDFS吞吐对比测试}

但引入Alluxio也带来新的技术挑战：

1. 元数据服务瓶颈：单Master节点支撑亿级元数据时，元数据扩展性成为瓶颈；

2. 故障域变大：组件增多导致系统整体故障域变大，对稳定性要求更高；

3. 容错能力要求：远程访问混部 worker 节点场景下，故障点更多，对容错能力提出更高的要求；

当前基于Alluxio的缓存加速方案已在B站实现规模化落地应用，在生产实践中我们重点突破以下技术挑战：

• 系统稳定性保障：高并发持续读写场景下，需确保缓存系统的高可用性与抗压能力;

• 元数据扩展性瓶颈：面对海量文件规模的 AI 训练场景，通过多种方案提升Alluxio 集群元数据存储容量；

• 写入性能与一致性平衡：平衡数据一致性与写入吞吐量；

• 平台化功能拓展与生态集成：构建统一接入平台降低使用门槛，实现缓存数据可视化管控。

下文将详细阐述各挑战的解决方案与技术实践。

首先介绍一下我们在系统稳定性保障与优化方面的面临的问题，主要集中在master节点，worker 节点，和 Fuse Client 端的稳定性问题。

首先介绍master节点稳定性问题。Alluxio集群采用Master/Slave架构，master节点稳定性直接影响所有缓存数据读写性能，在实际的生产运维中我们针对遇到的问题做了不少优化。

• Checkpoint机制优化

• 问题发现：Alluxio Master的 Journal 机制如图 3-1 所示，在常态化运维监控中发现，Alluxio Master节点的原生Checkpoint机制仅当Journal Entry累积至200万条时触发。实际生产场景中，某集群在完成数据加载后Journal Entry数量达到150万条，此后仅处理读请求导致Entry数量长期停滞。此时若Master节点故障重启，需耗时近30分钟加载Journal日志（冷启动耗时与日志量正相关），严重威胁集群稳定性。

• 优化方案：

• 动态Checkpoint触发策略：实现双阈值触发机制（阈值1. 间隔6小时累计超过1万条Journal Entry，阈值2. 任意时刻累计200w），确保日志回放效率

• 日志存储优化：将审计日志、Journal日志、Metastore日志分离存储至独立NVMe磁盘，规避I/O竞争

• 实施效果：Master节点冷启动时间从25分钟缩短至5分钟

• Master 切换造成 IO 暂停问题优化

• 问题发现：原生架构下Worker仅向Leader Master同步Block元数据，主从切换时需等待Worker心跳周期上报，期间集群处于不可用状态。

• 优化方案：启用Worker向所有Stateful Master（Leader/Follower）实时推送Block元数据

• 实施效果：Master主从切换实际减少明显，从分钟级缩短至秒级

• 元数据一致性修复

• 问题发现：开启 Worker 节点 Block 上报至所有 Master 节点后，在持续数据写入场景下Follower Master的元数据和Leader Master节点信息不一致，主从切换引发缓存数据丢失。

• 优化方案：增加Journal日志，同步 Block 新增信息。 

• 实施效果：Master 节点主从切换，数据完整性提升

• Master故障切换数据完整性保障

• 问题发现：Master节点重启过程中，Worker节点的Block元数据上报与Journal日志回放存在时序竞争。监控发现大量的Block因Journal未完成回放被错误标记为异常数据，导致部分缓存数据损失

• 优化方案：

• 启动流程重构：强制Master节点在Journal日志完全回放后，方开放Worker的Block上报通道

• 实施效果：Master节点切换场景下，数据完整性明显提升

^{图3-1 Alluxio Master 节点 Journal 机制}

Alluxio 作为缓存服务，经常需要同步数据，在生产环境中发现，Alluxio集群在Leader主节点切换时，由于Follower节点未正确继承任务终止状态，晋升为新Leader后会错误重启历史遗留失败任务，导致Worker节点因海量重复任务引发OOM，如图 3-2 所示。我们做了如下修复来解决上述问题：

• Journal Entry 同步 Job 状态信息，Follower Leader 更新 Job 状态；

• Leader Master 节点切换时检查 Load 任务状态。

^{图 3-2 Alluxio 集群Load数据过程}

修复了重复运行 Load 任务的问题后，我们仍然发现Alluxio Worker节点在加载海量数据时频繁触发OOM，如图 3-3 所示，核心问题源于NioDirectBufferPool内存管理机制的缺陷：

1. 碎片化严重：不同尺寸内存块混合存放导致空间利用率低下；

2. 回收机制缺失：无内存水位监控和主动清理策略，碎片内存持续堆积。

对此我们进行了优化，优化方案分二阶段实施：

• 零占用Buffer主动清理

新增后台线程周期性扫描并释放size=0的Buffer链表，消除无效内存占用。

• 阈值触发式碎片回收

设定DirectBuffer内存总量80%为警戒水位线，触发时强制合并未使用的非标准容量Buffer块，结合JVM FullGC协同释放。

经优化后，在 Load 大量数据场景下，Worker节点未发生OOM故障

^{图 3-3 Load 数据导致 worker 节点 OOM}

除上述优化外，我们发现原有的Load调度采用固定时间间隔来下发任务，这种机制在面对目录下包含海量小文件和大型文件的场景时，暴露出其固有的局限性：

• 小文件场景：要求较短的调度间隔以最大化吞吐率。

• 大文件场景：要求较长的调度间隔以避免任务堆积，防止对Worker造成过大的内存压力。

这种“一刀切”的固定周期策略，使得调度器无法在吞吐率和系统稳定性这两个关键指标之间难以取得平衡。为了解决上述挑战，我们对调度架构进行了升级，核心改进如下：

1. 引入基于Worker的并发任务队列：为每个Worker节点引入一个有限任务队列，Master节点会将Load任务分发至目标Worker的队列中，从而精确地控制每个Worker能同时执行的并发任务数量。

2. 建立失败任务的自动重试与故障转移机制：当一个任务在某个Worker上执行失败后，调度器会捕捉该失败事件，并将其重新分配给其他健康的Worker节点进行重试。该机制显著提升了Load操作的容错能力，确保在节点抖动或临时故障等不稳定环境中，依然能保持极高的任务成功率。

在上述对 Master 和 Worker 节点优化的基础上，为进一步应对Alluxio缓存集群异常导致的模型训练中断风险，我们在Fuse客户端构建了多级数据读取韧性防护体系

• 故障实时检测与自动降级、

• 当Fuse Client监测到Alluxio集群异常（如Worker磁盘故障、元数据服务卡顿、RPC超时等场景），基于已读取的OFFSET信息无缝切换至底层存储读取后续数据，如图 3-4 所示，规避传统方案因IO异常引发的训练任务崩溃。触发阈值可通过自定义参数动态配置。

• 智能流量调度策略

• 降级态流量隔离：单文件降级后，其关联的后续读请求自动锁定HDFS路径，防止Alluxio集群抖动引发二次异常

• 渐进式恢复机制：用户可配置自定义重试周期，客户端周期性探测Alluxio服务状态，恢复后自动回切至高性能缓存链路

^{图 3-4 Alluxio Fuse FallBack 机制}

为了保证 Master 端元数据与底层存储（HDFS/S3 等）的强一致性，曾配置 alluxio.user.file.metadata.sync.interval = 0 即每次访问均会触发一次 Sync, 在生产实践中暴露出两类问题：

1.短时大量 sync 导致集群抖动

• 当用户对超大目录执行 du / ls (-l) 等偶发低频操作时，会递归触发大量 sync，导致同步线程池任务暴增；

• HDFS Client 内部锁机制有性能瓶颈，在高并发场景下明显放大 getStatus 耗时；

• 高频创建/销毁锁对象大幅增加 master GC 压力。

2.小文件读取无明显加速

• 平均一次 sync ≈ 30 ms，对 <1 MB 文件，其比例开销过高，抵消了 Alluxio 数据缓存的收益。

为了解决上述问题，我们采取了以下方案:

1. 将 alluxio 中会造成大量 sync 的操作(rename delete ls 等等) 直接走 UFS ，仅保留 getFileInfo 的单点查询操作。由于 du / ls(-l) 命令仍然会大量调用 getattr (对应getFileInfo)，所以在 master 端将 listStatus 结果中的节点信息进行缓存。缓存的时效性与 sync.interval 保持一致。master 上的更新操作会更新缓存，以保证数据一致性。

2. 修改 hdfs client 缓存机制，并在 alluxio master 上使用线程池创建多个不同的 hdfs client 对象，避免持锁消耗，sync 达到10k QPS 耗时可减少 10ms。

3. 将来自 alluxio 的请求直接路由至 hdfs 的Active Node, 避免走 Observer Node, sync 耗时可减少 10ms。

4. 配置 alluxio.user.file.metadata.sync.interval = 10min。

最终在我们线上有大量写的集群中，alluxio sync 平均耗时仍能保持 4ms 左右。小文件(<1MB) 有 2X 读取性能提升且相比 sync = -1 (不同步) 由 55% 的性能差距缩减至 14%。

Alluxio单集群可以承载2-3亿文件时，当超出 3 亿文件时容易出现元数据性能瓶颈问题，我们通过构建路由联邦架构如图 3-5所示实现水平扩展。其核心矛盾源于海量小文件场景下单一Master节点的元数据存储瓶颈，导致文件系统吞吐量急剧下降。为此设计三级扩展体系：首先基于配置中心建立动态路由规则库，将训练数据集按路径特征映射至特定集群，Router节点通过30秒间隔的心跳机制同步最新路由表；其次在Fuse客户端嵌入智能路由决策模块，首次挂载路径时自动匹配目标集群元数据节点，后续请求直连对应集群规避中心化查询开销；同时建立集群弹性扩缩容机制，新增集群仅需注册路径规则即可无缝接入业务体系。

^{图 3-5 Alluxio 路由联邦策略}

模型训练海量小文件问题通过Alluxio 联邦架构和平行扩容得到了一定缓解，但仍然存在元数据节点资源浪费和 IO 性能问题。为此我们引入了小文件折叠合并技术如图 3-6 所示。针对训练场景中高频访问的KB级小文件，采用预聚合写入策略：当文件尺寸低于阈值（默认4MB）时，在数据注入HDFS前自动触发合并引擎，将数千文件聚合成GB级大文件（随机UUID命名），文件尾部开辟索引区——前16字节为二进制头（含版本号、元数据偏移量），后续区域存储JSON格式元数据索引（包含原始文件名、物理偏移量、长度等关键信息）。通过自研SDK实现透明化访问，用户调用SDK 读取数据时自动解析索引并定位数据块。生产环境中单数据集文件量从5800万级锐减至56万，元数据总量压缩98.3%。

^{图 3-6 文件折叠}

在模型训练场景的密集型写入阶段（如数据预处理管道及CheckPoint持久化），Alluxio单副本写入方式如果遭遇节点异常，就会触发写入失败，其异步多副本写入策略在Worker节点异常场景下任然存在相同的风险：如图3-7所示，当单个Worker节点故障时，即使其他副本写入成功，整体写入流程仍会触发ABORT异常，导致已传输数据丢失。这种"单点故障全局失效"的机制导致如下问题：

1. CheckPoint写入中断直接造成训练进度损失，如图 3-8 所示；

2. 预处理流水线数据不一致引发特征工程崩溃；

3. 多副本配置非但未能提升可用性，反而增加资源消耗。特别在高并发写入场景下，故障雪崩效应使集群级写入失败率陡增，成为模型训练流程的核心稳定性瓶颈。

^{图 3-7 Alluxio Fuse 写入问题}

^{图 3-8 训练进度损失}

针对Worker节点故障引发的异步写入数据丢失及CheckPoint中断风险，我们引入直写HDFS模式：在Alluxio Fuse层新增直连HDFS的旁路写入通道，通过存储介质分级与元数据协同机制实现稳定性和一致性平衡，主要设计如图 3-9 所示

1.分层存储策略

• CheckPoint高优先级写入：直连HDFS SSD层，保障低延迟与高持久性（可用性99.95%）

• 预处理数据降级写入：定向至HDFS HDD层，通过HDFS原生多副本容错（自动重试/切换DataNode）规避单点故障

2.元数据协同机制

用户可配置sync.mode=[IMMEDIATE | HOURLY | DAILY]控制同步粒度：

• 即时强一致：写入完成触发Alluxio元数据全量刷新（适用CheckPoint场景）

• 异步批量同步：周期拉取HDFS目录进行元数据同步

实施效果：双写模式下HDFS通道故障屏蔽率100%，CheckPoint写入失败率明显降低，且直写文件仍可通过Alluxio Fuse统一视图读取（延迟可控），实现存储稳定性与缓存加速能力的协同增效。

^{图 3-9 Alluxio Fuse 直连 HDFS 进行写入}

为降低AI开发者使用分布式缓存的技术门槛并提升运营效率，我们构建集缓存管理、策略编排、资源管控于一体的Alluxio 缓存管理平台，提供三大核心能力：

1.多源异构存储统一接入

如图 3-10 所示，支持HDFS、BOSS对象存储等底层存储系统接入，用户可灵活配置读写策略，并通过可视化界面自定义挂载点权限与缓存规则。

2.缓存生命周期工单化治理

• 数据预载与清理：用户提交数据集预热/失效任务后，平台自动生成跨集群同步链路，经多级审批（数据Owner→平台管理员→存储负责人）后自动执行，规避误操作风险；

• 智能配额管控：如图3-11 所示，基于数据集元数据量和存储量双重硬性限制，超Quota任务实时拦截。

3.精细化运营能力增强

通过构建Alluxio元数据仓库分析缓存访问画像，识别低效数据（如30天无访问记录）并触发定时缓存清理任务，提升资源使用效率

^{图 3-11 Alluxio Quota 配置}

在实际运行过程中，针对平台同步超大规模目录（如6000万文件）时引发的元数据服务性能骤降问题，采用动态目录分片同步机制，如图 3-12 所示：将单目录按子目录粒度拆解为独立同步单元，通过并行任务调度规避锁竞争。同步期间启用热路径标记，优先保障高频访问子目录的服务质量，该方案使亿级文件元数据同步对业务透明化。

^{图 3-12 动态目录分片同步机制}

经过上述多维度优化，Alluxio集群已稳定支撑AI模型训练数据访问需求，目前配置多组 Alluxio 集群，支持多种类型的模型训练任务，获得业务一致好评。但随着越来越多的模型训练任务接入，我们计划进一步提升服务能力。以下是当前推进及计划中的主要工作：

1.完善缓存管理策略，定制适合AI数据特征的缓存机制

当前缓存淘汰机制仍依赖集群自身的LRU策略和部分元数据仓库信息。后续将基于训练数据的可替代、可预测等特性，在训练过程中实时和动态的加载和淘汰缓存中的数据，用更少的缓存资源支撑更大规模数据的多模态训练;

2.提升读写稳定性，拓展用户场景

当前Alluxio Fuse在功能支持上仍存在不足，我们计划进一步提升Fuse功能性，如FUSE 多路 IO 扩展, 本地 IO 多链路写入，扩展读写带宽，同时支持用户态共享内存（SHM）技术， 避免内核态与用户态切换带来的性能瓶颈，加速文件访问效率；

3.构建模型训练全链路存储加速方案

完善模型训练存储产品体系，提供覆盖数据预处理→分布式训练→模型推理的全环节存储加速解决方案，实现端到端性能优化。

-End-

作者丨云镜、默菲