Alluxio助力AI模型训练加速宝典 2.0（实战篇）

小红书|加速云端机器学习-Alluxio在小红书的实践15.一、面临的挑战15.二、多云数据加速层16三、小红书实践案例18四、未来规划29知乎|AlluxioAI助力知乎千卡模型训练31.一、混合云架构，带来便捷与挑战31.二、知乎的探索历程32三、持续合作，保持探索40B站|Alluxio在B站AI训练场景.一、B站AI的训练场景41.二、Alluxio在AI训练场景的应用45三、未来规划51辉羲智能|Alluxio在自动驾驶模型训练中的应用与部署52.一、自动驾驶数据闭环52三、算法训练引入Alluxio55四、Alluxio部署：单机房.五、Alluxio部署：跨机房57.六、Alluxio测试：功能58七、Alluxio测试：性能59八、Alluxio落地：调参适配环境60九、Alluxio落地：运维61.十、Alluxio落地：共同进步62.十一、小结63中汽创智|Alluxio在自动驾驶数据闭环中的应用65一、自动驾驶业务介绍65.二、数据平台架构以及存储选型67.三、自动驾驶数据平台使用场景70.四、未来规划78关于Alluxio在当今这个人工智能飞速发展的时代，诸多企业正站在一个充满挑战与机遇的路口。随着AI模型训练的热潮不断升温，企业在追求更高性能计算的同时，也不得不面对GPU资源紧张、模型部署缓慢以及存储成本失控等问题。这些问题不仅加剧了技术团队的工作压力，也对企业的业务发展和市场竞争力构成了严峻考验。本电子书将深入剖析Alluxio如何在AI/ML场景中发挥其分布式缓存的作用，助力企业突破IO瓶颈。Alluxio作为一个高效的数据访问层，优化了数据在存储与计算引擎间的流动，显著提升了数据访问速度和操作便捷性。文章详尽地列举了企业在探索AI过程中遇到的挑战，细致阐释了Alluxio在技术架构中的关键角色，以及其如何通过优化AI框架的IO性能，提升整体数据处理能力。同时，文中通过小红书、知乎、B站、辉羲智能以及中汽创智等知名企业的实战案例，生动展示了Alluxio如何助力企业在解决技术难题的同时，实现更快的模型开集的迅猛增长。本电子书将帮助用户迅速把握Alluxio如何助力企业应对AI模型训练的多重挑战，捕捉行业发展的脉搏，实现技术上的飞跃和业务上的持续增长。1.实战经验借鉴：通过小红书、B站、知乎、辉羲智能等企业案例，了解如何将Alluxio应用于实际场景，解决具体的业务挑战。2.多云架构优化：了解如何在多云环境中利用Alluxio实现数据的高效管理和访问，从而优化多云架构下的数据使用和存储成本。3.性能与成本的双重优化：掌握如何通过Alluxio提升数据处理性能，同时实现成本优化。4.前沿技术洞察：获得对未来技术发展趋势的洞察，为技术选型和业务布局提供参考。5.灵活性与扩展性实践：了解Alluxio如何支持不同技术栈和框架，增强现有系统台团队、云计算与存储团队、IT运维与系背景&Alluxio赋能AI场景其实从几年前就已经呈现了一些趋势，不管是在云上使用GPU还是自己购买GPU搭建IDC（数据仓库AI基础设施都比较困难，原因大概可以分为.部分公司或许可以在阿里云或者腾讯云上买到GPU，但如何把这些GPU形成一公司现有数仓/存储方案较陈旧，很难迭代，进行GPU训练后，如何把模型上线到推理的集群中，是必不可少的一个环节，也是困难重.很多数仓、底层的存储都还是公司里比较传统的存储方案，比如HDFS，可能十几年前就开始用了，现在很难调整存储的设置；后面也会深入聊一下，如何解决这个问题。现在很多公司模型训练过程GPU利用率普遍比较低，当然这个不是Alluxio一家就能解决的问题，普遍现象是：企业的数据大多在数仓中，这些数据如何引入GPU集群，存在非常多的挑战。后文也会分享在不同云厂商、国内外的大型企业中，Alluxio是如何解决这一问题前面所提到的更多都是业务的压力或者是商业上业务决策的压力，这些压力反映到基础上对工程人员来说就会变成技术压力，为了能够更快进行模型开发，Alluxio其实是有一些期望的：.更快的模型开发时间；.更频繁的模型数据更新；.适应快速增长的数据集。这些压力反映到技术侧大概可以概括为3点：比如以现在的应用，如何做这套系统，很多时候需要进行一些复杂的数据拷贝任务，从数据仓库往GPU的训练集群中进行数据拷贝，无论是拷贝到本地的NAS、为了满足AI场景的需求，对性能的要求会比较高，可以这么理解：20-30年前，GPU是和HPC（高性能计算）一起发展起来的，所以那时候大家普遍倾向于要有一套IB的网络，并且是有一套高性能存储（全闪）这么高的专用存储支持模型训练或者是模型分发的任务。以看到非常多的场景，比如3年增加5倍的云上成本都是很正常的。在进入详细技术讨论之前，再系统介绍一下Alluxio在AI/ML技术栈中的位置。首先，Alluxio不是一个持久化的存储层，持久化存储比较依赖云上S3Storage、Ceph或者是HDFS这种分布式存储，这些都是Alluxio下面的一个接口，和Alluxio不是同一个概念。再往上，Alluxio在AI领域是一个高性能的接入层，因为对于持久化存储层来讲，大部分公司追求的是价格和性能效率，而这个效率就意味着要有一个非常便宜的存储池，可以存储很多资源，并不期望有一套非常昂贵的高性能存储来做持久化存储，之所以会这样是因为很多互联网厂商或者是传统企业的数据量有几百个PB甚至是EB级别的，但同时需要训练的数据并没有那么多，可能就是几十个TB，甚至高一点的也就1PB左右，如果可以把这些数据放到一个高性能存储向上进行对接，对用户来说这个性价比是非常低的，所以Alluxio比较依赖这种持久化存储层进行行数据对接。再往上，Alluxio对Pytorch、TensorFlow的IO性能做了非常多优化，包括缓存策略、调度的优化/如何与它对接、Kubernetes的部署等。再往上就是Ray或者是MLFlow这种AI/ML的编排层。Alluxio是一个从大数据场景发展起来的公司，在这波AICG浪潮中逐渐被用户转移使用场景到支持AI/ML的workload，从使用Alluxio的客户/用户环境中总结的价.一般大数据和AI两个Team虽然在一个大的架构下，但其实技术栈是非常不同的，比如大数据技术栈会有Spark、Trino、Hive、HBase等，向下对接的是HDFS、云上的一些对象存储等，这些数据是一直在的，数据量可能有几百个Pytorch、TensorFlow，下面对接比较多的是对象存储，比如Ceph、MinIO.其实这两个系统的存在就产生了对接的问题，就是数据在数仓中，但是处理是到AIInfra里，这就变成一套非常复杂的系统了，而Alluxio可以帮助打通这套系统，不需要每次都进行非常复杂的数据迁移。个过程很多时候是非常复杂的，比如DataPipeline，之前遇到很多互联网公司都有一个临时的checkpointstore，然后还有一个持久化的checkpointstore，他们进行低性能和高性能的互相拉取是一个非常复杂的过程。对云上的存储，在跟诸多云厂商交流后了解到，他们很多情况下没办法直接在云上用对象存储支持AI的业务，原因在于限流的问题，拉取数据的速度很快，所以没办法处理。下面详细介绍Alluxio是如何做这套系统的，里面有很多场景的沉淀，此处分享一下Alluxio架构设计的初衷：首先在很多互联网厂商群体中，大部分的客户/用户，他们的数据大概率是在数据湖中（有90-95%他们的数据并不是以一个单独的数据集群来做这个事，而是有非常多的数据，包括传统的HiveMetastore、现在比较流行的数据湖里的数据，同时还有很多StreamingData的数据直接进来，也有很多非结构化的数据是放在数据湖里的。那么Alluxio是如何在其中发挥作用的呢？现在比较流行的就是用Spark或者Ray的架构，把这个数据预处理完，放回数据湖中，后面的TensorFlow、Pytorch会拉取这里的数据进行训练，比如看左边这个图，如果不用Alluxio拉取数据会产生什么问.首先要把处理好/未处理好的数据拉到Ceph的集群中，再向上serving这些拉取的data，在这里就会出现一些问题：首先这套拉取的流程会非常复杂，很多公司会自己开发一套数据管理系统完成，会有几套不同的流程在里边，比如用metastore对应这些表/数据在哪里；.其次需要增量的拉取数据；.最后需要对数据进行检验，查看是否有问题。这套流程下来从拉取到可用有很长的延迟，而Alluxio缓存的功能帮助大家解决这个问题。首先可以预先将部分数据加载到Alluxio中，放到更靠近计算的存储中，从而降低带宽消耗。同时，即使没有预加载数据，Alluxio的缓存机制也能帮助快速拉取数问数据的瞬间，数据就可以被迅速提供，不需要等节省了大量时间。其次，Alluxio还能减少用户自行开发而产生的数据治理问题。如果用户已经有一进行定制化开发。此外，Alluxio还着重关注：在训练集群上如何降低成本并提高效率。过去很多公司使用高性能的存储集群进行训练，但这种成本可能非常昂贵，限制了业务的扩仍然是一个挑战。Alluxio在这方面提供了很多结合点。可以将Alluxio集群直接部署到训练节点上，这样的消耗非常小（约30-40GB内存却能提供高性能的训练支持。用户只需要付出整个计算集群成本的3-5%，就可以充分利用GPU集群，帮助用户克除了训练集群，Alluxio也特别关注推理集群的成本和效率问题。随着推理集群的扩展，成本可能远高于训练集群。因此Alluxio致力于解决如何快速将训练产生的模型部署到线上集群的问题。在传统方式中，训练结果会写回到一个Ceph存储，然后线上集群可能位于同一个(storageGateway）来解决跨域或跨IDC的问题，但是网关解决的是一个跨域或者是跨IDC问题，实际上没有解决的是高性能和跨域的问题，简单理解就是可以把训练集群和线上的ML打通，但如果在AWS里这个Gateway是完全没有办法支撑推非常厉害，再比如：Alluxio可以在2-3分钟内把整个模型全都部署到推理集群上面，一般这种系统需要耗费的时间是它的10倍，而且它的P95接下来会详细讲解不同场景中，Alluxio是如何做的：第一个就是之前说到的问题，在GPU非常短缺的情况下，很多公司其实之前都不是多云战略，不是IDC融合或者是云上、本地都有的架构，但为了满足GPU资源的部本就不想用Azure、GoogleCloud等其他云，但今年，Azure把所有GPU都买Azure里，就必须得有个方法直接去访问AWS里的数据，这个问题就导致如果直接第二个问题是如果要建一个多集群数据管理是非常复杂的，包括要保证数据的一致Alluxio解决这些问题。其次就是不希望大家专门买一套硬件解决方案，之前接触过的实验室有在做HPC的，HPC有一个很大的问题就是成本非常高，买1套HPC通常可以买10套Hadoop硬件，或者是云上的存储硬件，所以如果需要购买一套专有的硬件搭建AIInfra架构，是事倍功半的，成本非常昂贵，看到这个场景后，Alluxio提出还是希望可以直接在数据湖上构建AI和ML的数据通路，可以不更改存储系统，同时可以利用已有的，不需要额外购买IDMA这种硬件，就可以支撑训练的需求。同时不用考虑和原数仓中任务进行数据隔离的问题（所谓隔离就是需要进行数据迁移，然后运行成两套非常独立的系统，这对数据的拉取、获取是非常有问上图就是前面提到的，Alluxio提供的一些功能，比如自动数据湖加载/卸载、更新数据功能，从而提高数据工程团队的生产力，一个比较常见的场景就是：如果基于原有的系统搭建，加一个Ceph，基本时间线会拉长到3-6个月以上是非常常见的，但是用了Alluxio整套系统拉取后，基本就可以在1-2个月内把整个DataPipeline建起来，如果大家感兴趣可以去详细了解一下知乎的应上图是前面提到的另一个问题：模型部署受限于底层的存储，包括带宽的问题，还受限于IDC不同位置的问题，Alluxio可以做一个多云多架构，不管是从公有云到私提供一个高并发的缓存系统，支持业务高并发拉取。稍微总结一下，Alluxio在AI架构中处于怎样的位置？Alluxio帮助大家解决什么问.第一个就是降低改造和适配的成本，帮助大家更聚焦在模型上线的逻辑上；.第二个就是消除了专用存储架构，比如原来必须要用NAS、NFS这些系统来做的，用了Alluxio之后就不再需用，Alluxio和下面原来已有的HDFS，对象存储配合就可以搭建AI平台；.第三个就是需要添加缓存，就可以把GPU利用率提高到较高的水平；.第四个就是满足公司自由部署GPU的需求，不管是云上还是云下买的GPU，不论数据在哪，都可以实现很高效的数据适配，后面会提供一个具体案例。关于Alluxio在AI场景是如何助力企业解决问题的，详细分享几个备受关注的案小红书|加速云端机器学习-Alluxio在小红书的实践首看看小红书的业务都碰到了哪些挑战。小红书作为云上的原住民，从成立之初就构建在公有云上，下图是小红书多云架构的示意图：图中的三个圈代表两个云厂商的不同Zone（区域云厂商1是在ZoneA与ZoneB，云厂商2是在ZoneC。核心业务分别分布在多个云厂心业务如搜广推、社区通常在主要机房都会存在，是多活架构；主要业务如电商直简化后的示意图，真实情况远比这复杂。多云架构对小红书带来了非常明显的成本优势和可用性优势，但业务的通信链路也随之复杂，各种跨专线调用；还有个特点用上的痛点。多云架构下有哪些典型的问题1.机器学习训练在小红书是资源大户，属于公司Top级别，但海量的CPU和2.推荐服务是小红书最核心的服务之一。它的核心逻辑是推荐召回需要有索引分发的过程，比如刷小红书刷到的个性化的笔记列表，就主要用到了索引。索引服务因为索引分发慢，从而导致稳定性比较差，且因为索引数据存储在云盘决方案。而且随着AI的飞速发展，AI模型从之前的百GB级发展到如今的TB级别。原来的架构通常先把模型拉到本地盘，再从本地盘加载到内存，才可以进行在线推理。这个过程在模型增大到TB级之后，会有两个严重的问题：一个是加载过程非常缓慢，另一个是模型存储在本地盘的成本非常高昂。4.多云架构本身带来的网络链路复杂，跨专线传输数据量非常大，专线单价也是非常高昂，有成本和稳定性的双重挑战。接下来介绍下小红书是如何通过构建多云统一数据加速层来解决这些痛点的。上图是小红书业务架构的示意图。最上层是业务层，主要包括社区、搜广推、直器学习平台、AI训练平台，模型发布平台、推荐索引平台、数据平台等。最底层产品都可以适用于这个通用的解决方案。在平台层和存储层之间，基于Alluxio构建了一层多云统一数据加速层并研发了对应的智能缓存服务。为什么选择Alluxio作为多云统一的加速层首先基于面临的问题，抽象出了选型的重点目标：.需要能够复用业务历史上已经存储的数据，不需要再次搬迁或者导入到其他高速存储或文件系统就能享受到数据的加速。以典型的搜广推和训练业务为例，这些业务的存储量大概是数百PB级别，搬迁一遍才能使用不太可行。.需要支持S3和POSIX协议，以便常是S3协议，AI训练通常是POSIX协议，如果加速层能够兼容这类协议，业务方就不需要改代码，迁移成本也会低很多。.需要实现跨云专线传输的带宽控制和节省。因为跨云本身业务是多活、多云的。但多云之间本身就有实时的数据同步，如果把带宽打爆，那稳定性问题就会立马出来，所以一定要能够控制住带宽。.能够支撑百亿级别的AI训练，小红书有单个训练任务就有60亿+元信息的场景需要支持。.能够支持常见的云存储产品，以主流云厂商的对象存储为主。经过调研发现，业界目前唯一能同时满足上述诉求的产品，就是Alluxio。Alluxio主要特性.特性一：格式透明，不侵入业务数据存储格式。数据湖里的数据量非常大，是不可能再导入进来重复存储的，有了Alluxio，只需要在原来存储上加一层Alluxio，就可以直接去访问那些数据了，让业务直接享受到加速收益，这是非常关键的特性。API\RESTAPI等协议，帮助Alluxio上层AI/ML训练引擎（如Pytorch、Ray、TensorFlow）和查询引擎（如Presto、Spark、Trino）与底层存储进行无缝对接。.特性三：多云统一视图。不管底层存储是HDFS、Ceph还是各云厂商的对象存储，对于用户，只要通过Alluxio，任何API都可以去访问不同存储位置的数据，从而可以实现多云统一视图的效果。.特性四：数据仅需通过专线传输一次，后续可通过缓存就近读取，不需要再次跨专线，这个关键特性对小红书专线的保护意义重大。通过合理地利用这些特性，就能够解决上述提到的小红书多云架构的业务痛点。机器学习训练最初的架构是直接从对象存储拉取数据（主要是训练样本拉取完这些训练样本就开始在TensorFlow框架做训练。.训练速度不太符合预期，导致一些任务训练很慢，以及其他人排队调度不上，体验很差。.海量的集群资源利用率太低对成本也带来了很大挑战。主要原因是一些热点的数据集（如小红书的笔记样本是公共的样本，总量非常大（大概每天几百TB）。这些公共数据集会被很多任务使用，在小红书的场景下大概是20倍的扇出，如果是几百TB的数据会有20倍的扇出，这个总传输数据量是非常大的，整体流量达到了Tbps级，触达到了对象存储桶的带宽瓶颈。如果数据集大、扇出也大的话，一定会有额外的带宽需要，云厂商的解决方案通常是要么增加存储量，要么对增加带宽进行额外收费，两种方式都不太友好。.因为业务会直连对象存储，而对象存储本身是高吞吐的产品，并不会过分强调单线程有多快，这就需要业务不断的去调优，才能达到适合的吞吐。基于以上三个问题，机器学习训练架构经过了升级改造，最新架构如下图所示。新架构对于普通数据还是直接会去对象存储读取，对于笔记这种热点的训练数据集，会把它缓存到Alluxio，当业务来Alluxio访问的时候，如果第一次数据不存在，就会去对象存储透传，然后把数据返回给训练框架，如果数据已经在Alluxio虽然第一遍读完数据，Alluxio一定会去缓存数据，但这还很难解决业务的问题。第一种情况是Alluxio缓存是用到本地磁盘把数据缓存下来，但磁盘容量是有限第一个任务缓存了，第二个任务就没有空间缓存了，或是会把别的缓存数据给挤掉。第二种情况是有些训练任务可能因为计算资源或者故障的原因带来严重的延迟，之后这个业务一旦跑上来，可能需要训练30天之前的数据，或者直接回溯很老的数据去训练，那这30天的数据很容易就把所有的缓存空间全部用掉。以上两种场景通过研发了智能缓存管理服务来解决。智能缓存管理服务主要是基于任务的历史运行规律，可以基于任务的历史运行规如发现最近1-2天的笔记训练样本是非常重要的，就会把这些数据用Pin机制固定在磁盘里，就不会被自动淘汰，从而实现重要数据的淘汰完全由智能缓存管理服务去控制。通过这两个措施的共同保障，缓存命中率能跑到90%以上，很好节省了对象存储的带宽。同时，Alluxio也提供了load任务的管理和执行能力，但目前还不完全符合小红书的需求。具体的业务中需要监控到任务粒度的load进展，比如有10个任务（有几个是重要的在按小时提前预加载数据，结果集群故障了，但故障时间也较措施是通过实现load进度的可观测机制，能够观察到每个任务当前正在加载第几基于任务的优先级去判断优先补偿哪些任务，并提供一键补偿的能力，看看这些任务已经错过了哪些小时的缓存数据，然后全部加载进来，从而规避带宽全部透传到对象存储所造成的的稳定性风险。第三是为稳定性实现了一个探针服务，它可以完全模拟业务的读写行为，是一个端到端的探活服务。探活实践下来非常好用，无论是代码本身有问题，还是机器磁盘、网络等出现问题，都能反映在探针里，方便快速介入。目前能达到3分钟发现和1分钟止损的效率。经过将近一年时间的运行，故障告警的准确率几乎达到了100%。上图展示的是一个非常典型的笔记训练大任务，其他业务训练效果都差不多。在迁而平均CPU利用率只有30%，只是到了最后面会有一些上升，这是因为这时候大部分任务已经训练完成，对象存储的带宽有些缓解了。在迁移到Alluxio之后，训然很多业务比这个效果更好，但这个例子是一个非常典型的大任务，更具有代表性。索引对于推荐非常核心，稳定性是非常重要的问题。上图是未引入Alluxio之前的架构图。最上面是搜推平台，会对搜推的索引做一些生成或者更新，更新完了之后会存储到索引存储（一般是就近机房的对象存储）。存储索引之后，搜推平台会通知其他服务下发索引，下发索引的服务会把数据通过专线从原来索引存储的对象存储桶传输到另外一个多云机房的本地磁盘，也就是索引服务的本地磁盘上。以图中的架构为例，共有两个跨区域的机房，当把索引数据下载到本地盘后索引服务就能够把数据加载到内存中，对外提供一些索引的服务。这样的架构带来的问题很大：.以推荐场景下的索引读取速度来说，通常发布一个机房的服务需要3-4个小时，因为是多活设计，发布完四个机房整整需要一整天，这是非常令人头疼的很老的一个索引回滚，就需要重新走这个流程，.磁盘存储成本非常高。因为索引服务本身是一个主从架构，典型的场景是一主两从。同一个索引会有三副本的云盘存储，而云盘本身就是三副本冗余存储，那整体下来就是九副本，而云盘的单价通常比对象存储贵得多，这样计算下来整体成本是非常高的。下图是引入Alluxio之后的架构。从搜推平台生成索引之后，会把这个事件发送到会去加载索引。现在的加载流程和之前就不一样了，之前是通过专线传输过来存到本地磁盘，现在是加载到Alluxio集群里，然后再告知索引服务，去Alluxio集群把数据再加载到索引服务的内存，从而对外进行服务。这里的关键点是把本地磁盘变成了Alluxio集群，那为什么采用Alluxio之后解决了以上问题呢？首先，把磁盘上浮到了一个远程的集群，实现了索引的的存储瓶颈，转换成了宿主机的网络瓶颈。云盘的带宽通常在云厂商相对还比较好的规格是350MB/s，但是宿主机不一样，推荐可用的一些机以上，合4GB/s，这两者的差距超过10倍，因此下载索引数据这个过程就能提速10倍以上。第二，Alluxio并不会把文件存储在固定的一台机器上（和本地盘不一样一个文件会被切成block存储。比如一个集群有100台机器，一个文件能切100个block，那每个机器只会存1个block，这时候整个集群的带宽就是这个文件的吞吐极限。所以，对于一些热点的索引文件或者其他场景都是非常友好的。但这样直接用Alluxio还是会遇到问题，所以还加入了一些增强的功能，这也是为Alluxio支持限速，以保障核心服务的稳定性。现在已经支持了限速，当限制20-30Gbps的带宽从UFS下载数据，就不会把专线带宽占满。这套架构主要有三点收益：1.Alluxio将云盘带宽瓶颈变成了宿主机的网卡瓶颈，索引拉取速度带来10倍以上的提升。如果宿主机的核数越大，附带的带宽也会更大，带来的提升倍数还会增大。2.索引下发的整体业务体感（含业务逻辑）达到3倍的提升。主要是因为除了下载，还有一些业务逻辑在这个索引下发的过程里。3.高性能云盘替换成对象存储，节省80%成本。此优化是通过Alluxio把云盘全部省掉，变成了Alluxio的集群本地盘，而这些本地盘可以选择一些更廉价的介质，比如单副本的HDD盘。对于小红书的推荐场景，由于索引数据量很大，云盘成本的节省量也是非常可观的。小红书也有大模型的场景，大模型下载的解决方案和推荐索引几乎一模一样，面临的同样是云盘带宽限制和冗余存储高成本以及跨云同步稳定性问题。3-4年前大家通常只做单机训练，现在已经演进到了几乎都是分布式训练的状态。那一定会需要通过远端的存储集群来解决本地数据存放不下的问题，这块架构与收益跟推荐索引·有60亿+级别的小文件训练场景，如果把这些元信息存储在一个集中式的元信.对象存储作为很多存储的底座，最终数据会穿透到对象存储，会面临着存储带宽，或是IOPS比较有限的情况（尤其是小文件云厂商通常一个桶提供几万IOPS，每PB存储量的带宽配额也很低，尤其在小文件场景下，这点IOPS解决方法：引入Alluxio缓存训练需要的数据。Alluxio3.0版本提供了一个可扩展的元信息嵌入，让业务方看其实还是访问的本地盘，背后其实是AlluxiAlluxio集群去对象存储里取数据，基于Alluxio的缓存机制，可以有效的避免数据穿透到对象存储。因为通常AI训练是多轮的epoch，Alluxio只会让第一轮epoch走对象存储，后面都可以命中这些缓存。甚至理想情况下，可以错峰把这些数据预加载到Alluxio，这样真正训练的时候，完全不需要走对象存储。因为GPU机器上很多磁盘是闲置的，为了避免额外的支出成本，会把Alluxio和Alluxio相对于别的产品打造的非常成熟的能力是ClusterCache。在同样的总磁盘容量，ClusterCache相对于LocalCache的命中率可以做到更高，比如有两个训练任务读同样的文件，如果落在两个不同的机器上，对于LocalCache会把数据读两遍，而对于ClusterCache只需要读一遍，第二次可以通过网络来传输，而LocalCache，组合起来使用更佳。.可以在业务训练之前提前把数据加载到缓存中，突破IO限制，相比穿透对象存储读取性能更高；.读取数据时通过智能判定是随机读还是顺序读。如果是顺序读可以提前预读数据，从而达到更高的读吞吐；如果是随机读，可以精准地控制要读哪个位置，避免读的放大；.无集中式的元信息服务，全量元信息在对象存储，只有热数据及其元数据在缓.可异步写checkpoint到本地磁盘，再异步上传至对象存储，通过有效缩短IO在与Alluxio的合作过程中，小红书也一起参与解决了非常多的技术问题，这里有几个比较典型的场景：读放大问题解决：主要表现在S3协议里会有一些range读，以及Alluxioclient、fuse或者其他一些触发随机读的场景。放大主要存在两个环节：一个是S3proxy到worker之间；另一个是worker去对象存储（UFS）取数据的时候，都会有一个读放大的情况。比如一个数据是热读（指数据缓存已经在worker里原来的实现里proxy会直接去worker取，虽然S3协议里的range参数已经指明了截止位，但并没有透传过去。因为这里可能认为需要做一些预加载来加速后续的读取，实际上业务如果指定了一个endOffset，后面的数据则是没必要读取的。虽然预读能帮助吞吐的解决办法：worker传输数据当传输到endOffset，后面的字节不需要传输过来，第二个放大的问题是因为Alluxio初衷在读数据时，会把需读取数据范围涉及的block全部缓存下来，好处是之后再读这些数据就不需要走带宽了。比如在一个随机读的场景，在一个block里只需要1-2M数据，但Alluxio会缓存整个block的中本身传了endOffset，需要将其作为访问对象存储的参数，只需要读取必要的数据即可。endOffset之后的数据本身也会被丢弃掉，读出来就会变成worker机器上网络带宽的开销，从而影响成本和效果。第三个是冷读NoCache的场景。NoCache是指经过Alluxio读取但不缓存对应的数据，通常发生在对于延迟太久的任务或者读取大量冷数据的任务，不需要将其缓存下来，否则会将本身的热数据给挤掉。——解决办法：以前的实现里，通过S3proxy直接NoCache读，它会通过worker去UFS取数据。修改和打磨之后，Proxy会绕过worker直接去UFS取数据。这样可以节省worker传输到proxy的带宽，可以省一倍的带宽，对应到机器成本上就是省一倍的机器成本。在UFS这一层增加了流控能力，保护了专线带宽。在多云环境，业务通常会就近读取，一定不会跨专线访问Alluxio集群，所有跨云专线的流量只有从worker到UFS这一层，所以只需要在访问UFS的地方加限流就可以控制住专线。而客户端论上也需要保护，但不影响专线。在读性能优化方面，通常是识别了读的特征之后做预读，通过预读能够明显提升读的性能，尤其是在冷读数据的情况下。在Checkpoint写方面，一定不能阻塞训练，所以支持了WriteBack能力，WriteBack是指先异步写到磁盘甚至内存中，然后就可以开始后续训练，通过后台线程异步上传。同样也有一些线程模型的优化，整体对读写的性能也有非常大的提升。未来小红书会把数据加速层做成什么样子以及还有哪些待解决的问题呢？因为小红书的数据存储在多云里，业务需要关心数据到底在哪个云上，是不是会跨东西非常多。期望打造一个统一的多云数据存储产品，让业务方再也不需要在代码中关注数据到底在哪里，专线能否控制好等问题。在AI训练场景，因为GPU众所周知的供应问题，从各个厂商购买或租赁的GPU是分散在非常多的地域。这会造成一个非常严重的问题，有些地方有GPU，但没如何基于Alluxio来提升GPU利用率，解决数据和GPU在不同地域如何充分利用大数据查询加速在Alluxio社区里的案例非常多，但小红书需要探索出一个如何在极低成本的情况下去实现大数据查询的加速。同样的查询效率提升，需要增加的Alluxio的成本要小于直接扩容查询引擎节点的成本才行。现在Alluxio集群规模比较大，与此同时，CPU利用率是非常低的，每天平均大概3%的利用率，但磁盘容量和带宽全是占满的。如何将这些CPU去充分使用是一个非常大的问题，而公司出于成本考虑，也会从而发挥更多价值。知乎|AlluxioAI助力知乎千卡模型训练知乎目前是典型的混合云架构，数据和服务都分布在不同的机房：.离线机房：专为满足大数据相关业务方需求而设计的离线计算服务中心。其主要职能是部署离线调度、离线存储以及调度平台等服务。这些服务的目标是提供高效的离线数据处理和计算能力。在离线机房中，大数据业务方可以安心进行批量数据处理和计算任务，从而满足他们对数据处理、存储和调度的要求。.在线机房：此机房专为知乎主站提供直接面向用户的服务而设计。其中包括评以确保用户能够在最短的时间内获得稳定、高效的服务体验。知乎主站作为一个知识社区，其在线机房是为了保障用户对知识和信息的交流与分享能够得到.GPU机房：此机房专门用于部署机器学习平台，主要服务于算法用户。其主要特点是提供强大的GPU资源管理、模型训练、数据集导入导出等一站式解决方案。GPU机房的核心任务是为算法用户提供高性能计算资源，以满足机器学习模型训练和推理的要求。这样的设计能够使算法用户更专注于模型的研发架构图如下所示：混合云架构给知乎带来了成本，容灾等各方面的优势，但是也对存储提出了新的挑战。相比于数据都存在在单一机房，在混合云的架构下，时，还需要额外考虑访问存储时，专线带来的网络延迟以及网为了解决模型训练及模型分发场景跨云读取数据的痛点，知乎在早期自研了一个缓UnionStore的缓存工作流程可描述如下：.用户在向UnionStore请求读取文件时，会先检查对象存储上是否已经有该文.如果对象存储已经存在该文件，则直接从对象存储读取文件返回给用户；.如果对象存储不存在该文件，UnionStore会先将离线HDFS上的文件上传到在线机房的对象存储上，再从对象存储上读取文件，返回给用户，缓存期间用户的请求是被卡住的。这里相当于是利用对象存储做了一层跨机房缓存。UnionStore在知乎运行了两年，期间没有出现任何问题，但是随着2023年知乎访问和首字节延迟在几十毫秒，而大语言模型在进行训练，读取语料时，往往都是随机读取，对吞吐要求低，但是对时延敏感，而UnionStore只能从对象2.训练任务在启动时需要读取模型的checkpoint，大语言模型的checkpoint动UnionStore也做了一些加速手段，但是也只能加速到200-300MB/sec的速度，远远不能满足大模型的checkpoint读取需求；3.对象存储能力有上限，在模型分发时，往往单文件会有上百，甚至上千并发同4.无法做到边缓存边返回文件，导致首次读取文件的时间偏长，这也会影响大模型checkpoint的读取速度。以上痛点使得知乎面临两个选择：一是继续迭代UnionStore，让UnionStore具备高性能缓存能力，比如支持本地SSD以及内存缓存；二是寻找合适的开源解决使用的是UnionStore的对象存储协议，模型训练场景使用的是UnionStore.性能优秀：选择替换UnionStore的最重要的原因就是对象存储的性能和延迟远远不能满足算法业务的需求，所以知乎需要的AI存储必须要有足够优秀的.透明缓存：因为目前知乎的数据都是存放在HDFS上，不希望用户在接入新存储的时候，需要对访问数据的路径做比较大的修改，最好是路径能够与HDFS一一对应，有透明缓存的能力，这样能够最大程度上减少业务方的改造工作。基于以上需求，调研了市面上大多数的存储，发现只有Alluxio能够满足需求，严格意义上来说，Alluxio并不是一个标准的存储，它是一个多功能低侵入的高性能.透明缓存：相较于其他文件系统，Alluxio可仅作为缓存使用，用于编排数据，业务方无需将模型文件写入到其他的文件系统，只需要维持现状，写入.元数据与数据缓存：Alluxio支持自定义缓存元数据与数据，这样在读取已缓存文件时，可完全不受HDFS影响；目前知乎UnionStore的QPS大约在对数据湖场景也可以提供强有力的支撑；.即席查询加速：知乎Adhoc引擎采用的是Spark与Presto，Alluxio对这两个引擎都有较好的支持；.访问接口丰富：Alluxio提供的S3Proxy组件完全兼容S3协议，模型上线场景从UnionStore迁移至Alluxio付出的成本几乎可忽略不计；另外Alluxio提供的AlluxioFuse也具备本地元数据缓存与数据缓存，比业务之前使用的S3FS-FUSE具有更好的性能，正好能满足模型训练场景。此外知乎对Alluxio进行了一些性能上的测试，AlluxioFuse的单线程顺序读取速度能够达到500+MB/sec，AlluxioS3Proxy的单线程顺序读取性能能够达到1GB/sec以上，这个性能完全能够满足需求场景。上线的过程比较顺利，几乎是无感迁移，在短短三个月内就将UnionStore完全替换成了Alluxio，并且拿到了不错的收益：模型分发的速度得到了2-3倍的提升；训练任务等待数据的延迟几乎消失，训练时长降低至原来的40%。随着训练任务的规模不断扩大，也发现了Alluxio社区版中存在的各种问题。总结起来可以描述如下：.Fuse稳定性问题：社区版AlluxioFuse会经常出现OOM相关的故障，经常导致训练任务失败重启；.Master元数据性能瓶颈：社区版的AlluxioMaster是一个单点的服务，在缓.高昂的运维成本：社区版的Alluxio部署，需要自己打镜像，以及写k8s的yaml文件进行部署，没有operator相关的运维工具。以上问题在社区版需要投入极大的人力和精力来修复和维护，并且需要一个比较长的周期，而此时知乎的算法业务发展的势头很猛，根本等不及。正好听说Alluxio也在企业版重构了他们的架构，在提升性能的同时，也修复了很多社区版已存在的问题。于是正式开启的Alluxio企业版的调研与试用。.探索：Alluxio企业版攻克四大问题1.AlluxioFuse稳定性问题这是知乎真实生产环境中AlluxioFuse的重启监控，可以看到Fuse的重启十分频繁，几乎每隔几小时就有一次。一旦Fuse重启，训练任务就会因读取数据错误而失败，需要从上一次checkpoint开始训练，这就导致了无效训练，会浪费相当可以看到企业版的AlluxioFuse几乎没有出现重启的现象。机器故障率比较高，也造成了AlluxioWorker的故障率偏高。在这种情况下，企业版支持在某台AlluxioWorker出现问题时，重试到其他的Worker读取数据，或者是直接从UFS读取数据，这也提高了Alluxio企业版自上线以来，一共完成了300+训练任务，包括知乎最重要的千卡大模型训练任务，训练期间没有因为Fuse的稳定性导致训练任务重启，相比于社区版，企业版极大减少了无效训练的出现。AlluxioMaster是Alluxio社区版中一个比较明显的瓶颈：能问题，Master在3亿元数据下可以相对稳定运行，但是超过3亿就需在metadatasync比较频繁的时候，较小的元数据量也会出现比较严重的锁竞争Alluxio的企业版对整个Alluxio集群架构进行了重构，不再使用Master管理元管理的元数据越多，元数据的规模随着Worker的增长可以达由于元数据分散到不同的Worker，元数据请求的QPS也能随着Worker数量的增加，得到线性增长。这里需要注意的是，Alluxio企业版引入了一个轻量的服务写场景的需求主要体现在模型训练时做checkpoint。在训练过程中，往往会因为一些意外导致训练任务失败，比如机器故障，GPU卡之间的通信故障等。而大型训练任务往往都是持续好几个月的，在训练过程中出问题的概率接近100%，为了避免在训练任务失败时从零开始训练，训练任务就需要checkpoint恢复，而不必从头开始整个训练。做checkpoint越频繁，每次训练任务重启时，损失的训练时长就越短。但是对于一个大型训练而言，checkpoint的大小往往在数百GB，保存并持久化巨大的checkpoint文件也会花费比较长的状态。也就是说，如果想用Alluxio保存checkpoint，Alluxio必须要有一个比较在Alluxio社区版时，采用的是同步写模式写入数据，直接穿透写到UFS上，只每隔3小时做200GB的checkpoint，每天光是花费在做checkpoint上的时间就达到了120+分钟，占到全天时长的8%，8%，很明显这个速度是不能满足需求的。Alluxio企业版支持了更高的写入性能，在测试中，单线程同步写入HDFS能达到1.2-1.4GB/sec的速度，如果还是按照每隔3小时做200GB的checkpoint来算，每天花费的时间将减少至20分钟，只占到全天时长的1.4%，这能够大大减少模型训练做checkpoint的时长，提高GPU利用率。目前Alluxio写入的上线正在内部测试，还没有正式上线。除了同步写入，后续知乎还计划上线企业版的异在社区版时，需要自己打包Alluxio的镜像，并且自己写yaml文件将Alluxio部出错，下图是部署社区版所使用的脚本和配置文件的集合，可以看到一共有十几个文件。Alluxio企业版不仅提供了现成的k8s镜像，还提供了operator部署工具，可以一键启动集群，在operator安装好的情况下，部署一个Alluxio集群只需要一个配置文件，极大节省了我们的运维成本。首先，Alluxio社区版为知乎带来了混合云下AI存储的通用解决方案间内从自研组件无缝切换到Alluxio高性能缓存上，支持实现跨云训练；其次，在更加核心的场景下，Alluxio企业版带来了更高的稳定性，更好的性能，更便捷的运维，更是支持了知乎内部千卡大模型的训练稳定高效运行。感谢Alluxio团队在上线过程中提供的帮助，后续也将继续保持合作，共同深入挖掘Alluxio的潜力，探索更多的应用场景，为知乎的技术发展B站|Alluxio在B站AI训练场景的应用它具备了一个常规机器学习平台的能力，比如交互式建模、数据集管理、模型训练、模型部署等基础能力，用户也会有一些精确的数据集、业务团队以及资源运营相关的能力，同时对机器学习框架（比如业界流行的TensorFlow、PyTorch、DeepSeed以及自研的一些框架等）都需要兼容。同时，为了加速整个训练的收器主要是Volcano，是现在机器学习平台常用的。下图是搭建Alluxio之前的存储方案，HDFS主要针对大数据的分析场景，B站自的优缺点，这里也简单的做了个对比。这个场景也是目前使用Alluxio的一个主要业务场景，这里有一个特点，单数据集级别，基本都是小文件。CV训练以图片、音频等为主，基本都是100KB、1M大在训练过程中发现了几个存储方面的痛点：.因为现在随着大模型的引入，数据量会越来越大，对数据容量的要求会越来越.这是一个快速增长的过程，而且特别是最近的Sora带火了TTV这种场景，所以视频的规模会非常大，存储系统需要具备高扩展性以应对不断增加的数据需求。2.性能瓶颈：.高吞吐：AI训练需要频繁读取和写入数据，存储系统需要支持高吞吐量以保证数据加载速度.低延迟：数据读取的延迟应尽可能低，否则会影响训练效率，导致GPU/NPU等计算资源的浪费。.高成本：存储大量数据尤其是高分辨率图像和视频数据，存储成本很高，需要平衡性能和成.访问控制：需要对数据访问进行细粒度的权限管理，确保数据安全。这里先介绍一下Alluxio的主要优势：.性能高：低延迟高吞吐的数据缓存能力，对于AI训练尤其重要；.兼容性强：支持S3/HDFS后端，提供了广泛的数据源兼容性；兼容POSIX协.运维成本低：运维成本在大规模数据存储和处理环境中尤为重要，有助于减少整体运维投入；.大规模数据处理：Alluxio支持亿级的数据量规模，能满足AI训练需求。在做技术选型的时候，也对业界常用的几个系统做了调研和分析，基于B站的体投入更低的成本、更低的运维，支持更强的性能。在调研过程中Alluxio各方面表现优势明显，最终选择了Alluxio。据集场景是一种单集群部署的模式，优势是：一个集群可以集中管理、运维成本比较低，可以实现资源的高效利用；缺点是现在社区版2.9.4的元数据存储在Master,很容易碰到天花板，扩展性比较有限，如果单个集群出现了问题，对业务的影响是比较大的，所以在AI场景最终采用的是多集群部署的方案。基于整个集群的存储规模，集群的划分会按照业务或者是数据集，好处是某个业务或者数据集需要更强的能力，则会投入更多的资源，而对于那些不怎么重要的业务，或者是低优先级的业务，则需要把它隔响到高优先级的业务，这是最终采用的方式。通过多集群的方式，在部署运维方面会增加更多的成本，那么如何解决这个问题？这里引入了Fluid。Alluxio是对底层存储的抽象，Fluid又是对Alluxio这一层Runtime的抽象。通过Fluid之后，可以更好的在K8s上，更自动化的部署多集另一个问题是，在实际应用中使用的是volcano调度器，主要是binpack为主，binpack的策略是尽可能的把单台机器塞满，对IO密集型的业务，如果把所有的节点都调度到单台机器上，很容易造成单点故障，给IO造成瓶颈，另外也会带来网络拥塞、资源利用不均等问题。解决办法：结合了业务特点以及本身的缓存加速场景，采用的是拓扑感知的调度策略。首先，会尽可能的让Alluxio的节点分散到集群的每台机器上，尽可能的把IO打散。其次，在任务调度的时候，也会去感知Alluxio的拓扑分布，尽可能做到任务与Alluxio节点的亲和，这样亲和之后相当于在读本地硬盘。元数据同步的必要性:元数据同步在Alluxio中至关重要，因为它确保Alluxio文件系统与底层存储系统中的数据保持一致，这个问题B站也同样遇到过。当数据量大了之后，如果按照官方的元数据同步方法，对整个集群的稳定性和性能都会有很大的影响，所以最终采取了一种按需同步的方法。这里已经把集群暴露给用户，他可以直接操作他的集小化他的同步单元，尽可能的减少无效的同步计算。具体同步方式:.基于时间的自动同步：设置erval属性来定时同步；.手动同步：使用loadMetadata命令或API手动触发同步。很多场景的数据都是以小数据为主，如果只是简单的把数据给到Alluxio，然后什么都不做，这样就会有两个问题，一个是Meta会很多，本身B站采用的就是Master的架构，整个集群对Master的压力会很大；另一个就是用户会无组织的去用，因为他根本就不知道该做哪些组织才有利于数据的IO。这块主要是做了数据合并，也是在训练场景用的比较多的一种方式，把一个图片做成一个chunk，练的效果都不会有太大的影响。在实际应用过程中测下来，亿级别的单节点性能基本能达到IOPS在3000+以百T规模左右。Alluxio之前介绍过知乎的推理场景，这个场景B站也有比较大的痛点，所以B站也在尝试探索更多的可能。另外就是现在Master元数据管理是一个很痛的点，在这种场景下Alluxio最新的Dora框架可以带来多大的收益，也是需要进一步去调研专业团队做一个更大规模、更通用的Alluxio解决方案，这是现在在做的，也是后续打算去推的。中的应用与部署首先分享一下自动驾驶中怎么样构建数据闭环，这个业务过程可能大家都有所了采集就是在跑的过程中采自动驾驶车上的各种数据：比如说camera的数据就是图片，激光雷达的数据是点云。传感器数据采回来，可能一辆车每天跑下来就有几T的数据。这种数据通过基盘的方式或者其他上传方式把它们整体存储起来，传到对象存储里面。原始数据存储之后会有一个pipeline做数据的解析预处理，比如把它切成一帧一帧的数据帧，每帧的不同传感器数据之间可能还要做同步对齐的操作。完成数据解析之后，就要在上面做更多的挖掘。构建一个一个的数据集。因为不管一个路口，或者一些密集形成区域的数据，那就会在整个系统里面有大量的这种数这个位置的经纬度，解析周围的POI。之后再对挖掘出来的数据做标注。常见的验证完再把它部署到车上面，再去跑数据，在这个基础上再去采更多的数据。就是这样的一个循环，不断的去丰富数据，不断的去构建性能更好的模型。练，数据闭环要做的事情，也是现在自动驾驶研发里面较核心的事情。聚焦到模型训练来讲：模型训练主要是通过数据挖掘拿到数据，从而生成一个数据集。数据集在内部是一个pkl文件，包含数据、channel、存储位置，最后数据算法训练的同学会自己写下载脚本，把数据从对象存储拉到本地。在选用Alluxio之前，是通过NAS系统充当缓存的作用，把对象存储的数据拉到NAS上面，最后再用不同的模型，把数据load进来进行训练。这是使用Alluxio1.第一是并发性能比较差——NAS可以理解成任务一起跑的时候，还是比较够用的。但是当有几十个训练任务同时进行、很多模型在训练的时候，往往就会出现卡死。曾经有一段时间卡死非常严重，研发每天都叫苦不迭。卡得严重以至于可用性非常差、并发性能很差。2.第二是管理困难——每一个人都用自己下载的脚本，然后把想要的数据下载到自己的目录下面。另一个人可能又自己去下另外一堆数据，放到NAS的另外一个目录下面，这样就会造成NAS空间满时很难做清理。当时基本都是当面或者微信群沟通。一方面是效率特别低，依靠群消息管理会滞后。另外一方面，的数据集给删掉的情况。这也会造成线上任务区域的报错，这是另外一个痛点。3.第三是空间浪费——不同人下载的数据放在不同目录下，有可能同样一帧数据会出现在好几个数据集，存在比较严重的空间浪费。4.第四是使用很复杂——因为pkl里面的文件格式不相同，使得下载逻辑也不一样，每个人都要单独去写下载程序。这是之前用NAS会面临的一些困难和问题，为了解决这些问题而做了一些调研。调研后聚焦到Alluxio上来。发现Alluxio它可以提供一个比较统一的缓存，缓存可以提升训练速度，同时也可以减少管理成本。还会用Alluxio的系统，处理双机房的问题。通过统一的命名空间和访问方式，一方面可以简化代码实现上也会变得很简单。Alluixo会配置缓存的逐出策略。一般是通过LRU，当到一个threshold的时候.效率大大得提升；.解决了重复数据的问题。去访问这个路径时，就可以拿到对应的数据，这样就不会存在重复数据的问题。另以上是从逻辑层面解决了刚才讲的各种各样问题。下面讲一讲，整个落地的历程，么样部署、运维等的一些实践经验。用之前GPU上很少用的SSD，把每个节点都利用起来，然后把FUSE和worker部署在一起。FUSE就相当于客户端，worker就相当于一个具有内网通信的缓存小集群，做FUSE的服务。最后对应的通过worker自己对底层的对象存储做通信。但是由于各种各样的原因，还会有跨机房的存在。现在有两个机房，每一个机房里都会有对应的S3服务，也会有相应的GPU计算节点。基本上每一个机房都会部署一个Alluxio。同时在这个过程中也要注意，一个机房里可能是两个Alluxio的对象存储，另外一个机房如果也要做S3挂载，尽量做好bucket名字的统一规致Alluxio挂载时的一些问题。载集群1的endpoint内网，在另一边就是外网，反之性能就会大打折扣。挂载之后可以通过同样的路径去访问不同集群上面不同bucket的数据，这样其实整个架构就会变得非常简单，这是跨机房部署方面。想要真正把NAS换成Alluxio，在部署之前要做很多功能测试。这种功能测试，目的是让现有的算法流程通过最小程度的改造，让算法同学也能用起来。这里可能涉及到如下内容：.数据集的组织方式；.最终访问的脚本接口。以上遇到的诸多问题可能都要做验证，至少要通过它选一个典型任务，然后做一些接下来在这个基础上，还要做一些性能测验。在这个过程中，不管是单机还是多的。其实真正体现Alluxio优势的是多主机上、分布式的能力。可以看到NAS或者举时它有一个明显的瓶颈，达到7/8G左右，就基本上稳定了。而Alluxio这边，整个测试过程，节点随着运行实例的增加，可的上限，当时设到20GB/s时，它都还是呈现出一直向上的趋势。这说明Alluxio整个并发的、分布式的性能非常好。做完功能验证和性能测试之后，就真正的要实际部署Alluxio集群，部署好之后，需要一个参数调参适配的过程。因为测试时，只采用了一些典型的任务，真的上Alluxio环境之后，会发现随着任务增多，会有一个参数调参适配的过程。需要把Alluxio上面相应的参数跟实际运行环境做匹配，然后才能够把它性能给发挥好。ETCD的节点：一开始是1后来增加至3节点，这样就保证即便某个ETCD节点挂与S3相关的：比如说Alluxio在实现的时候，他会让S3生成一个访问比较长的这种情况下，训练任务下面的S3，是做了权限管控的，不允许他们去写这种数FUSE节点本身能忍受的并发强度的能力：包括它要使用的DirectMemory的大小，实际上也和整个业务实际运行并发的强度多少有很大关系。和能够一次性访问的数据量其实是有很大关系的，这也有一个调参的过程，不一而足。可能会在不同环境下遇到不同的问题。这也是选择Alluxio企业版的原因。因为在企业版的过程中Alluxio会有非常强的支持，7*24h都可以做到遇到问题去调整、去配合。有了相互配合的周期，才能够让整个集群比较顺畅地运行起来。团队最早运维的同学只有一个人，他负责很多底层Infra的维护和相关工作，当我要把Alluxio部署上来的时候，其实运维那边的资源是不够的，所以相当于我也兼半个运维。从自己要去运维一个东西的角度来说，要做好很多运维方面的记录和知识沉淀，特别是对一个新手来讲很重要。比如下不是之前已经有过这样的经验。针对当时的环境，会维护好三份文档。.运维的历史记录文档：比如说哪一天出现了什么问题，这些问题我找到它根因样去看日志、怎样去排查、去看FUSE对应的数据是哪个任务、哪个worker上.配置的变更：因为Alluxio具体在调参的过程中。不同的时候，可能遇到的配置文件、yaml文件是不一样的，可能还要做一些备份。可以用Git管理，也可以简单地采用文档管理。通过这种方式可以追溯到当前配置和历史配置版本。在此基础上，还会有一些相关的配套建设，就是为了更好地使用Alluxio。研发同学使用下来认为Alluxio蛮好用的。但多任务的时候，就暴露出来一些配套建设的更多的任务缓存。训练数据集做跨集群同步，以便更好的做数据预加载。这些都是围绕着Alluxio要做的系统化建设。在不断使用Alluxio的过程中，也会发现一些值得改进的地方，通过给Alluxio反.稳定性：一定要在运行过程中稳定，不能因为Alluxio，一些东西crash了，让整个系统训练受阻。这里面可能有一些运维的小技巧，比如说尽可能不要让FUSE重启。刚才也提到了FUSE重启就意味着它的访问路径，读数据文件的.确定性：比如Alluxio之前建议数据不需要做预加载，即不需要在预训练之前读一遍，只需要在第一个epoch过程中读一遍。但是因为研发有发版周期，他要明确的知道预加载要多长的时间，如果通过第一个epoch去读，很难预估整个训练时间。这里面其实也会引申出来，怎样通过一个filelist做缓存这件事情，这个也给Alluxio提了一些需求。.可控性：虽然Alluxio是可以提供自动化的基于LRU的缓存驱逐清理缓存。但是实际上研发还是希望，一些已经缓存过的数据，能够主动做一些清理。那么能不能也通过提供filelist，让Alluxio把这块数据给free掉。这也是除了间接的用Alluxio，还要直接的、非常可控的用Alluxio的需求。.配置中心：Alluxio自己可以提供一个配置中心，把配置的历史给保存下来。增加一个功能以便实现配置项更改时，提前预算到这个改动到底影响的是什.Trace跟踪一个命令的运行过程：另外一个比较现实一点的需求，比如现在发现一个问题：访问底层的一个UFS文件时延时比较高，到底是什么原因？看FUSE的日志可能看不出原因，得需要再去看location对应的worker日志。的线上客服支持。Alluxio能不能加一个Trace命令，在要做访问的时候，把FUSE耗时、worker耗时、以及从UFS里面读它的耗时，一个全链路的耗时问题给Trace出来。这样其实对整个运维过程或者排查过程会有比较大的帮助。.智能监控：有时候监控的东西是已经知道的东西。比如说DirectMemory有问题了，去配一个监控项。但是如果下一次一个新问题在我的日志里面出来了，它可能是一个隐藏的问题，在人不知道的情况下悄悄地发生。这种情况希望可以自动的监控出来。通过工单反馈的方式，给Alluxio提了各种各样的建议。希望Alluxio能够在产品迭代过程中，提供更强大的功能。把整个研发、运维care的事项，做到更好的满足。第一，从Alluxio在整个自动驾驶模型训练的缓存加速方面，对比NAS它提供了很好的可用性。对辉羲来说它也会有10倍左右的提升。成本的降低来源于两部分:.产品采购成本低；.NAS可能会有20%-30%的冗余存储，Alluxio都可以解中的应用首先介绍一下中汽创智的自动驾驶整个开发业务流程。现在围绕自动驾驶开发主要强调的是数据闭环：开始是数据采集，数据采集之后进行预处理/数据挖掘，包括一些大模型的预刷；接着进入数据标注环节，主要包括人工标注和一些自动化的标评测和推理；最后再去迭代整个自动驾驶模型，模型经过上线进行实车部署。定厂里对车端的一些传感器进行刚性位置的关系调教，改装完的车去做实测采集，比如在城区的道路、高速公路进行采集。每天采集的数据量非常大，一天一辆车采集的数据大概在1TB左右。而采集回来的数据量没办法通过线上传输的方式上传到私有云或者公有云里，一般是通过特殊的存储介质拷贝带回来。当然也有实时的采集，比如每隔多长时间需要去做一些采样，这种数据是可以通过实时的采集传输到私有云里。可以看到自动驾驶业务的每个流程里都有数据传输和拷贝的环节，这都是跟存储加速强相关的。关于标注，公司内部研发了一个人工标注的数据平台，主要把采集回来的数据进行预处理，因为原始的数据可能是一个bag包，如同现在机器人开发里基于ros，里边类似于Javatopic机制