Alluxio助力AI模型训练加速宝典+2-WN8

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