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

目录 引言03 背景&Alluxio赋能AI场景05 小红书|加速云端机器学习-Alluxio在小红书的实践15 一、面临的挑战15 二、多云数据加速层16 三、小红书实践案例18 四、未来规划29 知乎|AlluxioAI助力知乎千卡模型训练31 一、混合云架构，带来便捷与挑战31 二、知乎的探索历程32 三、持续合作，保持探索40 B站|Alluxio在B站AI训练场景的应用41 一、B站AI的训练场景41 二、Alluxio在AI训练场景的应用45 三、未来规划51 辉羲智能|Alluxio在自动驾驶模型训练中的应用与部署52 一、自动驾驶数据闭环52 二、算法训练：NAS53 三、算法训练引入Alluxio55 四、Alluxio部署：单机房56 目录 五、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如何支持不同技术栈和框架，增强现有系统的灵活性和扩展性，以适应不断变化的技术需求。 适用人群 数据科学家与机器学习工程师、AI研发团队、技术架构师、基础设施团队、技术平台团队、云计算与存储团队、IT运维与系统管理员、业务分析师与决策者、学术研究人员、技术爱好者、产品经理、行业解决方案顾问 背景&Alluxio赋能AI场景 一、企业在尝试AI时面临的挑战 1.GPU短缺 其实从几年前就已经呈现了一些趋势，不管是在云上使用GPU还是自己购买GPU搭建IDC（数据仓库），AI基础设施都比较困难，原因大概可以分为3种情况： 很多公司无法买到GPU； 部分公司即使买到了GPU，量也不是很大，很难满足业务需求； 部分公司或许可以在阿里云或者腾讯云上买到GPU，但如何把这些GPU形成一个系统的计算池，供上层业务使用，是比较困难的。 2.模型上线慢 公司现有数仓/存储方案较陈旧，很难迭代，进行GPU训练后，如何把模型上线到推理的集群中，是必不可少的一个环节，也是困难重重的一个环节： 很多数仓、底层的存储都还是公司里比较传统的存储方案，比如HDFS，可能十几年前就开始用了，现在很难调整存储的设置； 数据在云上，限流情况严重，使用限制较多。后面也会深入聊一下，如何解决这个问题。 3.GPU使用率低 现在很多公司模型训练过程GPU利用率普遍比较低，当然这个不是Alluxio一家就能解决的问题，普遍现象是：企业的数据大多在数仓中，这些数据如何引入GPU集群，存在非常多的挑战。 后文也会分享在不同云厂商、国内外的大型企业中，Alluxio是如何解决这一问题的： 前面所提到的更多都是业务的压力或者是商业上业务决策的压力，这些压力反映到基础上对工程人员来说就会变成技术压力，为了能够更快进行模型开发，Alluxio其实是有一些期望的： 更快的模型开发时间；更频繁的模型数据更新； 更高的准确性和可追溯性；适应快速增长的数据集。 这些压力反映到技术侧大概可以概括为3点： 1.广泛的数据拷贝任务管理 比如以现在的应用，如何做这套系统，很多时候需要进行一些复杂的数据拷贝任务，从数据仓库往GPU的训练集群中进行数据拷贝，无论是拷贝到本地的NAS、NFS系统，或者是拷贝到本地的磁盘中进行数据管理，都是比较复杂的 2.专用存储 为了满足AI场景的需求，对性能的要求会比较高，可以这么理解：20-30年前，GPU是和HPC（高性能计算）一起发展起来的，所以那时候大家普遍倾向于要有一套IB的网络，并且是有一套高性能存储（全闪）支撑业务的发展，其实现在在云上或者是IDC里，这个问题是非常难解决的，因为大部分公司/云上设施没有办法提供这么高的专用存储支持模型训练或者是模型分发的任务。 3.云和基础设施成本失控 模型上线以后，随着业务规模的增长，云和基础设施的成本是非常容易失控的，可以看到非常多的场景，比如3年增加5倍的云上成本都是很正常的。 二、Alluxio在技术栈中的位置 在进入详细技术讨论之前，再系统介绍一下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的客户/用户环境中总结的价值是有非常多的，大概可以概括成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倍 底层存储一般都是对象存储或者是传统HDFS，比如传统的HDFS大家都是给大量数据存储设计的，这个不是为了性能而设计的，大部分情况是为了保障容错，同时针对云上的存储，在跟诸多云厂商交流后了解到，他们很多情况下没办法直接在云上用对象存储支持AI的业务，原因在于限流的问题，拉取数据的速度很快，所以没办法处理。 下面详细介绍Alluxio是如何做这套系统的，里面有很多场景的沉淀，此处分享一下Alluxio架构设计的初衷： 首先在很多互联网厂商群体中，大部分的客户/用户，他们的数据大概率是在数据湖中（有90-95%），他们的数据并不是以一个单独的数据集群来做这个事，而是有非常多的数据，包括传统的HiveMetastore、现在比较流行的数据湖里的数据，同时还有很多StreamingData的数据直接进来，也有很多非结构化的数据是放在数据湖里的。 那么Alluxio是如何在其中发挥作用的呢？ 现在比较流行的就是用Spark或者Ray的架构，把这个数据预处理完，放回数据湖中，后面的TensorFlow、Pytorch会拉取这里的数据进行训练，比如看左边这个图，如果不用Alluxio拉取数据会产生什么问题呢？ 比如原来的数仓用的是HDFS集群，AI训练会用一个Ceph的集群： 首先要把处理好/未处理好的数据拉到Ceph的集群中，再向上serving这些拉取的data，在这里就会出现一些问题：首先这套拉取的流程会非常复杂，很多公司会自己开发一套数据管理系统完成，会有几套不同的流程在里边，比如用metastore对应这些表/数据在哪里； 其次需要增量的拉取数据； 最后需要对数据进行检验，查看是否有问题。 这套流程下来从拉取到可用有很长的延迟，而Alluxio缓存的功能帮助大家解决这个问题。 首先可以预先将部分数据加载到Alluxio中，放到更靠近计算的存储中，从而降低带宽消耗。同时，即使没有预加载数据，Alluxio的缓存机制也能帮助快速拉取数据到训练集群中。这种方式类似于股票交易中的T+1（T+0）交易，即从一开始访问数据的瞬间，数据就可以被迅速提供，不需要等待数小时再传递数据上去，从而节省了大量时间。 其次，Alluxio还能减少用户自行开发而产生的数据治理问题。如果用户已经有一套数据治理系统，Alluxio也提供了多种API，包括原始数据更新的API，方便用户进行定制化开发。 此外，Alluxio还着重关注：在训练集群上如何降低成本并提高效率。过去很多公司使用高性能的存储集群进行训练，但这种成本可能非常昂贵，限制了业务的扩展。如果仅在GPU计算节点上配备磁盘，与GPU集群整体成本相比，这个成本通常不会超过3-5%。此外，许多公司拥有大量存储资源，但如何充分利用这些资源