面临的挑战

• 机器学习训练在小红书是资源大户，属于公司 Top 级别，但海量的 CPU 和 GPU 资源的利用率不及预期，训练速度上不去，业务体感比较差。

• 推荐服务是小红书最核心的服务之一。它的核心逻辑是推荐召回需要有索引分发的过程，比如刷小红书刷到的个性化的笔记列表，就主要用到了索引。索引服务因为索引分发慢，从而导致稳定性比较差，且因为索引数据存储在云盘里，成本也很高。

• 在 AI 场景下，有业务面临 60 亿 + 的元信息小文件场景，需要有一个低成本的解决方案。
  而且随着 AI 的飞速发展，AI 模型从之前的百 GB 级发展到如今的 TB 级别。原来的架构通常先把模型拉到本地盘，再从本地盘加载到内存，才可以进行在线推理。这个过程在模型增大到 TB 级之后，会有两个严重的问题：一个是加载过程非常缓慢，另一个是模型存储在本地盘的成本非常高昂。
• 多云架构本身带来的网络链路复杂，跨专线传输数据量非常大，专线单价也是非常高昂，有成本和稳定性的双重挑战。

多云数据加速层

1. 为什么选择了 Alluxio 作为多云统一的加速层？

• 需要能够复用业务历史上已经存储的数据，不需要再次搬迁或者导入到其他高速存储或文件系统就能享受到数据的加速。以典型的搜广推和训练业务为例，这些业务的存储量大概是数百 PB 级别，搬迁一遍才能使用不太可行。
• 需要支持 S3 和 POSIX 协议，以便于与其他平台无缝对接。如机器学习训练通常是 S3 协议，AI 训练通常是 POSIX 协议，如果加速层能够兼容这类协议，业务方就不需要改代码，迁移成本也会低很多。
• 需要实现跨云专线传输的带宽控制和节省。因为跨云本身业务是多活、多云的。但多云之间本身就有实时的数据同步，如果我们把带宽打爆，那稳定性问题就会立马出来，所以我们一定要能够控制住带宽。
• 能够支撑百亿级别的 AI 训练，我们单个训练任务就有 60 亿 + 元信息的场景需要支持。
• 能够支持常见的云存储产品，以主流云厂商的对象存储为主。

Alluxio 主要有五部分模块：

• Master：主要负责元信息的服务，维护了文件及其 Block 的位置信息，并负责处理元信息请求；

• Worker：主要负责数据的缓存以及读取；

• Job Master：主要负责一些异步任务的管理，比如加载缓存、淘汰缓存等这些异步的任务的下发及管理

• Job Worker：主要是负责 Job Master 下发任务的具体执行，其执行状态会在 Job Master 进行维护；

• Alluxio Client：会通过 Master 去拿文件的元信息，之后会通过元信息知道这个文件对应位置的数据会在哪个 worker 上存储，接着就可以去对应的 worker 取数据。如果取数据的时候发现这个数据并不在 Alluxio 缓存里，就会去 Under Store 取数据（ Under Store 是对底层存储的统称，此案例里主要指对象存储），取下来之后响应给客户端，同时 Alluxio 会把这个数据缓存下来，当再次读取同样数据的时候就能够命中缓存了，这是非常重要的特性。

2. Alluxio 主要特性

• 特性一：格式透明，不侵入业务数据存储格式。我们数据湖里的数据量非常大，是不可能再导入进来重复存储的，有了 Alluxio，只需要在原来存储上加一层 Alluxio，就可以直接去访问那些数据了，让业务直接享受到加速收益，这是非常关键的特性。

• 特性二：协议兼容。Alluxio 支持非常丰富的 S3\POSIX\HDFS\Java File API\REST API 等协议，帮助 Alluxio 上层 AI/ML 训练引擎（如 Pytorch、Ray、TensorFlow）和查询引擎（如 Presto、Spark、Trino）与底层存储进行无缝对接。

• 特性三：多云统一视图。不管底层存储是 HDFS、Ceph 还是各云厂商的对象存储，对于用户，只要通过 Alluxio，任何 API 都可以去访问不同存储位置的数据，从而可以实现多云统一视图的效果。

• 特性四：数据仅需通过专线传输一次，后续可通过缓存就近读取，不需要再次跨专线，这个关键特性对我们专线的保护意义重大。

03

小红书实践案例

1. 机器学习训练场景

• 训练速度不太符合预期，导致一些任务训练很慢，以及其他人排队调度不上，体验很差。

• 海量的集群资源利用率太低对成本也带来了很大挑战。主要原因是一些热点的数据集（如小红书的笔记样本），是公共的样本，总量非常大（大概每天几百 TB）。这些公共数据集会被很多任务使用，在我们的场景下大概是 20 倍的扇出，如果是几百 TB 的数据会有 20 倍的扇出，这个总传输数据量是非常大的，整体流量达到了 Tbps 级，触达到了对象存储桶的带宽瓶颈。如果数据集大、扇出也大的话，一定会有额外的带宽需要，云厂商的解决方案通常是要么增加存储量，要么对增加带宽进行额外收费，两种方式都不太友好。

• 因为业务会直连对象存储，而对象存储本身是高吞吐的产品，并不会过分强调单线程有多快，这就需要业务不断的去调优，才能达到适合的吞吐。

2. 训练速度提升效果

3. 推荐召回索引下载场景

• 以推荐场景下的索引读取速度来说，通常发布一个机房的服务需要 3-4 个小时，因为是多活设计，发布完四个机房整整需要一整天，这是非常令人头疼的问题。同样，当单机房发生故障，止损时长同样也需要 3-4 小时，如果你要把很老的一个索引回滚，就需要重新走这个流程，四个机房就需要一天时间。

• 磁盘存储成本非常高。因为索引服务本身是一个主从架构，典型的场景是一主两从。同一个索引会有三副本的云盘存储，而云盘本身就是三副本冗余存储，那整体下来就是九副本，而云盘的单价通常比对象存储贵得多，这样计算下来整体成本是非常高的。

• Alluxio 将云盘带宽瓶颈变成了宿主机的网卡瓶颈，索引拉取速度带来 10 倍以上的提升。如果宿主机的核数越大，附带的带宽也会更大，带来的提升倍数还会增大。

• 索引下发的整体业务体感（含业务逻辑）达到 3 倍的提升。主要是因为除了下载，还有一些业务逻辑在这个索引下发的过程里。

• 高性能云盘替换成对象存储，节省 80% 成本。此优化是通过 Alluxio 把云盘全部省掉，变成了 Alluxio 的集群本地盘，而这些本地盘可以选择一些更廉价的介质，比如单副本的 HDD 盘。对于小红书的推荐场景，由于索引数据量很大，云盘成本的节省量也是非常可观的。

4. 大模型下载场景

5. AI 训练场景

• 有 60 亿 + 级别的小文件训练场景，如果把这些元信息存储在一个集中式的元信息服务里，成本非常高，本身技术挑战也很大。

• 对象存储作为很多存储的底座，最终数据会穿透到对象存储，会面临着存储带宽，或是 IOPS 比较有限的情况（尤其是小文件），云厂商通常一个桶提供几万 IOPS，每 PB 存储量的带宽配额也很低，尤其在小文件场景下，这点 IOPS 承载不了多少访问，因此 GPU 利用率就会很低。

• 引入 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，组合起来使用更佳。

6. Alluxio 为什么能加速 AI 训练

• 可以在业务训练之前提前把数据加载到缓存中，突破 IO 限制，相比穿透对象存储读取性能更高；

• 读取数据时通过智能判定是随机读还是顺序读。如果是顺序读可以提前预读数据，从而达到更高的读吞吐；如果是随机读，可以精准地控制要读哪个位置，避免读的放大；

• 无集中式的元信息服务，全量元信息在对象存储，只有热数据及其元数据在缓存中，对海量小文件友好，相比于集中式元信息服务，成本极低。

• 可异步写 checkpoint 到本地磁盘，再异步上传至对象存储，通过有效缩短 IO 负载时长，从而大幅缩短 GPU 等待时间，并显著提升 GPU 利用率。

7. 技术问题及解法

（1）读放大问题解决

（2）专线带宽限流

（3）读写性能优化

04

未来规划

1. 打造统一的多云数据存储产品

2. AI 训练：多地域 GPU 利用率提升

3. 大数据查询加速

4. 低效节点资源利用率提升