《Alluxio：2024年Alluxio助力AI模型训练加速宝典2.0（实战篇）（80页）.pdf》由会员分享，可在线阅读，更多相关《Alluxio：2024年Alluxio助力AI模型训练加速宝典2.0（实战篇）（80页）.pdf（80页珍藏版）》请在本站上搜索。

1、引言背景&Alluxio赋能AI场景小红书|加速云端机器学习-Alluxio在小红书的实践一、面临的挑战二、多云数据加速层三、小红书实践案例四、未来规划知乎|Alluxio AI助力知乎千卡模型训练一、混合云架构，带来便捷与挑战二、知乎的探索历程三、持续合作，保持探索B站|Alluxio 在B站AI训练场景的应用一、B站AI的训练场景二、Alluxio 在 AI 训练场景的应用三、未来规划辉羲智能|Alluxio在自动驾驶模型训练中的应用与部署一、自动驾驶数据闭环二、算法训练：NAS三、算法训练引入 Alluxio四、Alluxio 部署：单机房01目录15050315161829313132

2、40414152525145535556五、Alluxio 部署：跨机房六、Alluxio 测试：功能七、Alluxio 测试：性能八、Alluxio 落地：调参适配环境九、Alluxio 落地：运维十、Alluxio 落地：共同进步十一、小结中汽创智|Alluxio在自动驾驶数据闭环中的应用一、自动驾驶业务介绍二、数据平台架构以及存储选型三、自动驾驶数据平台使用场景四、未来规划关于Alluxio02目录575859606162636565677078在当今这个人工智能飞速发展的时代，诸多企业正站在一个充满挑战与机遇的路口。随着AI模型训练的热潮不断升温，企业在追求更高性能计算的同时，也不得不

3、面对GPU资源紧张、模型部署缓慢以及存储成本失控等问题。这些问题不仅加剧了技术团队的工作压力，也对企业的业务发展和市场竞争力构成了严峻考验。本电子书将深入剖析Alluxio如何在AI/ML场景中发挥其分布式缓存的作用，助力企业突破IO瓶颈。Alluxio作为一个高效的数据访问层，优化了数据在存储与计算引擎间的流动，显著提升了数据访问速度和操作便捷性。文章详尽地列举了企业在探索AI过程中遇到的挑战，细致阐释了Alluxio在技术架构中的关键角色，以及其如何通过优化AI框架的IO性能，提升整体数据处理能力。同时，文中通过小红书、知乎、B站、辉羲智能以及中汽创智等知名企业的实战案例，生动展示了All

4、uxio如何助力企业在解决技术难题的同时，实现更快的模型开发周期、更及时的数据更新、更高的模型准确性和可追溯性，以及更好地适应数据集的迅猛增长。本电子书将帮助用户迅速把握Alluxio如何助力企业应对AI模型训练的多重挑战，捕捉行业发展的脉搏，实现技术上的飞跃和业务上的持续增长。引言03用户收益实战经验借鉴：通过小红书、B站、知乎、辉羲智能等企业案例，了解如何将Alluxio应用于实际场景，解决具体的业务挑战。1.多云架构优化：了解如何在多云环境中利用Alluxio实现数据的高效管理和访问，从而优化多云架构下的数据使用和存储成本。2.性能与成本的双重优化：掌握如何通过Alluxio提升数据处理

5、性能，同时实现成本优化。3.前沿技术洞察：获得对未来技术发展趋势的洞察，为技术选型和业务布局提供参考。4.灵活性与扩展性实践：了解Alluxio如何支持不同技术栈和框架，增强现有系统的灵活性和扩展性，以适应不断变化的技术需求。5.适用人群数据科学家与机器学习工程师、AI研发团队、技术架构师、基础设施团队、技术平台团队、云计算与存储团队、IT运维与系统管理员、业务分析师与决策者、学术研究人员、技术爱好者、产品经理、行业解决方案顾问04一、企业在尝试AI时面临的挑战1.GPU短缺其实从几年前就已经呈现了一些趋势，不管是在云上使用GPU还是自己购买GPU搭建IDC（数据仓库），AI基础设施都比较困难

6、，原因大概可以分为3种情况：很多公司无法买到GPU；部分公司即使买到了GPU，量也不是很大，很难满足业务需求；部分公司或许可以在阿里云或者腾讯云上买到GPU，但如何把这些GPU形成一个系统的计算池，供上层业务使用，是比较困难的。2.模型上线慢公司现有数仓/存储方案较陈旧，很难迭代，进行GPU训练后，如何把模型上线到推理的集群中，是必不可少的一个环节，也是困难重重的一个环节：很多数仓、底层的存储都还是公司里比较传统的存储方案，比如HDFS，可能十几年前就开始用了，现在很难调整存储的设置；数据在云上，限流情况严重，使用限制较多。后面也会深入聊一下，如何解决这个问题。3.GPU使用率低现在很多公司模

7、型训练过程GPU利用率普遍比较低，当然这个不是Alluxio一家就能解决的问题，普遍现象是：企业的数据大多在数仓中，这些数据如何引入GPU集群，存在非常多的挑战。后文也会分享在不同云厂商、国内外的大型企业中，Alluxio是如何解决这一问题的：背景&Alluxio赋能AI场景05前面所提到的更多都是业务的压力或者是商业上业务决策的压力，这些压力反映到基础上对工程人员来说就会变成技术压力，为了能够更快进行模型开发，Alluxio其实是有一些期望的：更快的模型开发时间；更频繁的模型数据更新；更高的准确性和可追溯性；适应快速增长的数据集。这些压力反映到技术侧大概可以概括为3点：1.广泛的数据拷贝任务

8、管理比如以现在的应用，如何做这套系统，很多时候需要进行一些复杂的数据拷贝任务，从数据仓库往GPU的训练集群中进行数据拷贝，无论是拷贝到本地的NAS、NFS系统，或者是拷贝到本地的磁盘中进行数据管理，都是比较复杂的2.专用存储为了满足AI场景的需求，对性能的要求会比较高，可以这么理解：20-30年前，GPU是和HPC（高性能计算）一起发展起来的，所以那时候大家普遍倾向于要有一套IB的网络，并且是有一套高性能存储（全闪）支撑业务的发展，其实现在在云上或者是IDC里，这个问题是非常难解决的，因为大部分公司/云上设施没有办法提供这么高的专用存储支持模型训练或者是模型分发的任务。063.云和基础设施成本

9、失控模型上线以后，随着业务规模的增长，云和基础设施的成本是非常容易失控的，可以看到非常多的场景，比如3年增加5倍的云上成本都是很正常的。二、Alluxio在技术栈中的位置在进入详细技术讨论之前，再系统介绍一下Alluxio在AI/ML技术栈中的位置。07首先，Alluxio不是一个持久化的存储层，持久化存储比较依赖云上S3 Storage、Ceph或者是HDFS这种分布式存储，这些都是Alluxio下面的一个接口，和Alluxio不是同一个概念。再往上，Alluxio在AI领域是一个高性能的接入层，因为对于持久化存储层来讲，大部分公司追求的是价格和性能效率，而这个效率就意味着要有一个非常便宜的

10、存储池，可以存储很多资源，并不期望有一套非常昂贵的高性能存储来做持久化存储，之所以会这样是因为很多互联网厂商或者是传统企业的数据量有几百个PB甚至是EB级别的，但同时需要训练的数据并没有那么多，可能就是几十个TB，甚至高一点的也就1PB左右，如果可以把这些数据放到一个高性能存储向上进行对接，对用户来说这个性价比是非常低的，所以Alluxio比较依赖这种持久化存储层进行非常简单的对接，或者现在已经有了持久化存储层，不改变它的架构，可以直接进行数据对接。08再往上，Alluxio对Pytorch、TensorFlow的IO性能做了非常多优化，包括缓存策略、调度的优化/如何与它对接、Kubernet

11、es的部署等。再往上就是Ray或者是MLFlow这种AI/ML的编排层。Alluxio是一个从大数据场景发展起来的公司，在这波AICG浪潮中逐渐被用户转移使用场景到支持AI/ML的workload，从使用Alluxio的客户/用户环境中总结的价值是有非常多的，大概可以概括成4点：1.更高性能、可扩展的AI/ML管道Alluxio不改变现有的集群部署，比如已有的对象存储、HDFS等，同时又想扩展业务，这里其实有两个关键点：一般大数据和AI两个Team虽然在一个大的架构下，但其实技术栈是非常不同的，比如大数据技术栈会有Spark、Trino、Hive、HBase等，向下对接的是HDFS、云上的一些

12、对象存储等，这些数据是一直在的，数据量可能有几百个PB甚至EB级别的，同时需要搭建一个AI Infra的平台，AI技术栈其实是Pytorch、TensorFlow，下面对接比较多的是对象存储，比如Ceph、MinIO等，其它的会有一些专用存储，比如提供NFS、NAS的这些系统向上对接；其实这两个系统的存在就产生了对接的问题，就是数据在数仓中，但是处理是到AI Infra里，这就变成一套非常复杂的系统了，而Alluxio可以帮助打通这套系统，不需要每次都进行非常复杂的数据迁移。2.随时获取及时、准确的模型数据模型的数据从训练集群出来，需要先落到存储中，然后再向上拉取到推理集群，这个过程很多时候是

13、非常复杂的，比如Data Pipeline，之前遇到很多互联网公司都有一个临时的checkpoint store，然后还有一个持久化的checkpoint store，他们进行低性能和高性能的互相拉取是一个非常复杂的过程。3.避免复杂的数据迁移4.模型上线时间相比对象存储与传统数仓快2-4倍09底层存储一般都是对象存储或者是传统HDFS，比如传统的HDFS大家都是给大量数据存储设计的，这个不是为了性能而设计的，大部分情况是为了保障容错，同时针对云上的存储，在跟诸多云厂商交流后了解到，他们很多情况下没办法直接在云上用对象存储支持AI的业务，原因在于限流的问题，拉取数据的速度很快，所以没办法处理。

14、下面详细介绍Alluxio是如何做这套系统的，里面有很多场景的沉淀，此处分享一下Alluxio架构设计的初衷：首先在很多互联网厂商群体中，大部分的客户/用户，他们的数据大概率是在数据湖中（有90-95%），他们的数据并不是以一个单独的数据集群来做这个事，而是有非常多的数据，包括传统的Hive Meta store、现在比较流行的数据湖里的数据，同时还有很多Streaming Data的数据直接进来，也有很多非结构化的数据是放在数据湖里的。那么Alluxio是如何在其中发挥作用的呢？现在比较流行的就是用Spark或者Ray的架构，把这个数据预处理完，放回数据湖中，后面的TensorFlow、Py

15、torch会拉取这里的数据进行训练，比如看左边这个图，如果不用Alluxio拉取数据会产生什么问题呢？比如原来的数仓用的是HDFS集群，AI训练会用一个Ceph的集群：10首先要把处理好/未处理好的数据拉到Ceph的集群中，再向上serving这些拉取的data，在这里就会出现一些问题：首先这套拉取的流程会非常复杂，很多公司会自己开发一套数据管理系统完成，会有几套不同的流程在里边，比如用meta store对应这些表/数据在哪里；其次需要增量的拉取数据；最后需要对数据进行检验，查看是否有问题。这套流程下来从拉取到可用有很长的延迟，而Alluxio缓存的功能帮助大家解决这个问题。首先可以预先将部

16、分数据加载到 Alluxio 中，放到更靠近计算的存储中，从而降低带宽消耗。同时，即使没有预加载数据，Alluxio 的缓存机制也能帮助快速拉取数据到训练集群中。这种方式类似于股票交易中的 T+1（T+0）交易，即从一开始访问数据的瞬间，数据就可以被迅速提供，不需要等待数小时再传递数据上去，从而节省了大量时间。其次，Alluxio 还能减少用户自行开发而产生的数据治理问题。如果用户已经有一套数据治理系统，Alluxio也提供了多种 API，包括原始数据更新的 API，方便用户进行定制化开发。此外，Alluxio还着重关注：在训练集群上如何降低成本并提高效率。过去很多公司使用高性能的存储集群进行

17、训练，但这种成本可能非常昂贵，限制了业务的扩展。如果仅在 GPU 计算节点上配备磁盘，与 GPU 集群整体成本相比，这个成本通常不会超过 3-5%。此外，许多公司拥有大量存储资源，但如何充分利用这些资源仍然是一个挑战。Alluxio 在这方面提供了很多结合点。可以将 Alluxio 集群直接部署到训练节点上，这样的消耗非常小（约 30-40GB 内存），却能提供高性能的训练支持。用户只需要付出整个计算集群成本的 3-5%，就可以充分利用 GPU 集群，帮助用户克服IO瓶颈达到 GPU 100%使用率。11除了训练集群，Alluxio也特别关注推理集群的成本和效率问题。随着推理集群的扩展，成本可

18、能远高于训练集群。因此Alluxio致力于解决如何快速将训练产生的模型部署到线上集群的问题。在传统方式中，训练结果会写回到一个 Ceph 存储，然后线上集群可能位于同一个或不同的 IDC 中，涉及到复杂的管理。很多公司会开发一套自己的存储网关(storage Gateway）来解决跨域或跨 IDC 的问题，但是网关解决的是一个跨域或者是跨IDC问题，实际上没有解决的是高性能和跨域的问题，简单理解就是可以把训练集群和线上的ML打通，但如果在AWS里这个Gateway是完全没有办法支撑推理集群的，比如扩展到100个甚至1000个节点的推理集群后，上线的时候会抖动的非常厉害，再比如：Alluxio可

19、以在2-3分钟内把整个模型全都部署到推理集群上面，一般这种系统需要耗费的时间是它的10倍，而且它的P95和P99会非常长。三、Alluxio在模型训练&模型上线场景的应用接下来会详细讲解不同场景中，Alluxio是如何做的：12第一个就是之前说到的问题，在GPU非常短缺的情况下，很多公司其实之前都不是多云战略，不是IDC融合或者是云上、本地都有的架构，但为了满足GPU资源的部署，很多时候被迫变成这样，举个例子：很多客户/用户，数据都是在AWS上，根本就不想用Azure、Google Cloud等其他云，但今年，Azure把所有GPU都买了，在这种情况下其实很难说在AWS上可以找到所有集群，然后

20、这些集群就必须在Azure里，就必须得有个方法直接去访问AWS里的数据，这个问题就导致如果直接去获取，数据性能就会非常低，如果是在网络带宽非常低的情况下，GPU的利用率通常不会超过10%，好一点的网络（比如有专线）情况下，可以达到20-30%。第二个问题是如果要建一个多集群数据管理是非常复杂的，包括要保证数据的一致性，如何更新、拉取这些数据，但Alluxio做了很多的集成，就可以直接使用Alluxio解决这些问题。其次就是不希望大家专门买一套硬件解决方案，之前接触过的实验室有在做HPC的，HPC有一个很大的问题就是成本非常高，买1套HPC通常可以买10套Hadoop硬件，或者是云上的存储硬件，

21、所以如果需要购买一套专有的硬件搭建AI Infra 架构，是事倍功半的，成本非常昂贵，看到这个场景后，Alluxio提出还是希望可以直接在数据湖上构建AI和ML的数据通路，可以不更改存储系统，同时可以利用已有的，不需要额外购买IDMA这种硬件，就可以支撑训练的需求。同时不用考虑和原数仓中任务进行数据隔离的问题（所谓隔离就是需要进行数据迁移，然后运行成两套非常独立的系统，这对数据的拉取、获取是非常有问题的）。13上图就是前面提到的，Alluxio提供的一些功能，比如自动数据湖加载/卸载、更新数据功能，从而提高数据工程团队的生产力，一个比较常见的场景就是：如果基于原有的系统搭建，加一个Ceph，基

22、本时间线会拉长到3-6个月，在国外公司拉长到6个月以上是非常常见的，但是用了Alluxio整套系统拉取后，基本就可以在1-2个月内把整个Data Pipeline建起来，如果大家感兴趣可以去详细了解一下知乎的应用案例，里边有非常详细的解读，告诉大家如何去搭建这套系统。上图是前面提到的另一个问题：模型部署受限于底层的存储，包括带宽的问题，还受限于IDC不同位置的问题，Alluxio可以做一个多云多架构，不管是从公有云到私有云，还是不同公有云之间进行模型部署，都会非常快速的解决这个问题，同时会提供一个高并发的缓存系统，支持业务高并发拉取。稍微总结一下，Alluxio在AI架构中处于怎样的位置？Al

23、luxio帮助大家解决什么问题？第一个就是降低改造和适配的成本，帮助大家更聚焦在模型上线的逻辑上；第二个就是消除了专用存储架构，比如原来必须要用NAS、NFS这些系统来做的，用了Alluxio之后就不再需用，Alluxio和下面原来已有的HDFS，对象存储配合就可以搭建AI平台；14第三个就是需要添加缓存，就可以把GPU利用率提高到较高的水平；第四个就是满足公司自由部署GPU的需求，不管是云上还是云下买的GPU，不论数据在哪，都可以实现很高效的数据适配，后面会提供一个具体案例。关于Alluxio在AI场景是如何助力企业解决问题的，详细分享几个备受关注的案例：一、面临的挑战首看看小红书的业务都碰

24、到了哪些挑战。小红书作为云上的原住民，从成立之初就构建在公有云上，下图是小红书多云架构的示意图：小红书|加速云端机器学习-Alluxio在小红书的实践15图中的三个圈代表两个云厂商的不同 Zone（区域），云厂商1是在 ZoneA 与ZoneB，云厂商2是在 ZoneC。核心业务分别分布在多个云厂商的不同可用区，核心业务如搜广推、社区通常在主要机房都会存在，是多活架构；主要业务如电商直播及部分大数据服务，是双活架构；其他如训练等服务，是单活架构，这个只是个简化后的示意图，真实情况远比这复杂。多云架构对小红书带来了非常明显的成本优势和可用性优势，但业务的通信链路也随之复杂，各种跨专线调用；还有个

25、特点是不同 region 之间 rt 差异比较大，且专线容量非常稀缺，因此带来了一些业务使用上的痛点。多云架构下有哪些典型的问题机器学习训练在小红书是资源大户，属于公司 Top 级别，但海量的 CPU 和GPU 资源的利用率不及预期，训练速度上不去，业务体感比较差。1.推荐服务是小红书最核心的服务之一。它的核心逻辑是推荐召回需要有索引分发的过程，比如刷小红书刷到的个性化的笔记列表，就主要用到了索引。索引服务因为索引分发慢，从而导致稳定性比较差，且因为索引数据存储在云盘里，成本也很高。2.在AI场景下，有业务面临 60 亿+的元信息小文件场景，需要有一个低成本的解决方案。而且随着AI的飞速发展，

26、AI 模型从之前的百 GB 级发展到如今的 TB级别。原来的架构通常先把模型拉到本地盘，再从本地盘加载到内存，才可以进行在线推理。这个过程在模型增大到 TB 级之后，会有两个严重的问题：一个是加载过程非常缓慢，另一个是模型存储在本地盘的成本非常高昂。3.多云架构本身带来的网络链路复杂，跨专线传输数据量非常大，专线单价也是非常高昂，有成本和稳定性的双重挑战。4.二、多云数据加速层接下来介绍下小红书是如何通过构建多云统一数据加速层来解决这些痛点的。16上图是小红书业务架构的示意图。最上层是业务层，主要包括社区、搜广推、直播、电商这些核心服务。接下来是平台层，这里只列了一些和数据强相关的，如机器学习

27、平台、AI 训练平台，模型发布平台、推荐索引平台、数据平台等。最底层是公有云的存储产品，这里只列了主要依赖的对象存储，其实包括异构的 HDFS 等产品都可以适用于这个通用的解决方案。在平台层和存储层之间，基于 Alluxio 构建了一层多云统一数据加速层并研发了对应的智能缓存服务。为什么选择 Alluxio 作为多云统一的加速层首先基于面临的问题，抽象出了选型的重点目标：需要能够复用业务历史上已经存储的数据，不需要再次搬迁或者导入到其他高速存储或文件系统就能享受到数据的加速。以典型的搜广推和训练业务为例，这些业务的存储量大概是数百PB级别，搬迁一遍才能使用不太可行。需要支持 S3 和 POSI

28、X 协议，以便于与其他平台无缝对接。如机器学习训练通常是 S3 协议，AI 训练通常是 POSIX 协议，如果加速层能够兼容这类协议，业务方就不需要改代码，迁移成本也会低很多。需要实现跨云专线传输的带宽控制和节省。因为跨云本身业务是多活、多云的。但多云之间本身就有实时的数据同步，如果把带宽打爆，那稳定性问题就会立马出来，所以一定要能够控制住带宽。能够支撑百亿级别的 AI 训练，小红书有单个训练任务就有60亿+元信息的场景需要支持。能够支持常见的云存储产品，以主流云厂商的对象存储为主。经过调研发现，业界目前唯一能同时满足上述诉求的产品，就是 Alluxio。17Alluxio主要特性18特性一：

29、格式透明，不侵入业务数据存储格式。数据湖里的数据量非常大，是不可能再导入进来重复存储的，有了Alluxio，只需要在原来存储上加一层Alluxio，就可以直接去访问那些数据了，让业务直接享受到加速收益，这是非常关键的特性。特性二：协议兼容。Alluxio 支持非常丰富的S3POSIXHDFSJava FileAPIREST API等协议，帮助Alluxio上层AI/ML训练引擎（如Pytorch、Ray、TensorFlow）和查询引擎（如Presto、Spark、Trino）与底层存储进行无缝对接。特性三：多云统一视图。不管底层存储是HDFS、Ceph还是各云厂商的对象存储，对于用户，只要通

30、过Alluxio，任何API都可以去访问不同存储位置的数据，从而可以实现多云统一视图的效果。特性四：数据仅需通过专线传输一次，后续可通过缓存就近读取，不需要再次跨专线，这个关键特性对小红书专线的保护意义重大。通过合理地利用这些特性，就能够解决上述提到的小红书多云架构的业务痛点。三、小红书实践案例机器学习训练场景19机器学习训练原架构机器学习训练最初的架构是直接从对象存储拉取数据（主要是训练样本），拉取完这些训练样本就开始在TensorFlow框架做训练。主要问题：训练速度不太符合预期，导致一些任务训练很慢，以及其他人排队调度不上，体验很差。海量的集群资源利用率太低对成本也带来了很大挑战。主要原

31、因是一些热点的数据集（如小红书的笔记样本），是公共的样本，总量非常大（大概每天几百TB）。这些公共数据集会被很多任务使用，在小红书的场景下大概是 20 倍的扇出，如果是几百TB的数据会有 20 倍的扇出，这个总传输数据量是非常大的，整体流量达到了Tbps级，触达到了对象存储桶的带宽瓶颈。如果数据集大、扇出也大的话，一定会有额外的带宽需要，云厂商的解决方案通常是要么增加存储量，要么对增加带宽进行额外收费，两种方式都不太友好。因为业务会直连对象存储，而对象存储本身是高吞吐的产品，并不会过分强调单线程有多快，这就需要业务不断的去调优，才能达到适合的吞吐。基于以上三个问题，机器学习训练架构经过了升级改

32、造，最新架构如下图所示。20新架构对于普通数据还是直接会去对象存储读取，对于笔记这种热点的训练数据集，会把它缓存到 Alluxio，当业务来 Alluxio 访问的时候，如果第一次数据不存在，就会去对象存储透传，然后把数据返回给训练框架，如果数据已经在Alluxio上，那就可以命中缓存，直接由 Alluxio 返回数据。虽然第一遍读完数据，Alluxio 一定会去缓存数据，但这还很难解决业务的问题。第一种情况是 Alluxio 缓存是用到本地磁盘把数据缓存下来，但磁盘容量是有限的，如果总训练的样本空间远大于磁盘缓存容量，就会不断的淘汰缓存数据，可能第一个任务缓存了，第二个任务就没有空间缓存了，

33、或是会把别的缓存数据给挤掉。第二种情况是有些训练任务可能因为计算资源或者故障的原因带来严重的延迟，之后这个业务一旦跑上来，可能需要训练 30 天之前的数据，或者直接回溯很老的数据去训练，那这 30 天的数据很容易就把所有的缓存空间全部用掉。以上两种场景通过研发了智能缓存管理服务来解决。智能存储管理服务智能缓存管理服务主要是基于任务的历史运行规律，可以基于任务的历史运行规律，更加智能的把数据提前做预加载，这样通常第一次训练就能够命中缓存，而且可以更及时地淘汰掉不使用的缓存。不仅如此，还对缓存淘汰场景进行了评估，比如发现最近 1-2 天的笔记训练样本是非常重要的，就会把这些数据用 Pin 机制固定

34、在磁盘里，就不会被自动淘汰，从而实现重要数据的淘汰完全由智能缓存管理服务去控制。通过这两个措施的共同保障，缓存命中率能跑到90%以上，很好节省了对象存储的带宽。同时，Alluxio 也提供了load任务的管理和执行能力，但目前还不完全符合小红书的需求。具体的业务中需要监控到任务粒度的 load 进展，比如有 10 个任务（有几个是重要的），在按小时提前预加载数据，结果集群故障了，但故障时间也较长，第二天马上又要用新的样本去训练数据，那该如何止损呢？措施是通过实现 load 进度的可观测机制，能够观察到每个任务当前正在加载第几小时的数据。当在不及预期的时候，会马上发出告警并做止损。当止损的时候，

35、会基于任务的优先级去判断优先补偿哪些任务，并提供一键补偿的能力，看看这些任务已经错过了哪些小时的缓存数据，然后全部加载进来，从而规避带宽全部透传到对象存储所造成的的稳定性风险。第三是为稳定性实现了一个探针服务，它可以完全模拟业务的读写行为，是一个端到端的探活服务。探活实践下来非常好用，无论是代码本身有问题，还是机器磁盘、网络等出现问题，都能反映在探针里，方便快速介入。目前能达到3分钟发现和1分钟止损的效率。经过将近一年时间的运行，故障告警的准确率几乎达到了100%。训练速度提升效果2122上图展示的是一个非常典型的笔记训练大任务，其他业务训练效果都差不多。在迁移之前，训练时长达到9小时36分，

36、单一任务就需要消耗2000核，非常消耗资源，而平均 CPU 利用率只有30%，只是到了最后面会有一些上升，这是因为这时候大部分任务已经训练完成，对象存储的带宽有些缓解了。在迁移到 Alluxio 之后，训练时长直接缩减到了 5 小时 42 分，从图中可以看到，CPU 利用率可以非常均匀的维持在75%，并且再也没有被限流影响到。整体训练速度在时长上优化了41%，虽然很多业务比这个效果更好，但这个例子是一个非常典型的大任务，更具有代表性。推荐召回索引下载场景23索引对于推荐非常核心，稳定性是非常重要的问题。上图是未引入 Alluxio 之前的架构图。最上面是搜推平台，会对搜推的索引做一些生成或者更

37、新，更新完了之后会存储到索引存储（一般是就近机房的对象存储）。存储索引之后，搜推平台会通知其他服务下发索引，下发索引的服务会把数据通过专线从原来索引存储的对象存储桶传输到另外一个多云机房的本地磁盘，也就是索引服务的本地磁盘上。以图中的架构为例，共有两个跨区域的机房，当把索引数据下载到本地盘后索引服务就能够把数据加载到内存中，对外提供一些索引的服务。这样的架构带来的问题很大：以推荐场景下的索引读取速度来说，通常发布一个机房的服务需要 3-4 个小时，因为是多活设计，发布完四个机房整整需要一整天，这是非常令人头疼的问题。同样，当单机房发生故障，止损时长同样也需要 3-4 小时，如果你要把很老的一个

38、索引回滚，就需要重新走这个流程，四个机房就需要一天时间。磁盘存储成本非常高。因为索引服务本身是一个主从架构，典型的场景是一主两从。同一个索引会有三副本的云盘存储，而云盘本身就是三副本冗余存储，那整体下来就是九副本，而云盘的单价通常比对象存储贵得多，这样计算下来整体成本是非常高的。下图是引入 Alluxio 之后的架构。从搜推平台生成索引之后，会把这个事件发送到消息队列，智能缓存管理服务订阅了该消息队列，收到相应的加载缓存事件后，就会去加载索引。现在的加载流程和之前就不一样了，之前是通过专线传输过来存到本地磁盘，现在是加载到 Alluxio 集群里，然后再告知索引服务，去 Alluxio 集群把

39、数据再加载到索引服务的内存，从而对外进行服务。这里的关键点是把本地磁盘变成了 Alluxio 集群，那为什么采用 Alluxio 之后解决了以上问题呢？24首先，把磁盘上浮到了一个远程的集群，实现了索引的存算分离，把原来来自云盘的存储瓶颈，转换成了宿主机的网络瓶颈。云盘的带宽通常在云厂商相对还比较好的规格是 350 MB/s，但是宿主机不一样，推荐可用的一些机器至少都是 32 Gbps以上，合4GB/s，这两者的差距超过10 倍，因此下载索引数据这个过程就能提速10倍以上。第二，Alluxio 并不会把文件存储在固定的一台机器上（和本地盘不一样），一个文件会被切成 block 存储。比如一个集

40、群有 100 台机器，一个文件能切 100 个block，那每个机器只会存1个block，这时候整个集群的带宽就是这个文件的吞吐极限。所以，对于一些热点的索引文件或者其他场景都是非常友好的。但这样直接用 Alluxio 还是会遇到问题，所以还加入了一些增强的功能，这也是为什么引入了智能缓存管理服务的原因。比如 load 太快会把专线打爆，需要Alluxio 支持限速，以保障核心服务的稳定性。现在已经支持了限速，当限制20-30Gbps的带宽从 UFS 下载数据，就不会把专线带宽占满。这套架构主要有三点收益：Alluxio 将云盘带宽瓶颈变成了宿主机的网卡瓶颈，索引拉取速度带来 10 倍以上的提

41、升。如果宿主机的核数越大，附带的带宽也会更大，带来的提升倍数还会增大。1.索引下发的整体业务体感（含业务逻辑）达到 3 倍的提升。主要是因为除了下载，还有一些业务逻辑在这个索引下发的过程里。2.高性能云盘替换成对象存储，节省80%成本。此优化是通过 Alluxio 把云盘全部省掉，变成了Alluxio 的集群本地盘，而这些本地盘可以选择一些更廉价的介质，比如单副本的 HDD 盘。对于小红书的推荐场景，由于索引数据量很大，云盘成本的节省量也是非常可观的。3.大模型下载场景小红书也有大模型的场景，大模型下载的解决方案和推荐索引几乎一模一样，面临的同样是云盘带宽限制和冗余存储高成本以及跨云同步稳定性

42、问题。3-4年前大家通常只做单机训练，现在已经演进到了几乎都是分布式训练的状态。那一定会需要通过远端的存储集群来解决本地数据存放不下的问题，这块架构与收益跟推荐索引一样，就不赘述了。25AI 训练场景面对的挑战：有 60 亿+级别的小文件训练场景，如果把这些元信息存储在一个集中式的元信息服务里，成本非常高，本身技术挑战也很大。对象存储作为很多存储的底座，最终数据会穿透到对象存储，会面临着存储带宽，或是 IOPS 比较有限的情况（尤其是小文件），云厂商通常一个桶提供几万 IOPS，每PB存储量的带宽配额也很低，尤其在小文件场景下，这点 IOPS承载不了多少访问，因此 GPU 利用率就会很低。解决

43、方法：26引入 Alluxio 缓存训练需要的数据。Alluxio 3.0 版本提供了一个可扩展的元信息能力，让扩展性大幅提升。此外，Alluxio 本身支持 POSIX 协议，之前如果训练是在本地盘上，现在会把 Alluxio 集群 mount 到 GPU 机器上，由于 Alluxio 是透明嵌入，让业务方看其实还是访问的本地盘，背后其实是 Alluxio 集群。然后，通过Alluxio 集群去对象存储里取数据，基于 Alluxio 的缓存机制，可以有效的避免数据穿透到对象存储。因为通常 AI 训练是多轮的 epoch，Alluxio 只会让第一轮epoch 走对象存储，后面都可以命中这些缓

44、存。甚至理想情况下，可以错峰把这些数据预加载到 Alluxio，这样真正训练的时候，完全不需要走对象存储。因为 GPU 机器上很多磁盘是闲置的，为了避免额外的支出成本，会把 Alluxio 和GPU 机器混合部署，让这些磁盘都可以被充分使用，也不会有额外的成本支出。Alluxio 相对于别的产品打造的非常成熟的能力是ClusterCache。在同样的总磁盘容量，ClusterCache 相对于Local Cache的命中率可以做到更高，比如有两个训练任务读同样的文件，如果落在两个不同的机器上，对于 Local Cache 会把数据读两遍，而对于 ClusterCache 只需要读一遍，第二次可

45、以通过网络来传输，而GPU 机器之间的网络带宽也常非常高，通常有百Gbps，同时 Alluxio 也支持LocalCache，组合起来使用更佳。Alluxio 为什么能加速 AI 训练可以在业务训练之前提前把数据加载到缓存中，突破IO限制，相比穿透对象存储读取性能更高；读取数据时通过智能判定是随机读还是顺序读。如果是顺序读可以提前预读数据，从而达到更高的读吞吐；如果是随机读，可以精准地控制要读哪个位置，避免读的放大；无集中式的元信息服务，全量元信息在对象存储，只有热数据及其元数据在缓存中，对海量小文件友好，相比于集中式元信息服务，成本极低；可异步写 checkpoint 到本地磁盘，再异步上传

46、至对象存储，通过有效缩短 IO负载时长，从而大幅缩短GPU 等待时间，并显著提升 GPU 利用率。27技术问题及解法在与 Alluxio 的合作过程中，小红书也一起参与解决了非常多的技术问题，这里有几个比较典型的场景：读放大问题解决：主要表现在 S3 协议里会有一些 range 读，以及 Alluxio client、fuse 或者其他一些触发随机读的场景。放大主要存在两个环节：一个是 S3 proxy 到 worker 之间；另一个是worker 去对象存储（UFS）取数据的时候，都会有一个读放大的情况。比如一个数据是热读（指数据缓存已经在 worker里），原来的实现里 proxy会直接去

47、 worker 取，虽然S3协议里的 range 参数已经指明了截止位，但并没有透传过去。因为这里可能认为需要做一些预加载来加速后续的读取，实际上业务如果指定了一个 endOffset，后面的数据则是没必要读取的。虽然预读能帮助吞吐的提升，但在这种情况下后面的数据会被完全废掉，反而会转化成带宽的放大。解决办法：worker 传输数据当传输到 endOffset，后面的字节不需要传输过来，这样是更经济，更高效的办法。第二个放大的问题是因为 Alluxio 初衷在读数据时，会把需读取数据范围涉及的block 全部缓存下来，好处是之后再读这些数据就不需要走带宽了。比如在一个随机读的场景，在一个blo

48、ck 里只需要 1-2M 数据，但Alluxio会缓存整个 block 的大小（默认为 64M）。解决办法：如果是非缓存block的数据请求，因为协议中本身传了 endOffset，需要将其作为访问对象存储的参数，只需要读取必要的数据即可。endOffset 之后的数据本身也会被丢弃掉，读出来就会变成 worker 机器上网络带宽的开销，从而影响成本和效果。第三个是冷读 NoCache 的场景。NoCache 是指经过 Alluxio读取但不缓存对应的数据，通常发生在对于延迟太久的任务或者读取大量冷数据的任务，不需要将其缓存下来，否则会将本身的热数据给挤掉。解决办法：以前的实现里，通过 S3p

49、roxy 直接 NoCache 读，它会通过 worker 去UFS取数据。修改和打磨之后，Proxy 会绕过 worker 直接去 UFS 取数据。这样可以节省 worker 传输到 proxy的带宽，可以省一倍的带宽，对应到机器成本上就是省一倍的机器成本。28专线带宽限流：在 UFS 这一层增加了流控能力，保护了专线带宽。在多云环境，业务通常会就近读取，一定不会跨专线访问 Alluxio集群，所有跨云专线的流量只有从 worker 到UFS 这一层，所以只需要在访问 UFS 的地方加限流就可以控制住专线。而客户端和 S3 Proxy 的交互，以及 S3 Proxy 与 worker的交互都

50、是同机房的一个流量，理论上也需要保护，但不影响专线。读写性能优化：在读性能优化方面，通常是识别了读的特征之后做预读，通过预读能够明显提升读的性能，尤其是在冷读数据的情况下。在Checkpoint写方面，一定不能阻塞训练，所以支持了WriteBack 能力，WriteBack 是指先异步写到磁盘甚至内存中，然后就可以开始后续训练，通过后台线程异步上传。同样也有一些线程模型的优化，整体对读写的性能也有非常大的提升。四、未来规划未来小红书会把数据加速层做成什么样子以及还有哪些待解决的问题呢？打造统一的多云数据存储产品因为小红书的数据存储在多云里，业务需要关心数据到底在哪个云上，是不是会跨专线，到底要

51、用哪个 SDK 去读取，报错了都是什么原因，该去找谁，业务感知的东西非常多。期望打造一个统一的多云数据存储产品，让业务方再也不需要在代码中关注数据到底在哪里，专线能否控制好等问题。AI训练：多地域GPU利用率提升在 AI 训练场景，因为 GPU 众所周知的供应问题，从各个厂商购买或租赁的 GPU是分散在非常多的地域。这会造成一个非常严重的问题，有些地方有 GPU，但没数据，有些地方有数据，但没有 GPU，这会导致 GPU 的分配率不高。后面会探索如何基于 Alluxio 来提升 GPU 利用率，解决数据和 GPU 在不同地域如何充分利用GPU 的问题。29大数据查询加速大数据查询加速在 All

52、uxio 社区里的案例非常多，但小红书需要探索出一个如何在极低成本的情况下去实现大数据查询的加速。同样的查询效率提升，需要增加的Alluxio 的成本要小于直接扩容查询引擎节点的成本才行。低效节点资源利用率提升现在 Alluxio 集群规模比较大，与此同时，CPU 利用率是非常低的，每天平均大概3%的利用率，但磁盘容量和带宽全是占满的。如何将这些 CPU 去充分使用是一个非常大的问题，而公司出于成本考虑，也会要求这些低效节点能够被充分利用，从而发挥更多价值。30一、混合云架构，带来便捷与挑战知乎目前是典型的混合云架构，数据和服务都分布在不同的机房：离线机房：专为满足大数据相关业务方需求而设计的

53、离线计算服务中心。其主要职能是部署离线调度、离线存储以及调度平台等服务。这些服务的目标是提供高效的离线数据处理和计算能力。在离线机房中，大数据业务方可以安心进行批量数据处理和计算任务，从而满足他们对数据处理、存储和调度的要求。在线机房：此机房专为知乎主站提供直接面向用户的服务而设计。其中包括评论、回答、搜索、推荐等核心服务。在线机房的重点在于实时性和响应速度，以确保用户能够在最短的时间内获得稳定、高效的服务体验。知乎主站作为一个知识社区，其在线机房是为了保障用户对知识和信息的交流与分享能够得到优质、连续的支持。GPU 机房：此机房专门用于部署机器学习平台，主要服务于算法用户。其主要特点是提供强

54、大的 GPU 资源管理、模型训练、数据集导入导出等一站式解决方案。GPU 机房的核心任务是为算法用户提供高性能计算资源，以满足机器学习模型训练和推理的要求。这样的设计能够使算法用户更专注于模型的研发与优化，而不必担心计算资源的供给。31知乎|Alluxio AI助力知乎千卡模型训练32混合云架构给知乎带来了成本，容灾等各方面的优势，但是也对存储提出了新的挑战。相比于数据都存在在单一机房，在混合云的架构下，算法平台在调度训练任务时，还需要额外考虑访问存储时，专线带来的网络延迟以及网络吞吐的限制。二、知乎的探索历程探索：知乎自研UnionStore联合存储为了解决模型训练及模型分发场景跨云读取数据

55、的痛点，知乎在早期自研了一个缓存系统 UnionStore。顾名思义，UnionStore 是联合存储的意思，它联合了对象存储与 HDFS，利用对象存储来对外提供本机房缓存。它支持对象存储协议，这样用户可以使用 AWS S3 的 SDK 来访问数据。UnionStore 的缓存工作流程可描述如下：用户在向 UnionStore 请求读取文件时，会先检查对象存储上是否已经有该文件了；架构图如下所示：33如果对象存储已经存在该文件，则直接从对象存储读取文件返回给用户；如果对象存储不存在该文件，UnionStore 会先将离线 HDFS 上的文件上传到在线机房的对象存储上，再从对象存储上读取文件，返

56、回给用户，缓存期间用户的请求是被卡住的。这里相当于是利用对象存储做了一层跨机房缓存。挑战：面对大语言模型训练，UnionStore 捉襟见肘UnionStore 在知乎运行了两年，期间没有出现任何问题，但是随着 2023 年知乎开始布局大语言模型，UnionStore 在面对大语言模型训练时，有些捉襟见肘：没有元数据缓存，元数据强依赖 HDFS 与对象存储，特别是对象存储，元数据访问和首字节延迟在几十毫秒，而大语言模型在进行训练，读取语料时，往往都是随机读取，对吞吐要求低，但是对时延敏感，而 UnionStore 只能从对象存储随机读取数据，延迟极高；1.训练任务在启动时需要读取模型的 che

57、ckpoint，大语言模型的 checkpoint 动辄上百 GB，而对象存储单线程的读取性能只有 10-100MB/sec，尽管UnionStore 也做了一些加速手段，但是也只能加速到 200-300MB/sec 的速度，远远不能满足大模型的 checkpoint 读取需求；2.对象存储能力有上限，在模型分发时，往往单文件会有上百，甚至上千并发同时读取，对象存储容易面临性能瓶颈和带宽限制；3.无法做到边缓存边返回文件，导致首次读取文件的时间偏长，这也会影响大模型 checkpoint 的读取速度。4.以上痛点使得知乎面临两个选择：一是继续迭代 UnionStore，让 UnionStore

58、 具备高性能缓存能力，比如支持本地 SSD 以及内存缓存；二是寻找合适的开源解决方案，完美替代 UnionStore 的使用场景。基于人力资源的宝贵，选择了其二。探索：社区版Alluxio调研上线从 UnionStore 的使用场景来看，知乎需要的 AI 存储必须满足以下几个需求：34协议兼容：必须要具有对象存储协议和 POSIX 协议，目前知乎的模型分发场景使用的是 UnionStore 的对象存储协议，模型训练场景使用的是 UnionStore+S3FS-FUSE 来提供 POSIX 协议。性能优秀：选择替换 UnionStore 的最重要的原因就是对象存储的性能和延迟远远不能满足算法业务

59、的需求，所以知乎需要的 AI 存储必须要有足够优秀的性能；透明缓存：因为目前知乎的数据都是存放在 HDFS 上，不希望用户在接入新存储的时候，需要对访问数据的路径做比较大的修改，最好是路径能够与 HDFS一一对应，有透明缓存的能力，这样能够最大程度上减少业务方的改造工作。基于以上需求，调研了市面上大多数的存储，发现只有 Alluxio 能够满足需求，严格意义上来说，Alluxio 并不是一个标准的存储，它是一个多功能低侵入的高性能缓存，它的一些能力能够很好地满足需求：透明缓存：相较于其他文件系统，Alluxio 可仅作为缓存使用，用于编排数据，业务方无需将模型文件写入到其他的文件系统，只需要维

60、持现状，写入HDFS 即可；元数据与数据缓存：Alluxio 支持自定义缓存元数据与数据，这样在读取已缓存文件时，可完全不受 HDFS 影响；目前知乎 UnionStore 的 QPS 大约在20K-30K，缓存元数据可极大降低 NameNode 的压力，反哺离线场景；丰富的 UFS 支持：支持除 HDFS 外的多种 UFS，比如对象存储，在未来可能对数据湖场景也可以提供强有力的支撑；即席查询加速：知乎 Adhoc 引擎采用的是 Spark 与 Presto，Alluxio 对这两个引擎都有较好的支持；访问接口丰富：Alluxio 提供的 S3 Proxy 组件完全兼容 S3 协议，模型上线场

61、景从 UnionStore 迁移至 Alluxio 付出的成本几乎可忽略不计；另外 Alluxio提供的 Alluxio Fuse 也具备本地元数据缓存与数据缓存，比业务之前使用的S3FS-FUSE 具有更好的性能，正好能满足模型训练场景。35此外知乎对 Alluxio 进行了一些性能上的测试，Alluxio Fuse 的单线程顺序读取速度能够达到 500+MB/sec，Alluxio S3 Proxy 的单线程顺序读取性能能够达到1GB/sec 以上，这个性能完全能够满足需求场景。上线的过程比较顺利，几乎是无感迁移，在短短三个月内就将 UnionStore 完全替换成了 Alluxio，并且

62、拿到了不错的收益：模型分发的速度得到了 2-3 倍的提升；训练任务等待数据的延迟几乎消失，训练时长降低至原来的 40%。挑战：任务规模扩大，社区版难以为继随着训练任务的规模不断扩大，也发现了 Alluxio 社区版中存在的各种问题。总结起来可以描述如下：Fuse 稳定性问题：社区版 Alluxio Fuse 会经常出现 OOM 相关的故障，经常导致训练任务失败重启；Master 元数据性能瓶颈：社区版的 Alluxio Master 是一个单点的服务，在缓存文件增加的情况下，会遇到性能瓶颈，并且无法扩展；写场景性能不足：社区版的 Alluxio 同步写入 UFS 时，性能较差，不能满足业务做

63、checkpoint 的需求；高昂的运维成本：社区版的 Alluxio 部署，需要自己打镜像，以及写 k8s 的yaml 文件进行部署，没有 operator 相关的运维工具。以上问题在社区版需要投入极大的人力和精力来修复和维护，并且需要一个比较长的周期，而此时知乎的算法业务发展的势头很猛，根本等不及。正好听说 Alluxio也在企业版重构了他们的架构，在提升性能的同时，也修复了很多社区版已存在的问题。于是正式开启的 Alluxio 企业版的调研与试用。探索：Alluxio企业版攻克四大问题Alluxio Fuse 稳定性问题1.首先是 Alluxio Fuse 稳定性的问题，Fuse 在长时

64、间运行后，很容易出现 OOM 相关的故障，如下图所示：这是知乎真实生产环境中 Alluxio Fuse 的重启监控，可以看到 Fuse 的重启十分频繁，几乎每隔几小时就有一次。一旦 Fuse 重启，训练任务就会因读取数据错误而失败，需要从上一次 checkpoint 开始训练，这就导致了无效训练，会浪费相当多的 GPU 算力。在社区版中，定位到问题来自 Alluxio Fuse 的 native 内存泄露。社区版的Alluxio 使用 GRPC 传输数据，在遇到问题时，Alluxio Fuse 对于 GRPC 的处理不太优雅，导致了 native 内存泄露。企业版数据传输用 Netty 全部重

65、写了，不仅避免了使用 GRPC，也具有更好性能，相当于曲线救国了。下图是使用企业版时，Alluxio Fuse 的重启监控：36可以看到企业版的 Alluxio Fuse 几乎没有出现重启的现象。此外，由于 Alluxio Worker 在知乎是和和 GPU 节点绑定部署的，而 GPU 节点的机器故障率比较高，也造成了 Alluxio Worker 的故障率偏高。在这种情况下，企业版支持在某台 Alluxio Worker 出现问题时，重试到其他的 Worker 读取数据，或者是直接从 UFS 读取数据，这也提高了 Alluxio Fuse 的稳定性。Alluxio 企业版自上线以来，一共完成

66、了 300+训练任务，包括知乎最重要的千卡大模型训练任务，训练期间没有因为 Fuse 的稳定性导致训练任务重启，相比于社区版，企业版极大减少了无效训练的出现。2.Alluxio Master 元数据问题37Alluxio Master 是 Alluxio 社区版中一个比较明显的瓶颈：虽然 Alluxio Master 支持 HA，但是对外提供服务的 Master 只有一个，有单点性能问题，Master 在 3 亿元数据下可以相对稳定运行，但是超过 3 亿就需要进行调优，需要有丰富的经验；随着元数据增多，占用的内存也会变高，而内存在单节点上总是有上限的，不可能无限扩展；在 metadata sy

67、nc 比较频繁的时候，较小的元数据量也会出现比较严重的锁竞争问题，导致 Master 卡住。在 2023 年，因为 Master 的性能问题，出现过几次比较严重的故障，多亏及时抢修（手动切主+重启），才没有造成比较大的损失。Alluxio 的企业版对整个 Alluxio 集群架构进行了重构，不再使用 Master 管理元数据，而是将元数据用一致性 Hash 打散到每一台 Worker，理论上集群越大，可管理的元数据越多，元数据的规模随着 Worker 的增长可以达到近乎无限的扩展。由于元数据分散到不同的 Worker，元数据请求的 QPS 也能随着 Worker 数量的增加，得到线性增长。这里

68、需要注意的是，Alluxio 企业版引入了一个轻量的服务发现组件，目前是基于 ETCD 实现的，用于存放 Worker 列表。383.写场景需求写场景的需求主要体现在模型训练时做 checkpoint。在训练过程中，往往会因为一些意外导致训练任务失败，比如机器故障，GPU 卡之间的通信故障等。而大型训练任务往往都是持续好几个月的，在训练过程中出问题的概率接近 100%，为了避免在训练任务失败时从零开始训练，训练任务就需要在 训 练 的 过 程 中 定 期 做 checkpoint，这 样 任 务 失 败 了 就 可 以 从 上 一 次checkpoint 恢复，而不必从头开始整个训练。做 ch

69、eckpoint 越频繁，每次训练任务重启时，损失的训练时长就越短。但是对于一个大型训练而言，checkpoint的大小往往在数百 GB，保存并持久化巨大的 checkpoint 文件也会花费比较长的时间。训练任务在做 checkpoint 的时候，整个训练任务是停止的，GPU 处于等待状态。也就是说，如果想用 Alluxio 保存 checkpoint，Alluxio 必须要有一个比较好的写入性能，否则会造成 GPU 利用率不足。在 Alluxio 社区版时，采用的是同步写模式写入数据，直接穿透写到 UFS 上，只能达到 200MB/sec 的速度，与 HDFS 单线程写入的速度接近。假如以

70、这个速度，每隔 3 小时做 200GB 的 checkpoint，每天光是花费在做 checkpoint 上的时间就达到了 120+分钟，占到全天时长的 8%，也就相当于 GPU 利用率直接降低了8%，很明显这个速度是不能满足需求的。Alluxio 企业版支持了更高的写入性能，在测试中，单线程同步写入 HDFS 能达到1.2-1.4GB/sec 的速度，如果还是按照每隔 3 小时做 200GB 的 checkpoint 来算，每天花费的时间将减少至 20 分钟，只占到全天时长的 1.4%，这能够大大减少模型训练做 checkpoint 的时长，提高 GPU 利用率。目前 Alluxio 写入的

71、上线正在内部测试，还没有正式上线。除了同步写入，后续知乎还计划上线企业版的异步写功能，在提升写入性能的同时，节省专线带宽。4.运维成本在社区版时，需要自己打包 Alluxio 的镜像，并且自己写 yaml 文件将 Alluxio 部署到 k8s 上，上线的流程十分复杂，有很多步骤需要手动操作，费时费力，还容易出错，下图是部署社区版所使用的脚本和配置文件的集合，可以看到一共有十几个文件。39Alluxio 企业版不仅提供了现成的 k8s 镜像，还提供了 operator 部署工具，可以一键启动集群，在 operator 安装好的情况下，部署一个 Alluxio 集群只需要一个配置文件，极大节省了

72、我们的运维成本。40三、持续合作，保持探索首先，Alluxio 社区版为知乎带来了混合云下 AI 存储的通用解决方案，能够在短时间内从自研组件无缝切换到 Alluxio 高性能缓存上，支持实现跨云训练；其次，在更加核心的场景下，Alluxio 企业版带来了更高的稳定性，更好的性能，更便捷的运维，更是支持了知乎内部千卡大模型的训练稳定高效运行。感谢 Alluxio 团队在上线过程中提供的帮助，后续也将继续保持合作，共同深入挖掘 Alluxio 的潜力，探索更多的应用场景，为知乎的技术发展贡献更多的力量。一、B站AI的训练场景机器学习平台介绍首先，简单介绍一下B站 AI 的训练场景，整个机器学习平

73、台的架构如下图所示：B站|Alluxio 在B站AI训练场景的应用41它具备了一个常规机器学习平台的能力，比如交互式建模、数据集管理、模型训练、模型部署等基础能力，用户也会有一些精确的数据集、业务团队以及资源运营相关的能力，同时对机器学习框架（比如业界流行的 TensorFlow、PyTorch、DeepSeed 以及自研的一些框架等）都需要兼容。同时，为了加速整个训练的收益，B站与 Alluxio 进行了很多合作，搭建了一个在 AI 训练场景的训练集群，调度器主要是 Volcano，是现在机器学习平台常用的。已有存储方案介绍下图是搭建 Alluxio 之前的存储方案，HDFS 主要针对大数据

74、的分析场景，B站自研的 OSS 存储叫 BOSS，还有一些 NAS 存储的系统，当然每个存储系统都有自己的优缺点，这里也简单的做了个对比。AI 训练场景介绍搜推1.一个是搜推，比如商业、广告、流量推荐，这种场景就是很明显的大数据存储的场景，跟 HDFS 这一套就非常的亲和。42432.CV/大模型场景这个场景也是目前使用 Alluxio 的一个主要业务场景，这里有一个特点，单数据集的规模很大，比如最近在用的一个数据集，已经达到了 PB 级，文件数量大概在亿级别，基本都是小文件。CV 训练以图片、音频等为主，基本都是100KB、1M大小，数据比较多样，有图片、视频、音频、文本等。AI 训练存储痛

75、点在训练过程中发现了几个存储方面的痛点：存储容量：1.因为现在随着大模型的引入，数据量会越来越大，对数据容量的要求会越来越高，像现在大数据集，可能会达到上百T；这是一个快速增长的过程，而且特别是最近的 Sora 带火了 TTV 这种场景，所以视频的规模会非常大，存储系统需要具备高扩展性以应对不断增加的数据需求。2.性能瓶颈：高吞吐：AI 训练需要频繁读取和写入数据，存储系统需要支持高吞吐量以保证数据加载速度低延迟：数据读取的延迟应尽可能低，否则会影响训练效率，导致 GPU/NPU等计算资源的浪费。正如大家所熟知的，现在买卡非常难，如果 GPU 由于 IO 导致利用率低，那肯定是不划算的3.成本

76、、安全：高成本：存储大量数据尤其是高分辨率图像和视频数据，存储成本很高，需要平衡性能和成访问控制：需要对数据访问进行细粒度的权限管理，确保数据安全。基于 Alluxio 的训练存储架构44为了解决这些痛点，在调研之后，采用了 Alluxio 的方案，主要有三大吸引点：统一命名空间：将不同存储系统（如 HDFS、BOSS、云存储）抽象为一个统一文件系统接口，对用户来说不用感知底层的 HDFS，只需要挂 Fuse；内存或 NVMe 缓存：结合内存和 NVMe 存储缓存，提升访问速度，降低 I/O延迟，用的比较多的是 NVMe 的场景，大量 GPU 都会高配这种 NVMe；多存储后端：兼容 HDFS

77、、对象存储等多种存储后端，扩展性强。二、Alluxio 在 AI 训练场景的应用为什么选择 Alluxio？这里先介绍一下 Alluxio 的主要优势：性能高：低延迟高吞吐的数据缓存能力，对于 AI 训练尤其重要；兼容性强：支持 S3/HDFS 后端，提供了广泛的数据源兼容性；兼容 POSIX 协议；运维成本低：运维成本在大规模数据存储和处理环境中尤为重要，有助于减少整体运维投入；大规模数据处理：Alluxio 支持亿级的数据量规模，能满足 AI 训练需求。45在做技术选型的时候，也对业界常用的几个系统做了调研和分析，基于B站的体量，B站没有人力单独为 AI 做存储的维护，所以第一个优先考虑的

78、就是成本，需要投入更低的成本、更低的运维，支持更强的性能。在调研过程中 Alluxio各方面表现优势明显，最终选择了 Alluxio。单集群 or 多集群？在部署的时候 Alluxio 采用的是一种多 Master、多 Worker 的方式。但B站在大数据集场景是一种单集群部署的模式，优势是：一个集群可以集中管理、运维成本比较低，可以实现资源的高效利用；缺点是现在社区版2.9.4的元数据存储在 Master，很容易碰到天花板，扩展性比较有限，如果单个集群出现了问题，对业务的影响是比较大的，所以在 AI 场景最终采用的是多集群部署的方案。46基于整个集群的存储规模，集群的划分会按照业务或者是数据

79、集，好处是某个业务或者数据集需要更强的能力，则会投入更多的资源，而对于那些不怎么重要的业务，或者是低优先级的业务，则需要把它隔离开，从而不至于让低优先级的业务影响到高优先级的业务，这是最终采用的方式。通过多集群的方式，在部署运维方面会增加更多的成本，那么如何解决这个问题？基于 Fluid 的云原生多集群部署方案47这里引入了 Fluid。Alluxio 是对底层存储的抽象，Fluid 又是对 Alluxio 这一层Runtime 的抽象。通过 Fluid 之后，可以更好的在 K8s 上，更自动化的部署多集群的方案，目前B站应该有百机规模的集群。调度优化48另一个问题是，在实际应用中使用的是 v

80、olcano 调度器，主要是 binpack 为主，binpack 的策略是尽可能的把单台机器塞满，对 IO 密集型的业务，如果把所有的节点都调度到单台机器上，很容易造成单点故障，给 IO 造成瓶颈，另外也会带来网络拥塞、资源利用不均等问题。解决办法：结合了业务特点以及本身的缓存加速场景，采用的是拓扑感知的调度策略。首先，会尽可能的让 Alluxio 的节点分散到集群的每台机器上，尽可能的把IO 打散。其次，在任务调度的时候，也会去感知 Alluxio 的拓扑分布，尽可能做到任务与 Alluxio 节点的亲和，这样亲和之后相当于在读本地硬盘。元数据同步的必要性:元数据同步在 Alluxio 中

81、至关重要，因为它确保 Alluxio 文件系统与底层存储系统中的数据保持一致，这个问题B站也同样遇到过。当数据量大了之后，如果按照官方的元数据同步方法，对整个集群的稳定性和性能都会有很大的影响，所以最终采取了一种按需同步的方法。这里已经把集群暴露给用户，他可以直接操作他的集群，知道什么时候数据是更新的，由他来决定；另外，如果是那种亿级别的数据集要做 Meta 同步，至少是小时级别，这个肯定是不可接受的，所以也在要求用户最小化他的同步单元，尽可能的减少无效的同步计算。具体同步方式:基于时间的自动同步：设置alluxio.user.file.metadata.sync.interval 属性来定时

82、同步；手动同步：使用 loadMetadata 命令或 API 手动触发同步。元数据同步加速49加速方式：按需同步：只在需要时触发；最小范围同步：最小范围同步，减少无效同步计算。超大规模小文件优化50很多场景的数据都是以小数据为主，如果只是简单的把数据给到 Alluxio，然后什么都不做，这样就会有两个问题，一个是 Meta 会很多，本身B站采用的就是Master 的架构，整个集群对 Master 的压力会很大；另一个就是用户会无组织的去用，因为他根本就不知道该做哪些组织才有利于数据的 IO。这块主要是做了数据合并，也是在训练场景用的比较多的一种方式，把一个图片做成一个 chunk，chunk

83、 里边再做一个下浮，可以做到指数级的降低文件的 Meta 信息，并对整个训练的效果都不会有太大的影响。51Alluxio 带来的效益在实际应用过程中测下来，亿级别的单节点性能基本能达到 IOPS 在 3000+以上，整个业务包括审核、大模型，都在用这一套，现在已经缓存的数据集大概在几百T规模左右。三、未来规划Alluxio 之前介绍过知乎的推理场景，这个场景B站也有比较大的痛点，所以B站也在尝试探索更多的可能。另外就是现在 Master 元数据管理是一个很痛的点，在这种场景下 Alluxio 最新的 Dora 框架可以带来多大的收益，也是需要进一步去调研的，同时，因为是一个机器学习平台，应用场

84、景非常单一，同时也在跟B站的存储专业团队做一个更大规模、更通用的 Alluxio 解决方案，这是现在在做的，也是后续打算去推的。辉羲智能|Alluxio在自动驾驶模型训练中的应用与部署52一、自动驾驶数据闭环首先分享一下自动驾驶中怎么样构建数据闭环，这个业务过程可能大家都有所了解。自动驾驶会包含多种车辆类型，比如数采车辆、带着算法在路上跑的车。数据采集就是在跑的过程中采自动驾驶车上的各种数据：比如说 camera 的数据就是图片，激光雷达的数据是点云。传感器数据采回来，可能一辆车每天跑下来就有几T的数据。这种数据通过基盘的方式或者其他上传方式把它们整体存储起来，传到对象存储里面。原始数据存储之

85、后会有一个 pipeline 做数据的解析预处理，比如把它切成一帧一帧的数据帧，每帧的不同传感器数据之间可能还要做同步对齐的操作。53完成数据解析之后，就要在上面做更多的挖掘。构建一个一个的数据集。因为不管是在算法、仿真或者测试里面，都要构建数据集。比如想要雨天的某一个晚上，某一个路口，或者一些密集形成区域的数据，那就会在整个系统里面有大量的这种数据需求，要做数据的打标，打上一些标签。比如说在清华东门这个地方，需要去拿这个位置的经纬度，解析周围的 POI。之后再对挖掘出来的数据做标注。常见的标注有：对象、行人、对象的类型等。这种做了标注的数据，会被拿去做训练。典型的一些任务，比如目标的检测、车

86、道线的检测、或者更大的端到端的模型。模型训练好了之后，还要做一些仿真验证。验证完再把它部署到车上面，再去跑数据，在这个基础上再去采更多的数据。就是这样的一个循环，不断的去丰富数据，不断的去构建性能更好的模型。这是整个训练，数据闭环要做的事情，也是现在自动驾驶研发里面较核心的事情。二、算法训练：NAS聚焦到模型训练来讲：模型训练主要是通过数据挖掘拿到数据，从而生成一个数据集。数据集在内部是一个 pkl 文件，包含数据、channel、存储位置，最后数据算法训练的同学会自己写下载脚本，把数据从对象存储拉到本地。54在选用 Alluxio 之前，是通过 NAS 系统充当缓存的作用，把对象存储的数据拉

87、到NAS 上面，最后再用不同的模型，把数据 load 进来进行训练。这是使用 Alluxio之前，大概的训练流程。其中最大的问题在 NAS：第一是并发性能比较差NAS 可以理解成它就是一块大的硬盘，当只有几个任务一起跑的时候，还是比较够用的。但是当有几十个训练任务同时进行、很多模型在训练的时候，往往就会出现卡死。曾经有一段时间卡死非常严重，研发每天都叫苦不迭。卡得严重以至于可用性非常差、并发性能很差。1.第二是管理困难每一个人都用自己下载的脚本，然后把想要的数据下载到自己的目录下面。另一个人可能又自己去下另外一堆数据，放到NAS的另外一个目录下面，这样就会造成 NAS 空间满时很难做清理。当时

88、基本都是当面或者微信群沟通。一方面是效率特别低，依靠群消息管理会滞后。另外一方面，也会因为手动 remove，导致一些风险。曾经出现过 remove 数据时，把别人的数据集给删掉的情况。这也会造成线上任务区域的报错，这是另外一个痛点。2.第三是空间浪费不同人下载的数据放在不同目录下，有可能同样一帧数据会出现在好几个数据集，存在比较严重的空间浪费。3.第四是使用很复杂因为 pkl 里面的文件格式不相同，使得下载逻辑也不一样，每个人都要单独去写下载程序。4.这是之前用 NAS 会面临的一些困难和问题，为了解决这些问题而做了一些调研。调研后聚焦到Alluxio上来。发现 Alluxio 它可以提供一

89、个比较统一的缓存，缓存可以提升训练速度，同时也可以减少管理成本。还会用 Alluxio 的系统，处理双机房的问题。通过统一的命名空间和访问方式，一方面可以简化了系统设计，另外在代码实现上也会变得很简单。55三、算法训练引入 Alluxio当把 NAS 换成 Alluxio 之后，Alluxio 能够针对性的解决刚才提到的一些问题：1.在并发性方面NAS 本身不是一个完全分布式的系统，而 Alluxio 是。NAS 它访问的 IO 达到一定的速度时会出现卡顿，可能达到几个 G/s 的时候就会开始卡。而 Alluxio 的上限非常高，下面还有专门的测试来说明这一点。562.通过手动清理或者管理会非

90、常麻烦Alluixo 会配置缓存的逐出策略。一般是通过 LRU，当到一个 threshold 的时候（比如90%）它会自动做缓存的驱逐和清理。这样做的效果：效率大大得提升；可以避免因为误删导致的安全性问题；解决了重复数据的问题。在 Alluxio 里面，一个 UFS 里面文件，对应到 Alluxio 就是一个路径，当所有人都去访问这个路径时，就可以拿到对应的数据，这样就不会存在重复数据的问题。另外使用上面也比较简单，只需要通过 FUSE 的接口方式访问，不再需要下载文件。以上是从逻辑层面解决了刚才讲的各种各样问题。下面讲一讲，整个落地的历程，怎么从 0 到 1 实现 Alluxio 从开始的

91、POC 测试，到各种性能的验证，再到最后怎么样部署、运维等的一些实践经验。四、Alluxio 部署：单机房57首先可能会在单机房里部署，就是一定要临近 GPU，部署到 GPU 节点上。同时利用之前 GPU 上很少用的 SSD，把每个节点都利用起来，然后把 FUSE 和 worker部署在一起。FUSE 就相当于客户端，worker 就相当于一个具有内网通信的缓存小集群，做FUSE 的服务。最后对应的通过 worker 自己对底层的对象存储做通信。五、Alluxio 部署：跨机房但是由于各种各样的原因，还会有跨机房的存在。现在有两个机房，每一个机房里都会有对应的 S3 服务，也会有相应的 GPU

92、 计算节点。基本上每一个机房都会部署一个 Alluxio。同时在这个过程中也要注意，一个机房里可能是两个 Alluxio 的对象存储，另外一个机房如果也要做 S3 挂载，尽量做好 bucket 名字的统一规划，不能把两个搞重了。比如这里有个 bucket 1，那里又有一个 bucket 1，会导致 Alluxio 挂载时的一些问题。58还要注意，不同的 endpoint 要注意内网和外网的区分，比如集群1的 Alluxio，挂载集群1的 endpoint 内网，在另一边就是外网，反之性能就会大打折扣。挂载之后可以通过同样的路径去访问不同集群上面不同 bucket 的数据，这样其实整个架构就会变

93、得非常简单，这是跨机房部署方面。六、Alluxio 测试：功能想要真正把 NAS 换成 Alluxio，在部署之前要做很多功能测试。这种功能测试，目的是让现有的算法流程通过最小程度的改造，让算法同学也能用起来。这里可能要根据各位实际情况去操作。当时和 Alluxio 做过接近2-3周的 POC 验证，其中会涉及到如下内容：K8S 上访问 PVC 的配置；数据集的组织方式；作业提交的配置；访问路径的替换；最终访问的脚本接口。59以上遇到的诸多问题可能都要做验证，至少要通过它选一个典型任务，然后做一些改造，最后才能把 NAS 比较平稳的换成 Alluxio。七、Alluxio 测试：性能接下来在这

94、个基础上，还要做一些性能测验。在这个过程中，不管是单机还是多机，都做了比较充分的测试。在单机上，Alluxio 和原来的 NAS 基本上性能是打平的。其实真正体现 Alluxio 优势的是多主机上、分布式的能力。可以看到 NAS 或者举例的 QTS，它有一个非常明显的点：不稳定。测试3G 到 10G 间波动会比较大，同时它有一个明显的瓶颈，达到 7/8G 左右，就基本上稳定了。60而 Alluxio 这边，整个测试过程，节点随着运行实例的增加，可以达到一个非常高的上限，当时设到 20GB/s时，它都还是呈现出一直向上的趋势。这说明 Alluxio整个并发的、分布式的性能非常好。八、Alluxi

95、o 落地：调参适配环境做完功能验证和性能测试之后，就真正的要实际部署 Alluxio 集群，部署好之后，需要一个参数调参适配的过程。因为测试时，只采用了一些典型的任务，真的上Alluxio 环境之后，会发现随着任务增多，会有一个参数调参适配的过程。需要把Alluxio 上面相应的参数跟实际运行环境做匹配，然后才能够把它性能给发挥好。所以会有边运行、边运维、边调参的过程。其中经历了一些典型的调参过程，比如说：ETCD 的节点：一开始是 1 后来增加至3节点，这样就保证即便某个ETCD节点挂了，整个集群不会受到影响。与 S3 相关的：比如说 Alluxio 在实现的时候，他会让 S3 生成一个访问

96、比较长的路径，会在中间的路径节点，默认写一些空白，以至于让它具有更好的性能。但是这种情况下，训练任务下面的 S3，是做了权限管控的，不允许他们去写这种数据。面对这种冲突，也需要调参。61FUSE 节点本身能忍受的并发强度的能力：包括它要使用的 Direct Memory 的大小，实际上也和整个业务实际运行并发的强度多少有很大关系。和能够一次性访问的数据量其实是有很大关系的，这也有一个调参的过程，不一而足。可能会在不同环境下遇到不同的问题。这也是选择 Alluxio 企业版的原因。因为在企业版的过程中 Alluxio 会有非常强的支持，7*24h 都可以做到遇到问题去调整、去配合。有了相互配合的

97、周期，才能够让整个集群比较顺畅地运行起来。九、Alluxio 落地：运维团队最早运维的同学只有一个人，他负责很多底层 Infra 的维护和相关工作，当我要把 Alluxio 部署上来的时候，其实运维那边的资源是不够的，所以相当于我也兼半个运维。从自己要去运维一个东西的角度来说，要做好很多运维方面的记录和知识沉淀，特别是对一个新手来讲很重要。比如下一次出现问题怎样更好地解决，是不是之前已经有过这样的经验。针对当时的环境，会维护好三份文档。运维的历史记录文档：比如说哪一天出现了什么问题，这些问题我找到它根因是什么，它的解决方案是什么？具体操作是什么？62操作文档：比如在 K8S 上运维，它的重启是

98、哪几步、操作是什么、出现问题怎样去看日志、怎样去排查、去看FUSE对应的数据是哪个任务、哪个 worker 上面去运行、监控等等。都是常用的一些操作。配置的变更：因为 Alluxio 具体在调参的过程中。不同的时候，可能遇到的配置文件、yaml 文件是不一样的，可能还要做一些备份。可以用 Git 管理，也可以简单地采用文档管理。通过这种方式可以追溯到当前配置和历史配置版本。在此基础上，还会有一些相关的配套建设，就是为了更好地使用 Alluxio。研发同学使用下来认为 Alluxio 蛮好用的。但多任务的时候，就暴露出来一些配套建设的需求。比如要做图片的 resize，把图片从一开始高清4K，降

99、到 720P，以便支持更多的任务缓存。训练数据集做跨集群同步，以便更好的做数据预加载。这些都是围绕着 Alluxio 要做的系统化建设。十、Alluxio 落地：共同进步在不断使用 Alluxio 的过程中，也会发现一些值得改进的地方，通过给 Alluxio 反馈，促进了整个产品的迭代，从研发算法同学那边，他们 care 的是：稳定性：一定要在运行过程中稳定，不能因为 Alluxio，一些东西 crash 了，让整个系统训练受阻。这里面可能有一些运维的小技巧，比如说尽可能不要让FUSE 重启。刚才也提到了 FUSE 重启就意味着它的访问路径，读数据文件的时候，会失败、出现 IO 的 error

100、。确定性：比如 Alluxio 之前建议数据不需要做预加载，即不需要在预训练之前读一遍，只需要在第一个 epoch 过程中读一遍。但是因为研发有发版周期，他要明确的知道预加载要多长的时间，如果通过第一个 epoch 去读，很难预估整个训练时间。这里面其实也会引申出来，怎样通过一个 file list 做缓存这件事情，这个也给 Alluxio 提了一些需求。63可控性：虽然 Alluxio 是可以提供自动化的基于 LRU 的缓存驱逐清理缓存。但是实际上研发还是希望，一些已经缓存过的数据，能够主动做一些清理。那么能不能也通过提供 file list，让 Alluxio 把这块数据给 free 掉。

101、这也是除了间接的用 Alluxio，还要直接的、非常可控的用 Alluxio 的需求。从运维的这一端，也会提一些需求：配置中心：Alluxio 自己可以提供一个配置中心，把配置的历史给保存下来。增加一个功能以便实现配置项更改时，提前预算到这个改动到底影响的是什么；Trace跟踪一个命令的运行过程：另外一个比较现实一点的需求，比如现在发现一个问题：访问底层的一个 UFS 文件时延时比较高，到底是什么原因？看FUSE 的日志可能看不出原因，得需要再去看 location 对应的worker日志。这其实是一个非常耗时、麻烦的过程，而且往往排查不了问题，还需要Alluxio的线上客服支持。Alluxi

102、o 能不能加一个 Trace 命令，在要做访问的时候，把FUSE 耗时、worker 耗时、以及从 UFS 里面读它的耗时，一个全链路的耗时问题给 Trace 出来。这样其实对整个运维过程或者排查过程会有比较大的帮助。智能监控：有时候监控的东西是已经知道的东西。比如说 Direct Memory 有问题了，去配一个监控项。但是如果下一次一个新问题在我的日志里面出来了，它可能是一个隐藏的问题，在人不知道的情况下悄悄地发生。这种情况希望可以自动的监控出来。通过工单反馈的方式，给 Alluxio 提了各种各样的建议。希望 Alluxio 能够在产品迭代过程中，提供更强大的功能。把整个研发、运维 ca

103、re的事项，做到更好的满足。十一、小结第一，从 Alluxio 在整个自动驾驶模型训练的缓存加速方面，对比 NAS 它提供了很好的可用性。对辉羲来说它也会有10倍左右的提升。成本的降低来源于两部分:64产品采购成本低；NAS可能会有20%-30%的冗余存储，Alluxio 都可以解决掉。从可维护性的角度来讲，它可以自动清理数据，更加及时，也更加安全。易用性方面，它通过 FUSE 可以更便捷的访问数据。第二，我也分享了辉羲是怎么样去从 0 到 1 部署 Alluxio，运维一个系统。中汽创智|Alluxio在自动驾驶数据闭环中的应用65一、自动驾驶业务介绍首先介绍一下中汽创智的自动驾驶整个开发业

104、务流程。现在围绕自动驾驶开发主要强调的是数据闭环：开始是数据采集，数据采集之后进行预处理/数据挖掘，包括一些大模型的预刷；接着进入数据标注环节，主要包括人工标注和一些自动化的标注；标注以后产生的带有增值的数据集，提交给算法进行开发训练，如模型训练、评测和推理；最后再去迭代整个自动驾驶模型，模型经过上线进行实车部署。在数据采集环节，自动驾驶的采集车需要经过改装，进行传感器的标定，主要在标定厂里对车端的一些传感器进行刚性位置的关系调教，改装完的车去做实测采集，比如在城区的道路、高速公路进行采集。每天采集的数据量非常大，一天一辆车采集的数据大概在 1 TB 左右。而采集回来的数据量没办法通过线上传输

105、的方式上传到私有云或者公有云里，一般是通过特殊的存储介质拷贝带回来。当然也有实时的采集，比如每隔多长时间需要去做一些采样，这种数据是可以通过实时的采集传输到私有云里。66可以看到自动驾驶业务的每个流程里都有数据传输和拷贝的环节，这都是跟存储加速强相关的。关于标注，公司内部研发了一个人工标注的数据平台，主要把采集回来的数据进行预处理，因为原始的数据可能是一个 bag 包，如同现在机器人开发里基于 ros，里边类似于 Java topic 机制，可以去订阅包括点云、图片、轨迹数据等，而这些数据是存储在一个二进制的很大文件里。经过预处理要对应到每一个时间戳，比如它有一个频率，每秒大概两帧或者是几帧，

106、然后把这些数据做参数时间戳上的对齐，包括做一些插值，去处理成算法或人工标注所能识别的数据集（可能包括一组文件，里面有 point cloud 这样的文件夹。文件夹里是一帧帧的点云。车上可能有一系列前后左右一组传感器camera，每个时间戳下面都有对应的一张2D图片和一些轨迹，包括内外参的一些参数）。在处理成这种格式的数据之后，然后会把数据集上传到数据标注平台里进行增值的标注。标注包括多模态，如 3D 的点云，2D 图片/camera。点云和图片标注的时候会做 3D 到 2D 的转换，这个过程从人工标注之后进入到人工审核验收环节，最后流转出来到导出层，就成为了算法所需要的数据集（主要是一些增值数

107、据，比如标注的box、车道线、车道线障碍物、锥桶、行人以及路上的设施）。在模型开发训练阶段，自动驾驶的主要算法模块包括感知、预测、定位、规控。传统是基于分层的架构开发，每个模块有上下层的逻辑关系，现在比较流行的是端到端的模型训练，类似于人脑，依靠眼睛、耳朵来接收外界的输入信号，通过内容融合的大模型，最终输出自动控制车辆的行为。对于模型训练，我们与很多大型企业一样有自己的智算中心，会有很大的投入去建设 GPU 集群用于训练，然后数据集会源源不断的进行输入。最后是模型评测和模型上线。67数据存储管理的痛点：在整个数据闭环中，数据存储是影响整个开发的非常大的痛点。因为数据是自动驾驶的三要素之一，它像

108、血液一样，能驱动算法，驱动整个业务流程。如果没有数据，算法仅仅是一堆代码，模型根本无法支撑自动驾驶。在自动驾驶场景，数据是海量的，包括有采集车数据，一年的规模在几个PB，如果是长年累月的积攒，这个量是无法估量的，还有座舱数据、平台的业务数据和指标数据，这些都需要管理和治理。数据闭环过程中，往往存在重复性的拷贝，重复读写相同数据，造成效率低下。平台和算法都存在大量数据上传下载的业务逻辑，并且读写的效率低下。二、数据平台架构以及存储选型存储类型方案1：JuiceFS之前也调研过 JuiceFS，并且在数智化部门也有使用的案例。由于中汽创智数据湖底座是在 OBS 上，对象存储里的数据有多种使用方式，

109、JuiceFS 是自己实现了分布式文件系统的元数据层，按照自己的协议把数据写入 UFS，虽然通过gateway方式也支持多种协议的读写，但是算法还保留着对象存储 API 使用方式，所以出于数据可用性考虑放弃。方案 2：Alluxio（最终采用）接触Alluxio是在使用 JuiceFS 之后，在多个平台里面共享存储这样的需求，涉及到采集、数据筛选/数据挖掘、合规、标注、训练推理、仿真等相关业务，希望有统一底层 UFS 数据接入，读写加速、把读写 UFS 的能力下沉到中间件层，提升业务的效率；Alluxio 开源版本2.9.3的功能特性能够满足当前的需求。Alluxio 介绍Alluxio 作为

110、机器学习生态系统大数据中的新增数据访问层，可位于任何持久化存储 系 统（如 Amazon S3、Microsoft Azure 对 象 存 储、Apache HDFS 或OpenStack Swift）和计算框架（如 Pytorch、TensorFlow、Apache Spark、Presto或Hadoop MapReduce）之间，但是 Alluxio 本身并非持久化存储系统。使用 Alluxio 作为数据访问层可带来诸多优势：对于用户应用和计算框架而言，Alluxio 提供的快速存储可以让任务（无论是否在同一计算引擎上运行）进行数据共享，并且在同时将数据缓存在本地计算集群。因此，当数据在本

111、地时，Alluxio 可以提供内存级别的数据访问速度；当数据在Alluxio中时，Alluxio 将提供计算集群网络带宽级别的数据访问速度。数据只需在第一次被访问时从底层存储系统中读取一次即可。因此，即使底层存储的访问速度较慢，也可以通过 Alluxio 显著加速数据访问。为了获得最佳性能，建议将Alluxio 与集群的计算框架部署在一起。就底层存储系统而言，Alluxio 将 AI 应用和不同的存储系统连接起来，因此扩充了能够利用数据的可用工作负载集。由于Alluxio 和底层存储系统的集成对于应用程序是透明的，因此任何底层存储都可以通过 Alluxio支持数据访问的应用和框架。此外，当同时

112、挂载多个底层存储系统时，Alluxio 可以作为任意数量的不同数据源的统一层。内部架构如下：68数据平台架构69中汽创智的海量数据主要是非结构化数据，有别于传统的数仓是结构化的数据（语义直接在数据里），而自驾的数据都是非结构化的，如你光看这些文件（图片、视频或者是点云）并不清楚里面是什么，只有通过挖掘之后才知道它表达的是什么语义，蕴含什么信息。这些需要抽象出来在数据库和数仓里去表达。架构中数据湖架构底层由对象存储和 HDFS 组成，上面是分布式缓存加速层，如Alluxio；再往上会将抽象出来的非结构化数据元数据，业务数据存储在 OLTP/OLAP 数据库中，通过流式 cdc 或者数据集成工具同

113、步写入数据湖，采用Hudi/Iceberg/Delta Lake 这样的 tableformat 数据格式，也是为了解决早期 Hive 在upsert 场景上的性能问题；往上是元数据层，接着再往上集成了如 Clickhouse 和Doris等 OLAP 引擎对业务层进行查询，数据湖则通过 Trino 进行交互式分析。整个数据湖架构为上层业务平台以及算法、工具链提供 DataOps 支撑。70三、自动驾驶数据平台使用场景当前方案目前部署了 3 Master+10 Worker，客户端随应用侧使用sidecar 方式部署，应用 pod 中业务容器和 sidecar 容器通过存储卷的共享传播机制实现

114、挂载。主要使用到的 Allluxio 3大特性：简化数据管理：Alluxio 提供对多数据源的单点访问，能够对多个独立存储系统提供单点访问，无论这些存储系统的物理位置在何处。这提供了所有数据源的统一视图和应用程序的标准接口。内存速度 I/O：Alluxio 能够用作分布式共享缓存服务，这样与 Alluxio 通信的计算应用程序可以透明地缓存频繁访问的数据（尤其是从远程位置），以提供内存级 I/O 吞吐率。此外，Alluxio的层次化存储机制能够充分利用内存、固态硬盘或者磁盘，降低具有弹性扩张特性的数据驱动型应用的成本开销。应用侧实现数据本地挂载 Alluxio-fuse应用案例一在标注平台有个

115、场景是上提数据集。数据集有大有小，一般上提数据集文件数处于较小规模时没有问题，但如果有一个很大 BEV 数据集，1个包大概5至6GB，需要再上提的时候，把原始目录下的文件做转换，一些文件夹的处理。然后，按照每一帧组装好元数据，因为如果是图片可能比较大（几 MB 至十几 MB），特别是在标注平台里，由于加载原始图片比较大，会涉及到生成缩略图。比如1帧可能会有 7个camera，每个图片会生成大、中、小 3 个缩略图，这样就放大 3 倍。假如现在有3,000 帧，一个摄像头就可能变成 9,000 张图片，然后再加上 6 个摄像头，那就再乘以 6 倍，这个数据量就蹭蹭上去了。之前为使用 Alluxi

116、o 的时候，还是通过传统方式先在本地生成，接着通过对象存储的 API 去上传，但当上提较大数据集时（文件数在1w左右），则会出现 gc 问题，刚开始采用多线程并且加内存资源，也依然存在问题，出现 GCLocker 的告警，并且一直重试申请分配对象，最终导致 OOM。使用了 Alluxio之后，把这么多文件通过 MQ 分发到缩略图服务里，然后把 OBS或者 MinIO 通过 sidecar 方式挂载到服务的 pod 里，这个时候可以看到速度非常快，性能也好，没有再出现之前的问题。之前读写方面的瓶颈问题，也通过Alluxio 解决了，非常能够体现 Alluxio 的价值。应用案例二71第二个是合规

117、平台场景。现在企业里很多都要讲究数据的合规，它是把采集回来的数据根据法律法规去做一些数据的糊化和转换，首先是对数据进行分类分级，之后识别出敏感的数据，再通过数据抽帧，对于敏感的帧要进行识别和删除。剩下的数据，比如点云或轨迹，里面会有一些地理性的坐标，这种精准的信息是不允许对外的，只有经过坐标偏转之后才能对外提供服务。最后是个性脱敏，比如拍到的图片里面有人脸、车牌这些属于个人隐私的内容，需要通过算法推理做糊化，输出的图片才能交付给下游使用。这些服务是通过工作流串联起来的，比如通过消息队列，在每个服务侧挂载了Alluxio，采用 Alluxio sidecar 方式将对象存储挂载到本地，所有数据流

118、转都通过写入本地挂载路径，通过 Alluxio 同步到 OBS。当 FUSE Client 开启 cache，Alluxio Fuse 的读取速度从 50MB/sec 提升到了 200MB/sec；敏感区识别和个人脱敏（人脸和车牌识别糊化）这些推理服务加载预热后的 Alluxio 数据，推理性能提升了40%。应用案例三72第三个场景是仿真测试平台案例。如图左边的集群是业务集群在 K8S 里，右边是由 C+和 C#写的仿真程序，名字叫Smartview。原先在仿真测试平台有个播放bag 包的case，平台需要获取 OBS 上采集数据目录，然后拉取 bag 包进行仿真程序的回放播包，给算法进行一些

119、 corner case 的定位以及回放；仿真程序单独部署在一个工控机上，运行在 Docker 容器中，需要让 k8s 集群外的 fuse 客户端能访问集群中的 Alluxio；这个时候需要对 Alluxio集群做修改，比如 worker 的配置，将 worker 中 hostNetwork 置为 true。现在仿真测试也是在用这个环境，1个 bag 包大小都不一样，最小的也超过1GB，属于大文件的读写，在仿真程序里播包没有任何的延迟，都很顺畅。Sidecar 接入方法业务要接入 Alluxio 实现挂载 obs 需要在 k8s 部署 yaml 文件增加如下配置：比如 haohan-datai

120、nject 服务的 deploy.yaml 中增加：1.pod 配置中增加用户权限配置：securityContext:runAsUser:0 runAsGroup:0 fsGroup:02.pod 增加存储卷申明：volumes:-name:alluxio-fuse-volume emptyDir:3.增加 sidecar 容器配置：（resources 部分可以自行定义）734.业务容器增加挂载配置：74知识点-挂载卷的传播：挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。卷的挂载传播特性由 Container.volumeMount

121、s 中的mountPropagation 字段控制。它的值包括：None-此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。该模式等同于 mount(8)中描述的 rprivate 挂载传播选项。然而，当 rprivate 传播选项不适 用 时，CRI 运 行 时 可 以 转 为 选 择 rslave 挂 载 传 播 选 项 （即HostToContainer）。当 挂 载 源 包 含 Docker 守 护 进 程 的 根 目 录（/var/lib/docker）时，cri-dockerd(Docker)已知可以选择

122、rslave 挂载传播选项。HostToContainer-此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。类似的，配置了 Bidirectional 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 HostToContainer 的容器都将能看到这一变化.该模式等同于 mount(8)中描述的 rslave 挂载传播选项。Bidirectional-这种卷挂载和 HostToContainer 挂载表现相同。另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。该模式

123、等同于mount(8)中描述的 rshared 挂载传播选项。AlluxioFuse 这里一共有三个挂载：AlluxioFuse 把 Alluxio 挂载到容器内的/mnt/alluxio-fuse 目录下；k8s 把宿主机路径/mnt 以 bi-direction 的方式挂载到 AlluxioFuse 容器内的/mnt 路径；k8s把宿主机路径/mnt 挂载到 application container 内任意路径。75先 说 第 三 个 挂 载，application container，其 实 把 宿 主 机 的 /mnt 还 是/mnt/alluxio-fuse 挂进去都是可以的，只不

124、过容器内部会是不同的路径访问数据，多了一层子目录 alluxio-fuse,前两个挂载是有一点 tricky 的。如果 k8s 把目录 /mnt/alluxio-fuse 挂 进 fuse container 的 /mnt/alluxio-fuse，然 后alluxioFuse 又把 Alluxio 挂到/mnt/alluxio-fuse，会把第一个挂载给挤掉。这个其实还算比较符合直觉，不可能把路径A和路径B都挂到路径C上。挤掉之后这层宿主机和alluxio-fuse 的 connection 就没有了，application 自然也就没办法读到数据。当然用户如果不想把一整个/mnt 都挂进f

125、use container 里面，也可以用/mnt/alluxio/alluxio-fuse 取 代 /mnt/alluxio-fuse，/mnt/alluxio 取 代/mnt。JAVA API 访问 Alluxio应用 pom 文件添加依赖：76 org.alluxio alluxio-core-client-fs 2.9.3 数据预热：Alluxio master 默认是存储元数据的，挂载以后客户端侧默认能看到所有挂载路径下的文件系统系统其实是通过 master load 到元数据，但是业务访问文件系统实际上还要取load数据，数据块是存储在 worker 中的，如果 worker没有则

126、会去底层的 UFS 即 obs 加载数据，这个在业务运营过程中其实对性能是有损的，所以通常我们惯用的方法就是提前数据预热。Alluxio 的 Java api 中 FileSystem 接口提供大部分文件系统的操作 API,比如新建、删除、挂载、读取、加载元数据等等，当然也有通过 job service 方式提供了其他额外的接口，比如 LoadJob，即可实现 load 数据到 worker。代码如下：77try AlluxioProperties properties=new AlluxioProperties();properties.set(PropertyKey.MASTER_HOST

127、NAME,10.79.180.14);properties.set(PropertyKey.MASTER_RPC_PORT,30619);AlluxioConfiguration conf=new InstancedConfiguration(properties);FileSystem fs=FileSystem.Factory.create(conf);AlluxioURI path=new AlluxioURI(/origin/101/1664083078340767745/CAIC_郁健峰_L42340_南京市_城区_晴天_天_20221104_rosbag_202211041650_

128、1667551809843);LoadJobPOptions.Builder options=alluxio.grpc.LoadJobPOptions .newBuilder().setPartialListing(true).setVerify(true);LoadJobRequest job=new LoadJobRequest(path.getPath(),options.build();Optional jobId=fs.submitJob(job);if(jobId.isPresent()System.out.printf(Load%s is successfully submitt

129、ed.JobId:%s%n,path,jobId.get();else System.out.printf(Load already running for path%s,updated the job with +new bandwidth:%s,verify:%s%n,path,unlimited,verify);catch(Exception e)System.out.println(Failed to submit load job +:+e.getMessage();遇到的问题中汽创智的场景有读写，读其实没有太大的问题，但是写入目前2.9.3版本不支持追加写目前写的需求。目前是先写临

130、时目录，然后复制到指定分发目录；元数据同步，目前 Alluxio 是通过设置 metadata sync interval 设置相关UFS 的元数据同步,如果开启设置固定时间间隔，主要担心对 Alluxio 自身有性能影响，所以还是通过手动通过命令或者代码触发元数据同步。78四、未来规划从基础设施层去优化整个 Alluxio 集群的性能，赋能算法训练推理将 Master 独立部署稳定性保障将 Worker 与 GPU 节点混布降本增效将 Worker 与 Fuse 混布本地缓存书关于Alluxio（扫码添加小助手）（扫码关注Alluxio）Alluxio是全球首个分布式超大规模数据编排系统，孵

131、化于加州大学伯克利分校AMP实验室。自项目开源以来，已有超过来自300多个组织机构的1200多位贡献者参与开发，包括全球最头部科技公司、最顶尖的计算机科研院所等。Alluxio聚焦于AI和数据分析场景，可加速企业Al产品价值变现，并最大化基础设施的投资回报率。Alluxio 数据平台位于计算与存储系统之间，能够在数据工作流的各个阶段为数据平台上的工作负载提供统一视图。无论数据位于何处，该平台均可提供高性能的数据访问，简化数据工程，提高GPU 利用率，并降低云计算和存储成本。企业无需使用专用存储，即可大幅加速模型训练和模型服务，并在现有数据湖上构建Al基础设施。Alluxio在头部投资者的支持下，为全球科技、互联网、金融和电信企业提供商业化服务，目前全球排名前10的互联网公司中有9家在使用Alluxio。