Alluxio助力AI模型训练加速宝典+2.0实战篇.pdf

引言背景&Alluxio赋能AI场景小红书|加速云端机器学习-Alluxio在小红书的实践一、面临的挑战二、多云数据加速层三、小红书实践案例四、未来规划知乎|Alluxio AI助力知乎千卡模型训练一、混合云架构，带来便捷与挑战二、知乎的探索历程三、持续合作，保持探索B站|Alluxio 在B站AI训练场景的应用一、B站AI的训练场景二、Alluxio 在 AI 训练场景的应用三、未来规划辉羲智能|Alluxio在自动驾驶模型训练中的应用与部署一、自动驾驶数据闭环二、算法训练：NAS三、算法训练引入 Alluxio四、Alluxio 部署：单机房01目录1505031516182931313240414152525145535556五、Alluxio 部署：跨机房六、Alluxio 测试：功能七、Alluxio 测试：性能八、Alluxio 落地：调参适配环境九、Alluxio 落地：运维十、Alluxio 落地：共同进步十一、小结中汽创智|Alluxio在自动驾驶数据闭环中的应用一、自动驾驶业务介绍二、数据平台架构以及存储选型三、自动驾驶数据平台使用场景四、未来规划关于Alluxio02目录575859606162636565677078在当今这个人工智能飞速发展的时代，诸多企业正站在一个充满挑战与机遇的路口。随着AI模型训练的热潮不断升温，企业在追求更高性能计算的同时，也不得不面对GPU资源紧张、模型部署缓慢以及存储成本失控等问题。这些问题不仅加剧了技术团队的工作压力，也对企业的业务发展和市场竞争力构成了严峻考验。本电子书将深入剖析Alluxio如何在AI/ML场景中发挥其分布式缓存的作用，助力企业突破IO瓶颈。Alluxio作为一个高效的数据访问层，优化了数据在存储与计算引擎间的流动，显著提升了数据访问速度和操作便捷性。文章详尽地列举了企业在探索AI过程中遇到的挑战，细致阐释了Alluxio在技术架构中的关键角色，以及其如何通过优化AI框架的IO性能，提升整体数据处理能力。同时，文中通过小红书、知乎、B站、辉羲智能以及中汽创智等知名企业的实战案例，生动展示了Alluxio如何助力企业在解决技术难题的同时，实现更快的模型开发周期、更及时的数据更新、更高的模型准确性和可追溯性，以及更好地适应数据集的迅猛增长。本电子书将帮助用户迅速把握Alluxio如何助力企业应对AI模型训练的多重挑战，捕捉行业发展的脉搏，实现技术上的飞跃和业务上的持续增长。引言03用户收益实战经验借鉴：通过小红书、B站、知乎、辉羲智能等企业案例，了解如何将Alluxio应用于实际场景，解决具体的业务挑战。1.多云架构优化：了解如何在多云环境中利用Alluxio实现数据的高效管理和访问，从而优化多云架构下的数据使用和存储成本。2.性能与成本的双重优化：掌握如何通过Alluxio提升数据处理性能，同时实现成本优化。3.前沿技术洞察：获得对未来技术发展趋势的洞察，为技术选型和业务布局提供参考。4.灵活性与扩展性实践：了解Alluxio如何支持不同技术栈和框架，增强现有系统的灵活性和扩展性，以适应不断变化的技术需求。5.适用人群数据科学家与机器学习工程师、AI研发团队、技术架构师、基础设施团队、技术平台团队、云计算与存储团队、IT运维与系统管理员、业务分析师与决策者、学术研究人员、技术爱好者、产品经理、行业解决方案顾问04一、企业在尝试AI时面临的挑战1.GPU短缺其实从几年前就已经呈现了一些趋势，不管是在云上使用GPU还是自己购买GPU搭建IDC（数据仓库），AI基础设施都比较困难，原因大概可以分为3种情况：很多公司无法买到GPU；部分公司即使买到了GPU，量也不是很大，很难满足业务需求；部分公司或许可以在阿里云或者腾讯云上买到GPU，但如何把这些GPU形成一个系统的计算池，供上层业务使用，是比较困难的。2.模型上线慢公司现有数仓/存储方案较陈旧，很难迭代，进行GPU训练后，如何把模型上线到推理的集群中，是必不可少的一个环节，也是困难重重的一个环节：很多数仓、底层的存储都还是公司里比较传统的存储方案，比如HDFS，可能十几年前就开始用了，现在很难调整存储的设置；数据在云上，限流情况严重，使用限制较多。后面也会深入聊一下，如何解决这个问题。3.GPU使用率低现在很多公司模型训练过程GPU利用率普遍比较低，当然这个不是Alluxio一家就能解决的问题，普遍现象是：企业的数据大多在数仓中，这些数据如何引入GPU集群，存在非常多的挑战。后文也会分享在不同云厂商、国内外的大型企业中，Alluxio是如何解决这一问题的：背景&Alluxio赋能AI场景05前面所提到的更多都是业务的压力或者是商业上业务决策的压力，这些压力反映到基础上对工程人员来说就会变成技术压力，为了能够更快进行模型开发，Alluxio其实是有一些期望的：更快的模型开发时间；更频繁的模型数据更新；更高的准确性和可追溯性；适应快速增长的数据集。这些压力反映到技术侧大概可以概括为3点：1.广泛的数据拷贝任务管理比如以现在的应用，如何做这套系统，很多时候需要进行一些复杂的数据拷贝任务，从数据仓库往GPU的训练集群中进行数据拷贝，无论是拷贝到本地的NAS、NFS系统，或者是拷贝到本地的磁盘中进行数据管理，都是比较复杂的2.专用存储为了满足AI场景的需求，对性能的要求会比较高，可以这么理解：20-30年前，GPU是和HPC（高性能计算）一起发展起来的，所以那时候大家普遍倾向于要有一套IB的网络，并且是有一套高性能存储（全闪）支撑业务的发展，其实现在在云上或者是IDC里，这个问题是非常难解决的，因为大部分公司/云上设施没有办法提供这么高的专用存储支持模型训练或者是模型分发的任务。063.云和基础设施成本失控模型上线以后，随着业务规模的增长，云和基础设施的成本是非常容易失控的，可以看到非常多的场景，比如3年增加5倍的云上成本都是很正常的。二、Alluxio在技术栈中的位置在进入详细技术讨论之前，再系统介绍一下Alluxio在AI/ML技术栈中的位置。07首先，Alluxio不是一个持久化的存储层，持久化存储比较依赖云上S3 Storage、Ceph或者是HDFS这种分布式存储，这些都是Alluxio下面的一个接口，和Alluxio不是同一个概念。再往上，Alluxio在AI领域是一个高性能的接入层，因为对于持久化存储层来讲，大部分公司追求的是价格和性能效率，而这个效率就意味着要有一个非常便宜的存储池，可以存储很多资源，并不期望有一套非常昂贵的高性能存储来做持久化存储，之所以会这样是因为很多互联网厂商或者是传统企业的数据量有几百个PB甚至是EB级别的，但同时需要训练的数据并没有那么多，可能就是几十个TB，甚至高一点的也就1PB左右，如果可以把这些数据放到一个高性能存储向上进行对接，对用户来说这个性价比是非常低的，所以Alluxio比较依赖这种持久化存储层进行非常简单的对接，或者现在已经有了持久化存储层，不改变它的架构，可以直接进行数据对接。08再往上，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级别的，同时需要搭建一个AI Infra的平台，AI技术栈其实是Pytorch、TensorFlow，下面对接比较多的是对象存储，比如Ceph、MinIO等，其它的会有一些专用存储，比如提供NFS、NAS的这些系统向上对接；其实这两个系统的存在就产生了对接的问题，就是数据在数仓中，但是处理是到AI Infra里，这就变成一套非常复杂的系统了，而Alluxio可以帮助打通这套系统，不需要每次都进行非常复杂的数据迁移。2.随时获取及时、准确的模型数据模型的数据从训练集群出来，需要先落到存储中，然后再向上拉取到推理集群，这个过程很多时候是非常复杂的，比如Data Pipeline，之前遇到很多互联网公司都有一个临时的checkpoint store，然后还有一个持久化的checkpoint store，他们进行低性能和高性能的互相拉取是一个非常复杂的过程。3.避免复杂的数据迁移4.模型上线时间相比对象存储与传统数仓快2-4倍09底层存储一般都是对象存储或者是传统HDFS，比如传统的HDFS大家都是给大量数据存储设计的，这个不是为了性能而设计的，大部分情况是为了保障容错，同时针对云上的存储，在跟诸多云厂商交流后了解到，他们很多情况下没办法直接在云上用对象存储支持AI的业务，原因在于限流的问题，拉取数据的速度很快，所以没办法处理。下面详细介绍Alluxio是如何做这套系统的，里面有很多场景的沉淀，此处分享一下Alluxio架构设计的初衷：首先在很多互联网厂商群体中，大部分的客户/用户，他们的数据大概率是在数据湖中（有90-95%），他们的数据并不是以一个单独的数据集群来做这个事，而是有非常多的数据，包括传统的Hive Meta store、现在比较流行的数据湖里的数据，同时还有很多Streaming Data的数据直接进来，也有很多非结构化的数据是放在数据湖里的。那么Alluxio是如何在其中发挥作用的呢？现在比较流行的就是用Spark或者Ray的架构，把这个数据预处理完，放回数据湖中，后面的TensorFlow、Pytorch会拉取这里的数据进行训练，比如看左边这个图，如果不用Alluxio拉取数据会产生什么问题呢？比如原来的数仓用的是HDFS集群，AI训练会用一个Ceph的集群：userid:529794,docid:172662,date:2024-08-22,10首先要把处理好/未处理好的数据拉到Ceph的集群中，再向上serving这些拉取的data，在这里就会出现一些问题：首先这套拉取的流程会非常复杂，很多公司会自己开发一套数据管理系统完成，会有几套不同的流程在里边，比如用meta store对应这些表/数据在哪里；其次需要增量的拉取数据；最后需要对数据进行检验，查看是否有问题。这套流程下来从拉取到可用有很长的延迟，而Alluxio缓存的功能帮助大家解决这个问题。首先可以预先将部分数据加载到 Alluxio 中，放到更靠近计算的存储中，从而降低带宽消耗。同时，即使没有预加载数据，Alluxio 的缓存机制也能帮助快速拉取数据到训练集群中。这种方式类似于股票交易中的 T+1（T+0）交易，即从一开始访问数据的瞬间，数据就可以被迅速提供，不需要等待数小时再传递数据上去，从而节省了大量时间。其次，Alluxio 还能减少用户自行开发而产生的数据治理问题。如果用户已经有一套数据治理系统，Alluxio也提供了多种 API，包括原始数据更新的 API，方便用户进行定制化开发。此外，Alluxio还着重关注：在训练集群上如何降低成本并提高效率。过去很多公司使用高性能的存储集群进行训练，但这种成本可能非常昂贵，限制了业务的扩展。如果仅在 GPU 计算节点上配备磁盘，与 GPU 集群整体成本相比，这个成本通常不会超过 3-5%。此外，许多公司拥有大量存储资源，但如何充分利用这些资源仍然是一个挑战。Alluxio 在这方面提供了很多结合点。可以将 Alluxio 集群直接部署到训练节点上，这样的消耗非常小（约 30-40GB 内存），却能提供高性能的训练支持。用户只需要付出整个计算集群成本的 3-5%，就可以充分利用 GPU 集群，帮助用户克服IO瓶颈达到 GPU 100%使用率。11除了训练集群，Alluxio也特别关注推理集群的成本和效率问题。随着推理集群的扩展，成本可能远高于训练集群。因此Alluxio致力于解决如何快速将训练产生的模型部署到线上集群的问题。在传统方式中，训练结果会写回到一个 Ceph 存储，然后线上集群可能位于同一个或不同的 IDC 中，涉及到复杂的管理。很多公司会开发一套自己的存储网关(storage Gateway）来解决跨域或跨 IDC 的问题，但是网关解决的是一个跨域或者是跨IDC问题，实际上没有解决的是高性能和跨域的问题，简单理解就是可以把训练集群和线上的ML打通，但如果在AWS里这个Gateway是完全没有办法支撑推理集群的，比如扩展到100个甚至1000个节点的推理集群后，上线的时候会抖动的非常厉害，再比如：Alluxio可以在2-3分钟内把整个模型全都部署到推理集群上面，一般这种系统需要耗费的时间是它的10倍，而且它的P95和P99会非常长。三、Alluxio在模型训练&模型上线场景的应用接下来会详细讲解不同场景中，Alluxio是如何做的：12第一个就是之前说到的问题，在GPU非常短缺的情况下，很多公司其实之前都不是多云战略，不是IDC融合或者是云上、本地都有的架构，但为了满足GPU资源的部署，很多时候被迫变成这样，举个例子：很多客户/用户，数据都是在AWS上，根本就不想用Azure、Google Cloud等其他云，但今年，Azure把所有GPU都买了，在这种情况下其实很难说在AWS上可以找到所有集群，然后这些集群就必须在Azure里，就必须得有个方法直接去访问AWS里的数据，这个问题就导致如果直接去获取，数据性能就会非常低，如果是在网络带宽非常低的情况下，GPU的利用率通常不会超过10%，好一点的网络（比如有专线）情况下，可以达到20-30%。第二个问题是如果要建一个多集群数据管理是非常复杂的，包括要保证数据的一致性，如何更新、拉取这些数据，但Alluxio做了很多的集成，就可以直接使用Alluxio解决这些问题。其次就是不希望大家专门买一套硬件解决方案，之前接触过的实验室有在做HPC的，HPC有一个很大的问题就是成本非常高，买1套HPC通常可以买10套Hadoop硬件，或者是云上的存储硬件，所以如果需要购买一套专有的硬件搭建AI Infra 架构，是事倍功半的，成本非常昂贵，看到这个场景后，Alluxio提出还是希望可以直接在数据湖上构建AI和ML的数据通路，可以不更改存储系统，同时可以利用已有的，不需要额外购买IDMA这种硬件，就可以支撑训练的需求。同时不用考虑和原数仓中任务进行数据隔离的问题（所谓隔离就是需要进行数据迁移，然后运行成两套非常独立的系统，这对数据的拉取、获取是非常有问题的）。13上图就是前面提到的，Alluxio提供的一些功能，比如自动数据湖加载/卸载、更新数据功能，从而提高数据工程团队的生产力，一个比较常见的场景就是：如果基于原有的系统搭建，加一个Ceph，基本时间线会拉长到3-6个月，在国外公司拉长到6个月以上是非常常见的，但是用了Alluxio整套系统拉取后，基本就可以在1-2个月内把整个Data Pipeline建起来，如果大家感兴趣可以去详细了解一下知乎的应用案例，里边有非常详细的解读，告诉大家如何去搭建这套系统。上图是前面提到的另一个问题：模型部署受限于底层的存储，包括带宽的问题，还受限于IDC不同位置的问题，Alluxio可以做一个多云多架构，不管是从公有云到私有云，还是不同公有云之间进行模型部署，都会非常快速的解决这个问题，同时会提供一个高并发的缓存系统，支持业务高并发拉取。稍微总结一下，Alluxio在AI架构中处于怎样的位置？Alluxio帮助大家解决什么问题？第一个就是降低改造和适配的成本，帮助大家更聚焦在模型上线的逻辑上；第二个就是消除了专用存储架构，比如原来必须要用NAS、NFS这些系统来做的，用了Alluxio之后就不再需用，Alluxio和下面原来已有的HDFS，对象存储配合就可以搭建AI平台；14第三个就是需要添加缓存，就可以把GPU利用率提高到较高的水平；第四个就是满足公司自由部署GPU的需求，不管是云上还是云下买的GPU，不论数据在哪，都可以实现很高效的数据适配，后面会提供一个具体案例。关于Alluxio在AI场景是如何助力企业解决问题的，详细分享几个备受关注的案例：一、面临的挑战首看看小红书的业务都碰到了哪些挑战。小红书作为云上的原住民，从成立之初就构建在公有云上，下图是小红书多云架构的示意图：小红书|加速云端机器学习-Alluxio在小红书的实践15图中的三个圈代表两个云厂商的不同 Zone（区域），云厂商1是在 ZoneA 与ZoneB，云厂商2是在 ZoneC。核心业务分别分布在多个云厂商的不同可用区，核心业务如搜广推、社区通常在主要机房都会存在，是多活架构；主要业务如电商直播及部分大数据服务，是双活架构；其他如训练等服务，是单活架构，这个只是个简化后的示意图，真实情况远比这复杂。多云架构对小红书带来了非常明显的成本优势和可用性优势，但业务的通信链路也随之复杂，各种跨专线调用；还有个特点是不同 region 之间 rt 差异比较大，且专线容量非常稀缺，因此带来了一些业务使用上的痛点。多云架构下有哪些典型的问题机器学习训练在小红书是资源大户，属于公司 Top 级别，但海量的 CPU 和GPU 资源的利用率不及预期，训练速度上不去，业务体感比较差。1.推荐服务是小红书最核心的服务之一。它的核心逻辑是推荐召回需要有索引分发的过程，比如刷小红书刷到的个性化的笔记列表，就主要用到了索引。索引服务因为索引分发慢，从而导致稳定性比较差，且因为索引数据存储在云盘里，成本也很高。2.在AI场景下，有业务面临 60 亿+的元信息小文件场景，需要有一个低成本的解决方案。而且随着AI的飞速发展，AI 模型从之前的百 GB 级发展到如今的 TB级别。原来的架构通常先把模型拉到本地盘，再从本地盘加载到内存，才可以进行在线推理。这个过程在模型增大到 TB 级之后，会有两个严重的问题：一个是加载过程非常缓慢，另一个是模型存储在本地盘的成本非常高昂。3.多云架构本身带来的网络链路复杂，跨专线传输数据量非常大，专线单价也是非常高昂，有成本和稳定性的双重挑战。4.二、多云数据加速层接下来介绍下小红书是如何通过构建多云统一数据加速层来解决这些痛点的。16上图是小红书业务架构的示意图。最上层是业务层，主要包括社区、搜广推、直播、电商这些核心服务。接下来是平台层，这里只列了一些和数据强相关的，如机器学习平台、AI 训练平台，模型发布平台、推荐索引平台、数据平台等。最底层是公有云的存储产品，这里只列了主要依赖的对象存储，其实包括异构的 HDFS 等产品都可以适用于这个通用的解决方案。在平台层和存储层之间，基于 Alluxio 构建了一层多云统一数据加速层并研发了对应的智能缓存服务。为什么选择 Alluxio 作为多云统一的加速层首先基于面临的问题，抽象出了选型的重点目标：需要能够复用业务历史上已经存储的数据，不需要再次搬迁或者导入到其他高速存储或文件系统就能享受到数据的加速。以典型的搜广推和训练业务为例，这些业务的存储量大概是数百PB级别，搬迁一遍才能使用不太可行。需要支持 S3 和 POSIX 协议，以便于与其他平台无缝对接。如机器学习训练通常是 S3 协议，AI 训练通常是 POSIX 协议，如果加速层能够兼容这类协议，业务方就不需要改代码，迁移成本也会低很多。需要实现跨云专线传输的带宽控制和节省。因为跨云本身业务是多活、多云的。但多云之间本身就有实时的数据同步，如果把带宽打爆，那稳定性问题就会立马出来，所以一定要能够控制住带宽。能够支撑百亿级别的 AI 训练，小红书有单个训练任务就有60亿+元信息的场景需要支持。能够支持常见的云存储产品，以主流云厂商的对象存储为主。经过调研发现，业界目前唯一能同时满足上述诉求的产品，就是 Alluxio。17Alluxio主要特性18特性一：格式透明，不侵入业务数据存储格式。数据湖里的数据量非常大，是不可能再导入进来重复存储的，有了Alluxio，只需要在原来存储上加一层Alluxio，就可以直接去访问那些数据了，让业务直接享受到加速收益，这是非常关键的特性。特性二：协议兼容。Alluxio 支持非常丰富的S3POSIXHDFSJava FileAPIREST API等协议，帮助Alluxio上层AI/ML训练引擎（如Pytorch、Ray、TensorFlow）和查询引擎（如Presto、Spark、Trino）与底层存储进行无缝对接。特性三：多云统一视图。不管底层存储是HDFS、Ceph还是各云厂商的对象存储，对于用户，只要通过Alluxio，任何API都可以去访问不同存储位置的数据，从而可以实现多云统一视图的效果。特性四：数据仅需通过专线传输一次，后续可通过缓存就近读取，不需要再次跨专线，这个关键特性对小红书专线的保护意义重大。通过合理地利用这些特性，就能够解决上述提到的小红书多云架构的业务痛点。三、小红书实践案例机器学习训练场景19机器学习训练原架构机器学习训练最初的架构是直接从对象存储拉取数据（主要是训练样本），拉取完这些训练样本就开始在TensorFlow框架做训练。主要问题：训练速度不太符合预期，导致一些任务训练很慢，以及其他人排队调度不上，体验很差。海量的集群资源利用率太低对成本也带来了很大挑战。主要原因是一些热点的数据集（如小红书的笔记样本），是公共的样本，总量非常大（大概每天几百TB）。这些公共数据集会被很多任务使用，在小红书的场景下大概是 20 倍的扇出，如果是几百TB的数据会有 20 倍的扇出，这个总传输数据量是非常大的，整体流量达到了Tbps级，触达到了对象存储桶的带宽瓶颈。如果数据集大、扇出也大的话，一定会有额外的带宽需要，云厂商的解决方案通常是要么增加存储量，要么对增加带宽进行额外收费，两种方式都不太友好。因为业务会直连对象存储，而对象存储本身是高吞吐的产品，并不会过分强调单线程有多快，这就需要业务不断的去调优，才能达到适合的吞吐。基于以上三个问题，机器学习训练架构经过了升级改造，最新架构如下图所示。20新架构对于普通数据还是直接会去对象存储读取，对于笔记这种热点的训练数据集，会把它缓存到 Alluxio，当业务来 Alluxio 访问的时候，如果第一次数据不存在，就会去对象存储透传，然后把数据返回给训练框架，如果数据已经在Alluxio上，那就可以命中缓存，直接由 Alluxio 返回数据。虽然第一遍读完数据，Alluxio 一定会去缓存数据，但这还很难解决业务的问题。第一种情况是 Alluxio 缓存是用到本地磁盘把数据缓存下来，但磁盘容量是有限的，如果总训练的样本空间远大于磁盘缓存容量，就会不断的淘汰缓存数据，可能第一个任务缓存了，第二个任务就没有空间缓存了，或是会把别的缓存数据给挤掉。第二种情况是有些训练任务可能因为计算资源或者故障的原因带来严重的延迟，之后这个业务一旦跑上来，可能需要训练 30 天之前的数据，或者直接回溯很老的数据去训练，那这 30 天的数据很容易就把所有的缓存空间全部用掉。以上两种场景通过研发了智能缓存管理服务来解决。智能存储管理服务智能缓存管理服务主要是基于任务的历史运行规律，可以基于任务的历史运行规律，更加智能的把数据提前做预加载，这样通常第一次训练就能够命中缓存，而且可以更及时地淘汰掉不使用的缓存。不仅如此，还对缓存淘汰场景进行了评估，比如发现最近 1-2 天的笔记训练样本是非常重要的，就会把这些数据用 Pin 机制固定在磁盘里，就不会被自动淘汰，从而实现重要数据的淘汰完全由智能缓存管理服务去控制。通过这两个措施的共同保障，缓存命中率能跑到90%以上，很好节省了对象存储的带宽。同时，Alluxio 也提供了load任务的管理和执行能力，但目前还不完全符合小红书的需求。具体的业务中需要监控到任务粒度的 load 进展，比如有 10 个任务（有几个是重要的），在按小时提前预加载数据，结果集群故障了，但故障时间也较长，第二天马上又要用新的样本去训练数据，那该如何止损呢？措施是通过实现 load 进度的可观测机制，能够观察到每个任务当前正在加载第几小时的数据。当在不及预期的时候，会马上发出告警并做止损。当止损的时候，会基于任务的优先级去判断优先补偿哪些任务，并提供一键补偿的能力，看看这些任务已经错过了哪些小时的缓存数据，然后全部加载进来，从而规避带宽全部透传到对象存储所造成的的稳定性风险。第三是为稳定性实现了一个探针服务，它可以完全模拟业务的读写行为，是一个端到端的探活服务。探活实践下来非常好用，无论是代码本身有问题，还是机器磁盘、网络等出现问题，都能反映在探针里，方便快速介入。目前能达到3分钟发现和1分钟止损的效率。经过将近一年时间的运行，故障告警的准确率几乎达到了100%。训练速度提升效果2122上图展示的是一个非常典型的笔记训练大任务，其他业务训练效果都差不多。在迁移之前，训练时长达到9小时36分，单一任务就需要消耗2000核，非常消耗资源，而平均 CPU 利用率只有30%，只是到了最后面会有一些上升，这是因为这时候大部分任务已经训练完成，对象存储的带宽有些缓解了。在迁移到 Alluxio 之后，训练时长直接缩减到了 5 小时 42 分，从图中可以看到，CPU 利用率可以非常均匀的维持在75%，并且再也没有被限流影响到。整体训练速度在时长上优化了41%，虽然很多业务比这个效果更好，但这个例子是一个非常典型的大任务，更具有代表性。推荐召回索引下载场景23索引对于推荐非常核心，稳定性是非常重要的问题。上图是未引入 Alluxio 之前的架构图。最上面是搜推平台，会对搜推的索引做一些生成或者更新，更新完了之后会存储到索引存储（一般是就近机房的对象存储）。存储索引之后，搜推平台会通知其他服务下发索引，下发索引的服务会把数据通过专线从原来索引存储的对象存储桶传输到另外一个多云机房的本地磁盘，也就是索引服务的本地磁盘上。以图中的架构为例，共有两个跨区域的机房，当把索引数据下载到本地盘后索引服务就能够把数据加载到内存中，对外提供一些索引的服务。这样的架构带来的问题很大：以推荐场景下的索引读取速度来说，通常发布一个机房的服务需要 3-4 个小时，因为是多活设计，发布完四个机房整整需要一整天，这是非常令人头疼的问题。同样，当单机房发生故障，止损时长同样也需要 3-4 小时，如果你要把很老的一个索引回滚，就需要重新走这个流程，四个机房就需要一天时间。磁盘存储成本非常高。因为索引服务本身是一个主从架构，典型的场景是一主两从。同一个索引会有三副本的云盘存储，而云盘本身就是三副本冗余存储，那整体下来就是九副本，而云盘的单价通常比对象存储贵得多，这样计算下来整体成本是非常高的。下图是引入 Alluxio 之后的架构。从搜推平台生成索引之后，会把这个事件发送到消息队列，智能缓存管理服务订阅了该消息队列，收到相应的加载缓存事件后，就会去加载索引。现在的加载流程和之前就不一样了，之前是通过专线传输过来存到本地磁盘，现在是加载到 Alluxio 集群里，然后再告知索引服务，去 Alluxio 集群把数据再加载到索引服务的内存，从而对外进行服务。这里的关键点是把本地磁盘变成了 Alluxio 集群，那为什么采用 Alluxio 之后解决了以上问题呢？24首先，把磁盘上浮到了一个远程的集群，实现了索引的存算分离，把原来来自云盘的存储瓶颈，转换成了宿主机的网络瓶颈。云盘的带宽通常在云厂商相对还比较好的规格是 350 MB/s，但是宿主机不一样，推荐可用的一些机器至少都是 32 Gbps以上，合4GB/s，这两者的差距超过10 倍，因此下载索引数据这个过程就能提速10倍以上。第二，Alluxio 并不会把文件存储在固定的一台机器上（和本地盘不一样），一个文件会被切成 block 存储。比如一个集群有 100 台机器，一个文件能切 100 个block，那每个机器只会存1个block，这时候整个集群的带宽就是这个文件的吞吐极限。所以，对于一些热点的索引文件或者其他场景都是非常友好的。但这样直接用 Alluxio 还是会遇到问题，所以还加入了一些增强的功能，这也是为什么引入了智能缓存管理服务的原因。比如 load 太快会把专线打爆，需要Alluxio 支持限速，以保障核心服务的稳定性。现在已经支持了限速，当限制20-30Gbps的带宽从 UFS 下载数据，就不会把专线带宽占满。这套架构主要有三点收益：Alluxio 将云盘带宽瓶颈变成了宿主机的网卡瓶颈，索引拉取速度带来 10 倍以上的提升。如果宿主机的核数越大，附带的带宽也会更大，带来的提升倍数还会增大。1.索引下发的整体业务体感（含业务逻辑）达到 3 倍的提升。主要是因为除了下载，还有一些业务逻辑在这个索引下发的过程里。2.高性能云盘替换成对象存储，节省80%成本。此优化是通过 Alluxio 把云盘全部省掉，变成了Alluxio 的集群本地盘，而这些本地盘可以选择一些更廉价的介质，比如单副本的 HDD 盘。对于小红书的推荐场景，由于索引数据量很大，云盘成本的节省量也是非常可观的。3.大模型下载场景小红书也有大模型的场景，大模型下载的解决方案和推荐索引几乎一模一样，面临的同样是云盘带宽限制和冗余存储高成本以及跨云同步稳定性问题。3-4年前大家通常只做单机训练，现在已经演进到了几乎都是分布式训练的状态。那一定会需要通过远端的存储集群来解决本地数据存放不下的问题，这块架构与收益跟推荐索引一样，就不赘述了。25AI 训练场景面对的挑战：有 60 亿+级别的小文件训练场景，如果把这些元信息存储在一个集中式的元信息服务里，成本非常高，本身技术挑战也很大。对象存储作为很多存储的底座，最终数据会穿透到对象存储，会面临着存储带宽，或是 IOPS 比较有限的情况（尤其是小文件），云厂商通常一个桶提供几万 IOPS，每PB存储量的带宽配额也很低，尤其在小文件场景下，这点 IOPS承载不了多少访问，因此 GPU 利用率就会很低。解决方法：26引入 Alluxio 缓存训练需要的数据。Alluxio 3.0 版本提供了一个可扩展的元信息能力，让扩展性大幅提升。此外，Alluxio 本身支持 POSIX 协议，之前如果训练是在本地盘上，现在会把 Alluxio 集群 mount 到 GPU 机器上，由于 Alluxio 是透明嵌入，让业务方看其实还是访问的本地盘，背后其实是 Alluxio 集群。然后，通过Alluxio 集群去对象存储里取数据，基于 Alluxio 的缓存机制，可以有效的避免数据穿透到对象存储。因为通常 AI 训练是多轮的 epoch，Alluxio 只会让第一轮epoch 走对象存储，后面都可以命中这些缓存。甚至理想情况下，可以错峰把这些数据预加载到 Alluxio，这样真正训练的时候，完全不需要走对象存储。因为 GPU 机器上很多磁盘是闲置的，为了避免额外的支出成本，会把 Alluxio 和GPU 机器混合部署，让这些磁盘都可以被充分使用，也不会有额外的成本支出。Alluxio 相对于别的产品打造的非常成熟的能力是ClusterCache。在同样的总磁盘容量，ClusterCache 相对于Local Cache的命中率可以做到更高，比如有两个训练任务读同样的文件，如果落在两个不同的机器上，对于 Local Cache 会把数据读两遍，而对于 ClusterCache 只需要读一遍，第二次可以通过网络来传输，而GPU 机器之间的网络带宽也常非常高，通常有百Gbps，同时 Alluxio 也支持LocalCache，组合起来使用更佳。Alluxio 为什么能加速 AI 训练可以在业务训练之前提前把数据加载到缓存中，突破IO限制，相比穿透对象存储读取性能更高；读取数据时通过智能判定是随机读还是顺序读。如果是顺序读可以提前预读数据，从而达到更高的读吞吐；如果是随机读，可以精准地控制要读哪个位置，避免读的放大；无集中式的元信息服务，全量元信息在对象存储，只有热数据及其元数据在缓存中，对海量小文件友好，相比于集中式元信息服务，成本极低；可异步写 checkpoint 到本地磁盘，再异步上传至对象存储，通过有效缩短 IO负载时长，从而大幅缩短GPU 等待时间，并显著提升 GPU 利用率。27技术问题及解法在与 Alluxio 的合作过程中，小红书也一起参与解决了非常多的技术问题，这里有几个比较典型的场景：读放大问题解决：主要表现在 S3 协议里会有一些 range 读，以及 Alluxio client、fuse 或者其他一些触发随机读的场景。放大主要存在两个环节：一个是 S3 proxy 到 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 的地方加限流就可以控制住专线。而客户端和 S3 Proxy 的交互，以及 S3 Proxy 与 worker的交互都是同机房的一个流量，理论上也需要保护，但不影响专线。读写性能优化：在读性能优化方面，通常是识别了读的特征之后做预读，通过预读能够明显提升读的性能，尤其是在冷读数据的情况下。在Checkpoint写方面，一定不能阻塞训练，所以支持了WriteBack 能力，WriteBack 是指先异步写到磁盘甚至内存中，然后就可以开始后续训练，通过后台线程异步上传。同样也有一些线程模型的优化，整体对读写的性能也有非常大的提升。四、未来规划未来小红书会把数据加速层做成什么样子以及还有哪些待解决的问题呢？打造统一的多云数据存储产