案例分享｜Alluxio在自动驾驶模型训练中的应用与部署

分享嘉宾：
杨林三-辉羲智能

关于辉羲智能：
辉羲智能致力打造创新车载智能计算平台，提供高阶智能驾驶芯片、易用开放工具链及全栈自动驾驶解决方案，运用独创性“数据闭环定义芯片”方法学，助力车企构建低成本、大规模和自动化迭代能力，实现优质高效的自动驾驶量产交付，引领数据驱动时代的高阶智慧出行。

分享提纲：

1. 创业公司中，如何使用Alluxio？

2. 从0-1使用 Alluxio 的过程（调研-部署-上生产）。

3. 实践经验分享。

分享主题：
《 Alluxio 在自动驾驶模型训练中的应用与部署》

👉戳我观看完整回放👈

下文为完整文字版分享内容

自动驾驶数据闭环

首先分享一下自动驾驶中怎么样构建数据闭环，这个业务过程可能大家都有所了解。自动驾驶会包含多种车辆类型，比如数采车辆、带着算法在路上跑的车。数据采集就是在跑的过程中采自动驾驶车上的各种数据：比如说 camera 的数据就是图片，激光雷达的数据是点云。

传感器数据采回来，可能一辆车每天跑下来就有几T的数据。这种数据通过基盘的方式或者其他上传方式把它们整体存储起来，传到对象存储里面。原始数据存储之后会有一个 pipeline 做数据的解析预处理，比如把它切成一帧一帧的数据帧，每帧的不同传感器数据之间可能还要做同步对齐的操作。

完成数据解析之后，就要在上面做更多的挖掘。构建一个一个的数据集。因为不管是在算法、仿真或者测试里面，都要构建数据集。比如说我们想要雨天的某一个晚上，某一个路口，或者一些密集形成区域的数据，那我们就会在整个系统里面有大量的这种数据需求，要做数据的打标，打上一些标签。比如说在清华东门这个地方，需要去拿这个位置的经纬度，解析周围的 POI 。之后再对挖掘出来的数据做标注。常见的标注有：对象、行人、对象的类型等。

这种做了标注的数据，会被拿去做训练。典型的一些任务，比如目标的检测、车道线的检测、或者更大的端到端的模型。模型训练好了之后，还要做一些仿真验证。验证完再把它部署到车上面，再去跑数据，在这个基础上再去采更多的数据。就是这样的一个循环，不断的去丰富数据，不断的去构建性能更好的模型。这是整个训练，数据闭环要做的事情，也是现在自动驾驶研发里面较核心的事情。

算法训练：NAS

我们聚焦到模型训练来讲：模型训练主要是通过数据挖掘拿到数据，从而生成一个数据集。数据集在内部是一个 pkl 文件，包含数据、channel 、存储位置，最后数据算法训练的同学会自己写下载脚本，把数据从对象存储拉到本地。

我们在选用 Alluxio 之前，是通过 NAS 系统充当缓存的作用，把对象存储的数据拉到 NAS 上面，最后再用不同的模型，把数据 load 进来进行训练。这是使用 Alluxio 之前，大概的训练流程。

其中最大的问题在 NAS ：

1.第一是并发性能比较差——NAS 我们可以理解成它就是一块大的硬盘，当只有几个任务一起跑的时候，还是比较够用的。但是当有几十个训练任务同时进行、很多模型在训练的时候，往往就会出现卡死。我们曾经有一段时间卡死非常严重，研发每天都叫苦不迭。卡得严重以至于可用性非常差、并发性能很差。

2.第二是管理困难——每一个人都用自己下载的脚本，然后把想要的数据下载到自己的目录下面。另一个人可能又自己去下另外一堆数据，放到NAS的另外一个目录下面，这样就会造成 NAS 空间满时很难做清理。当时我们基本都是当面或者微信群沟通。一方面是效率特别低，依靠群消息管理会滞后。另外一方面，也会因为手动 remove ，导致一些风险。我们曾经出现过 remove 数据时，把别人的数据集给删掉的情况。这也会造成线上任务区域的报错，这是另外一个痛点。

3.第三是空间浪费——不同人下载的数据放在不同目录下，有可能同样一帧数据会出现在好几个数据集，存在比较严重的空间浪费。

4.第四是使用很复杂——因为 pkl 里面的文件格式不相同，使得下载逻辑也不一样，每个人都要单独去写下载程序。

这是我们之前用 NAS 会面临的一些困难和问题，为了解决这些问题，我们做了调研。调研后聚焦到Alluxio上来。发现 Alluxio 它可以提供一个比较统一的缓存，缓存可以提升我们的训练速度，同时也可以减少管理成本。我们还会用 Alluxio 的系统，处理双机房的问题。通过统一的命名空间和访问方式，一方面可以简化我们的系统设计，另外在代码实现上也会变得很简单。

算法训练引入 Alluxio

当我们把 NAS 换成 Alluxio 之后，Alluxio 能够针对性的解决刚才提到的一些问题：

1. 在并发性方面。NAS 本身不是一个完全分布式的系统，而 Alluxio 是。NAS 它访问的 IO 达到一定的速度时会出现卡顿，可能达到几个 G/s 的时候就会开始卡。而 Alluxio 的上限非常高，我们下面还有专门的测试来说明这一点。

2. 通过手动清理或者管理会非常麻烦。Alluixo 会配置缓存的逐出策略。一般是通过 LRU，当到一个 threshold 的时候（比如90%）它会自动做缓存的驱逐和清理。这样做的效果：

• 效率大大得提升；
• 可以避免因为误删导致的安全性问题；
• 解决了重复数据的问题。

在 Alluxio 里面，一个 UFS 里面文件，对应到 Alluxio 就是一个路径，当所有人都去访问这个路径时，就可以拿到对应的数据，这样就不会存在重复数据的问题。另外使用上面也比较简单，我们只需要通过 FUSE 的接口方式访问，不再需要下载文件。

以上是从逻辑层面解决了我们刚才讲的各种各样问题。下面讲一讲，我们整个落地的历程，怎么从 0 到 1 实现 Alluxio 从开始的 POC 测试，到各种性能的验证，再到最后怎么样部署、运维。我们的一些实践经验。

Alluxio 部署：单机房

首先，我们可能会在单机房里部署，就是一定要临近 GPU，部署到 GPU 节点上。同时利用之前 GPU 上很少用的 SSD，把每个节点都利用起来，然后把 FUSE 和 worker 部署在一起。FUSE 就相当于客户端，worker 就相当于一个具有内网通信的缓存小集群，做FUSE 的服务。最后对应的通过 worker 自己对底层的对象存储做通信。

Alluxio 部署：跨机房

但是由于各种各样的原因，我们还会有跨机房的存在。现在有两个机房，每一个机房里都会有对应的 S3 服务，也会有相应的 GPU 计算节点。基本上每一个机房我们都会部署一个 Alluxio 。同时在这个过程中也要注意，一个机房里可能是两个 Alluxio 的对象存储，另外一个机房如果也要做 S3 挂载，尽量做好 bucket 名字的统一规划，不能把两个搞重了。比如这里有个 bucket 1，那里又有一个 bucket 1，会导致 Alluxio 挂载时的一些问题。

还要注意，不同的 endpoint 要注意内网和外网的区分，比如集群1的 Alluxio，挂载集群1的 endpoint 内网，在另一边就是外网，反之性能就会大打折扣。挂载之后我们可以通过同样的路径去访问不同集群上面不同 bucket 的数据，这样其实整个架构就会变得非常简单，这是跨机房部署方面。

Alluxio 测试：功能

想要真正把 NAS 换成 Alluxio ，在部署之前要做很多功能测试。这种功能测试，目的是让现有的算法流程通过最小程度的改造，让算法同学也能用起来。这里可能要根据各位实际情况去操作。我们当时和 Alluxio 做过接近2-3周的 POC 验证，其中会涉及到，比如说：

• K8S 上访问 PVC 的配置；
• 数据集的组织方式；
• 作业提交的配置；
• 访问路径的替换；
• 最终访问的脚本接口。

以上遇到的诸多问题可能都要做验证，至少我们要通过它选一个典型任务，然后做一些改造，最后才能把 NAS 比较平稳的换成 Alluxio。

Alluxio 测试：性能

接下来在这个基础上，还要做一些性能测验。在这个过程中，不管是单机还是多机，我们都做了比较充分的测试。在单机上，Alluxio 和原来的 NAS 基本上性能是打平的。

其实真正体现 Alluxio 优势的是多主机上、分布式的能力。可以看到 NAS 或者我们举例的 QTS，它有一个非常明显的点：不稳定。测试3G 到 10G 间波动会比较大，同时它有一个明显的瓶颈，达到 7/8G 左右，就基本上稳定了。

而 Alluxio 这边，整个测试过程，节点随着运行实例的增加，可以达到一个非常高的上限，我们当时设到 20GB/s时，它都还是呈现出一直向上的趋势。这说明 Alluxio 整个并发的、分布式的性能非常好。

Alluxio 落地：调参适配环境

做完功能验证和性能测试之后，就真正的要实际部署 Alluxio 集群，部署好之后，需要一个参数调参适配的过程。因为测试时，只采用了一些典型的任务，真的上 Alluxio 环境之后，会发现随着任务增多，会有一个参数调参适配的过程。需要把 Alluxio 上面相应的参数跟实际运行环境做匹配，然后才能够把它性能给发挥好。所以会有边运行、边运维、边调参的过程。

我们经历了一些典型的调参过程，比如说：

1. ETCD 的节点。一开始是 1 后来增加至3节点，这样就保证即便某个ETCD节点挂了，整个集群不会受到影响。

2. 与 S3 相关的。比如说 Alluxio 在实现的时候，他会让 S3 生成一个访问比较长的路径，会在中间的路径节点，默认写一些空白，以至于让它具有更好的性能。但是这种情况下，我们训练任务下面的 S3 ，是做了权限管控的，不允许他们去写这种数据。面对这种冲突，也需要调参。

3. FUSE 节点本身能忍受的并发强度的能力。包括它要使用的 Direct Memory 的大小，实际上也和整个业务实际运行并发的强度多少有很大关系。和能够一次性访问的数据量其实是有很大关系的，这也有一个调参的过程，不一而足。可能会在不同环境下遇到不同的问题。这也是选择 Alluxio 企业版的原因。因为在企业版的过程中 Alluxio 会有非常强的支持， 7* 24h 都可以做到遇到问题去调整、去配合。有了相互配合的周期，才能够让整个集群比较顺畅地运行起来。

Alluxio 落地：运维

我们这个团队最早运维的同学只有一个人，他负责很多底层 Infra 的维护和相关工作，当我要把 Alluxio 部署上来的时候，其实运维那边的资源是不够的，所以相当于我也兼半个运维。从自己要去运维一个东西的角度来说，要做好很多运维方面的记录和知识沉淀，特别是对一个新手来讲很重要。比如下一次出现问题怎样更好地解决，是不是之前已经有过这样的经验。

针对我们当时的环境，会维护好三份文档。

1. 运维的历史记录文档：比如说哪一天出现了什么问题，这些问题我找到它根因是什么，它的解决方案是什么？具体操作是什么？

2. 操作文档：比如我们在 K8S 上面去运维，它的重启是哪几步、操作是什么、出现问题怎样去看日志、怎样去排查、去看FUSE对应的数据是哪个任务、哪个 worker 上面去运行、监控等等。都是常用的一些操作。

3. 配置的变更：因为 Alluxio 具体在调参的过程中。不同的时候，可能遇到的配置文件、yaml 文件是不一样的，可能还要做一些备份。可以用 Git 管理，也可以简单地采用文档管理。通过这种方式可以追溯到当前配置和历史配置版本。

在此基础上，我们还会有一些相关的配套建设，就是为了更好地使用 Alluxio。研发同学使用下来认为 Alluxio 蛮好用的。但多任务的时候，就暴露出来一些配套建设的需求。比如我们要去做图片的 resize，把图片从一开始高清4K ，降到 720P ，以便支持更多的任务缓存。

训练数据集做跨集群同步，以便更好的做数据预加载。这些都是围绕着 Alluxio 要做的系统化建设。

Alluxio 落地：共同进步

在我们不断使用 Alluxio 的过程中，也会发现一些值得改进的地方，我们通过给 Alluxio 反馈，促进了整个产品的迭代，从研发算法同学那边，他们 care 的是：

1. 稳定性：一定要在运行过程中稳定，不能因为 Alluxio ，一些东西 crash 了，让整个系统训练受阻。这里面可能有一些运维的小技巧，比如说尽可能不要让 FUSE 重启。刚才也提到了 FUSE 重启就意味着它的访问路径，读数据文件的时候，会失败、出现 IO 的 error。

2. 确定性：比如 Alluxio 之前建议数据不需要做预加载，即不需要在预训练之前读一遍，只需要在第一个 epoch 过程中读一遍。但是因为研发有发版周期，他要明确的知道预加载要多长的时间，如果通过第一个 epoch 去读，很难预估整个训练时间。这里面其实也会引申出来，怎样通过一个 file list 做缓存这件事情，这个也给 Alluxio 提了一些需求。

3. 可控性：虽然 Alluxio 是可以提供自动化的基于 LRU 的缓存驱逐清理缓存。但是实际上研发还是希望，一些已经缓存过的数据，能够主动做一些清理。那么能不能也通过提供 file list，让 Alluxio 把这块数据给 free 掉。这也是我们除了间接的用 Alluxio，还要直接的、非常可控的用 Alluxio 的需求。

从运维的这一端，也会提一些需求：

1. 配置中心：Alluxio 自己可以提供一个配置中心，把配置的历史给保存下来。增加一个功能以便实现配置项更改时，提前预算到这个改动到底影响的是什么；

2. Trace跟踪一个命令的运行过程：另外一个比较现实一点的需求，比如现在发现一个问题：访问底层的一个 UFS 文件时延时比较高，到底是什么原因？我们看 FUSE 的日志可能看不出原因，得需要再去看 location 对应的worker日志。这其实是一个非常耗时、麻烦的过程，而且往往排查不了问题，还需要Alluxio 的线上客服支持。Alluxio 能不能加一个 Trace 命令，在要做访问的时候，把 FUSE 耗时、worker 耗时、以及从 UFS 里面读它的耗时，一个全链路的耗时问题给 Trace 出来。这样其实对整个运维过程或者排查过程会有比较大的帮助。

3. 智能监控：有时候监控的东西是我们已经知道的东西。比如说 Direct Memory 有问题了，我们去配一个监控项。但是如果下一次一个新问题在我的日志里面出来了，它可能是一个隐藏的问题，在人不知道的情况下悄悄地发生。这种情况我们希望可以自动的监控出来。

我们通过工单反馈的方式，给 Alluxio 提了各种各样的建议。希望 Alluxio 能够在产品迭代过程中，提供更强大的功能。把整个研发、运维 care的事项，做到更好的满足。

小结

第一，从 Alluxio 在整个自动驾驶模型训练的缓存加速方面，对比 NAS 它提供了很好的可用性。对我们来说它也会有10倍左右的提升。成本的降低来源于两部分：

• 产品采购成本低；
• NAS可能会有20%-30%的冗余存储，Alluxio 都可以解决掉。

从可维护性的角度来讲，它可以自动清理数据，更加及时，也更加安全。易用性方面，它通过 FUSE 可以更便捷的访问数据。

第二，我也分享了辉羲是怎么样去从 0 到 1 部署 Alluxio ，运维一个系统。

以上就是我的分享，谢谢大家。