关于人工智能:小米云原生文件存储平台化实践支撑-AI-训练大模型容器平台多项业务

小米作为寰球出名的科技巨头公司，曾经在数百款产品中广泛应用了 AI 技术，这些产品包含手机、电视、智能音箱、儿童手表和翻译机等。这些 AI 利用次要都是通过小米的深度学习训练平台实现的。

在训练平台的存储计划中，小米曾尝试了多种不同的存储形式，包含 Ceph+NFS、HDFS 和对象存储挂载等。然而，这些不同的存储形式导致了数据冗余和保护治理老本的减少，同时也带来了扩展性和性能方面的问题。另外，随着公司云原生化过程的推动，越来越多的利用从物理机迁徙到容器平台，这进一步减少了对文件存储和多节点共享拜访数据的需要。

因而，小米存储团队自 2021 年开始启动了文件存储我的项目，基于 JuiceFS 构建了一个文件存储平台化产品，并通过 CSI Driver 组件提供了云原生存储的能力，以满足上述各种业务场景对文件存储的需要。

目前，这个平台曾经承载了超过 50 亿个文件，总容量 2.5PB 以上，集群吞吐达到每秒 300~400Gbps。业务场景也在一直扩大，涵盖了大模型数据存储、大数据以及数据湖上云等畛域。在接下来的内容中，咱们将深刻介绍小米在这一过程中的设计思路和实践经验。

01 为什么要建设对立的存储平台

一方面，咱们面临着以下三方面的需要增长：日益增长的利用场景：随着人工智能业务的倒退，咱们对大规模文件存储的需要也在快速增长，此外在容器内共享拜访数据、存算拆散、大数据上云、大模型等场景同样对文件存储有着泛滥的利用需要，这些场景均须要高效、牢靠的文件存储服务。

对立的文件存储计划：在咱们立项并进行 JuiceFS 我的项目之前，在机器学习平台咱们采纳了 Ceph RBD+NFS、S3 FUSE、HDFS 等多种数据存储形式，咱们冀望可能对立存储计划，将大部分数据放到同一存储平台，升高保护及数据冗余老本。

混合云场景：小米作为全球化企业，业务遍布寰球多个国家，在海内多个区域都会有文件存储相干的业务需要，咱们须要满足公有云 + 私有云一体的文件存储架构。咱们预期中的存储平台须要具备如下个性：

1. 功能丰富，领有欠缺的存储性能，反对 POSIX 等多种拜访协定，同时具备易用性，面向云原生平台设计。
2. 规模扩展性，可能撑持百亿文件、百 PB 容量规模的文件存储能力，可能弹性扩大。
3. 性能与老本，满足 AI 高并发训练等场景的性能需求，服务稳固牢靠同时兼顾存储老本。
4. 混合云场景，反对多种存储后端，反对云上云下不同应用环境。
5. 开发迭代，咱们有一个明确的指标，即借助开源我的项目，不反复造轮子。易于开发扩大与保护，可能继续迭代。

存储选型：CephFS vs JuiceFS

咱们比照了 JuiceFS、CephFS 以及其余一些业界文件系统的性能和性能。JuiceFS 社区文档也提供了一些的比照信息，如果您感兴趣，能够查阅 JuiceFS 社区文档。

首先，CephFS 在咱们的需要中有一些无奈满足的局部，例如，咱们心愿在私有云上部署，而 CephFS 可能更适宜在 IDC 环境中应用。其次，CephFS 在集群规模达到肯定水平时（例如 PB 级别），在均衡和元数据服务器性能方面可能会遇到一些瓶颈。

在 2021 年初，JuiceFS 我的项目刚刚开源，咱们就开始关注了。与 CephFS 等其余开源文件存储系统相比，JuiceFS 采纳了插件化的设计思维，为咱们提供了更大的灵活性 ，使咱们可能依据本身需要进行定制化开发。JuiceFS 还提供了丰盛的产品性能，可能满足咱们的特定场景需要。

同时，思考到 Ceph 作为底层存储服务在小米外部曾经大规模利用了多年，咱们能够将 Ceph RADOS 作为 JuiceFS 的数据存储池，在 IDC 机房内提供高性能和低提早的文件存储服务。这是咱们在选型时的根本思考，以下这些劣势是咱们抉择了 JuiceFS 作为整体存储服务的根底。

JuiceFS 劣势

JuiceFS 采纳了数据和元数据拆散存储的架构，同时具备齐全可插拔的设计，我集体认为这个构想十分杰出。在进行基于 JuiceFS 的二次开发时，咱们可能轻松地适应外部企业需要，充分利用已有的成熟组件，以满足不同利用场景下的数据管理需要。

JuiceFS 性能非常丰盛，它兼容了 POSIX、HDFS、S3 等多种拜访协定，反对数据的加密、压缩、文件锁等多项性能，并提供了 CSI 组件的反对，同时还具备绝对简单的扩大性能，这些满足了咱们对存储服务的根本需要。

性能方面 JuiceFS 体现卓越，借助其独特的数据切分治理和客户端缓存减速能力，为客户端提供了杰出的吞吐性能。

JuiceFS 社区生态十分沉闷，依据我所接触到的一些我的项目，我认为 JuiceFS 社区的运作是最出色的。 值得一提的是，在开源之前，JuiceFS 首先在商业畛域积攒了教训并利用于理论场景中，这为咱们提供了许多有价值的借鉴 。

通过以上思考，咱们过后决定基于 JuiceFS 构建一个面向云原生设计的、高性能且具备弹性可扩展性的共享文件系统。

02 小米存储平台架构及能力

作为一个文件存储平台，咱们的服务是处于底层地位的，旨在满足小米企业内多样的需要场景。这些场景不仅包含自驾等根底利用，还涵盖了容器共享存储、大数据等多种场景。咱们的指标是将产品化性能提供给业务部门，加强服务的易用性，使业务方可能更轻松地应用咱们的服务。

在上述架构图中，作为存储平台，咱们不仅提供了 JuiceFS 文件存储服务，还提供了基于 Ceph RBD 的块存储服务。同时，Ceph 为 JuiceFS 提供了底层对象存储反对。咱们还领有外部的 FDS 对象存储服务，能够适应 IDC 以及各种私有云对象存储，为业务提供无缝的跨多云的服务。咱们向下层提供了不同的协定反对，包含块协定、文件协定和对象协定。在更高层次，咱们为 PaaS 平台和计算层提供反对，最顶层则是应用层。

小米的 JuiceFS 架构与社区版 JuiceFS 基本相同。在 JuiceFS 客户端方面，咱们提供下层协定反对，并与咱们的 meta 服务和 data 服务进行底层对接。

咱们的我的项目启动较早，当初在 JuiceFS 开源时，meta 服务的抉择仅限于应用 Redis。然而，咱们的首个业务需要可能波及到数亿级别的文件规模，而 Redis 实际上难以无效反对这一规模。

与此同时，咱们的产品是一个平台化我的项目，因而咱们决定自行开发一个分布式的 meta 服务，用于对立治理集群，包含之前提到的简单性能，具备这样的中心化能力实际上会更容易实现咱们的指标。为存储元数据信息，咱们抉择了分布式 meta，基于另外一款开源存储我的项目 CubeFS 的 meta 模块实现。

优化 1：对立集群治理

依据咱们的场景需要，咱们对 JuiceFS 做了一些优化。” 集群对立治理 ” 这是咱们与 JuiceFS 社区版的架构最大的区别，也是咱们很多平台性能实现的根底。

在 JuiceFS 社区版中，文件系统之间不足对立的治理，用户须要自行设置他们本人的 meta 服务、bucket 等。例如，当业务部门创立一个新的卷时，他们须要本人申请 Redis、bucket、网关等，并设置后台任务，这使得整个过程繁琐且依赖于客户端。如果业务部门须要创立另一个卷，他们必须反复之前的工作，因为所有工作都是在客户端实现的。

小米的次要不同之处在于咱们将卷的治理进行了集中，将通用性能下沉，使得业务应用更加便捷。

首先，咱们能够看到在这个档次上，最顶层是 meta 服务，分为 master 和 metanode。咱们通过 meta master 进行了对立治理，将跨客户端的工作性能集成到了对立的治理档次。这包含根本的治理性能，如卷的创立和删除，以及存储池与 bucket 的治理，还包含一些会话管理机制。一些异步工作由核心对立保护，包含 compaction、数据清理等流程。

因为咱们有一个 master 层，因而咱们可能提供一些产品性能，包含权限接入，建设了对立的网关，并提供账单服务，以及对应外部控制台的性能接入。

优化 2：S3 网关

社区版的 S3 网关能够与一个卷绝对应，通常须要进行 Minio 的 AK/SK 配置。咱们首先在卷内进行了对立的治理，这使得它可能反对集群内所有卷的拜访，并提供了一个对立的 S3 接入域名。

因而，咱们在这一层上实现了文件系统的动静加载，使得多个卷能够通过同一个网关服务拜访数据。同时，在这一档次上，咱们也实现了小米外部 IAM 权限零碎的适配，反对多租户的 AK/SK。

在公共参数方面，例如缓冲缓存（--buffer-cache）、缓存大小（--cache-size），这些参数能够在多个卷之间全局共享，还有与 meta 相干的连接池实现了共享，反对多个卷的网关治理。

此外，咱们在网关服务上提供了一个齐备的监控零碎，用于监控申请吞吐量、提早、SLA 等性能指标。

优化 3：存储类型及多池治理

在进行了对立治理之后，咱们进行了存储类型的封装。对于业务方来说，他们不须要关怀数据存储在后端的存储介质或服务提供商。用户只须要抉择适宜其需要的服务类型。这个零碎提供了三种根本类型，包含性能型、容量型和老本型。性能型对应后端的 Ceph SSD 存储，容量型对应机械硬盘，而老本型则对接对象存储。每种类型实用于不同的应用场景，因而提供了不同的吞吐量和提早程度。

在存储类型方面，咱们引入了一层多池管理机制，对底层存储服务进行了对立治理和封装。绝对于社区版中卷（bucket）与存储池的一对一关系，咱们反对了多池治理性能，次要实现了以下能力：

首先，与业务相干的配置。存储池的配置以及 Ceph 的配置都由元数据系统进行对立治理，无需用户额定配置 Ceph 的环境变量或配置文件。

第二点，咱们容许卷设置存储类型，存储类型与存储池关联，并且在数据的切片级别进行记录。存储类型与其绑定的存储池是能够切换的，这样能够满足超大容量卷（百 PB 级别）的存储需要。

咱们的多池治理设计次要来源于对 Ceph 的思考。当 Ceph 集群规模达到肯定水平时，性能问题可能会显现出来，咱们不心愿保护特地大规模的 Ceph 集群，而是会建设新的集群，相当于将大容量划分为多个小集群来进行治理。这有利于缩小性能开销，缩小 OSD 存储故障的概率。同时也升高了治理节点的数量。咱们的操作就相当于将存储类型绑定的存储池切换到新的存储池上，旧数据依然存储在旧存储池中，而新的数据将被存储在新的存储池上，不会产生数据平衡移动。

此外，咱们还有更多操作的空间，能够按切片级别将数据迁徙到不同的存储池。基于这一能力，咱们能够实现更简单的性能，如依据文件拜访状况的冷热分层、基于 ec 纠删码 + 3 正本的大小 IO 分流优化等。

产品能力

咱们为团体外部提供了丰盛的产品性能，这些性能在企业外部是十分必要的性能：

• 权限零碎 ：咱们接入了 IAM（身份与拜访治理）资源权限管理系统，适配通用的鉴权性能，以确保只有通过受权的用户能够拜访资源。同时可能依据卷的归属找到相干我的项目部门及负责人，从而将存储资源精准地定位到理论负责的实体，有助于企业更好地进行治理。
• 控制台 ：接入小米交融云控制台，咱们提供了治理卷和文件的性能，不便业务应用
• 监控 ：咱们为 JuiceFS 集群和客户端提供了监控看板，帮忙企业实时理解零碎的性能和状态。
• 审计 ：对文件操作和数据读写进行审计，记录审计日志。这对一些敏感数据的业务十分重要，因为它能够告诉您哪些客户端正在拜访文件，以及文件是否曾被篡改或删除。
• 回收站 ：咱们反对回收站性能，能够帮忙企业躲避因误删数据而带来的危险，让数据更加平安可控。
• 账单 ：咱们提供按不同存储类型和存储容量计费的性能，帮忙企业理解和治理存储资源的费用。

大部分业务人员对于存储产品并不非常理解，因而在抉择适合的存储类型时经常感到艰难。为了帮忙外部用户更好地做出抉择，咱们提供了一些通用场景倡议。在控制台的卷文件治理方面，咱们采纳了相似于 Minio 平台的 S3 网关，用于多卷的文件内容治理，用户可能不便的进行文件治理和分享下载。

基于这些产品能力及云原生 CSI Driver 的性能，咱们曾经对接了小米容器平台及机器学习 PaaS 平台，业务依据须要抉择不同的集群与存储类型应用咱们的 JuiceFS 文件存储服务。在容器内应用 JuiceFS 时，咱们更偏向于优先采纳动态卷的形式来进行接入。首先，动态卷接入的劣势在于它们是明确定义和创立的，对其名称和用处都有明确的规定。相比之下，动静卷的应用往往波及到更简单的权限治理。另外，对于更底层的 Kubernetes 平台，咱们也为该服务提供了动态卷和动静卷两种接入形式。目前，咱们的大部分服务都是以原生形式提供的。

分布式 meta

咱们的元数据局部则是基于 CubeFS 进行开发的。最早，CubeFS 是由京东开源，是中国第一个开源分布式文件系统，涵盖了元数据（meta）、数据（data）以及最近的纠删码（EC）模块。

然而，当初咱们并没有间接采纳 CubeFS 的全副，次要有两个起因。首先，咱们更心愿可能充分利用私有云的资源，而过后的 CubeFS 仅反对自建存储。其次，咱们对 Ceph 有更深刻的理解，心愿可能在底层的数据局部进行灵便替换。因而，当初咱们只采纳了 CubeFS 的元数据局部。

元数据是基于 Multi Raft 进行全内存实现的，架构分为两个模块：Master 和 Meta。

• Master 是一个集群治理节点，负责管理存储卷和集群的根本配置信息，以及治理和调度 meta region，并向内部提供 HTTP 接口。
• meta 作为元信息节点。它通过 Multi Raft 治理 region，并向内部提供 TCP 和 HTTP 接口，反对横向扩大。

数据被划分为不同的 region。每个文件系统都有多个数据分片，依照 inode 区间进行划分。随着数据量的增长，分片的数量也会减少。每个分片都会被平均地散布在不同的元数据节点上。在肯定条件下，会进行决裂操作，以便更好地实现程度扩大。 目前，咱们的生产环境中最大的一个集群曾经领有了 30 多亿个文件，预计能够扩大到百亿级别 。

上图是 meta region 决裂的示意图，如果前两个 region 被写满，它就会变成只读状态。当最初一个 region 的文件数量达肯定规模或节点内存用量超过了阈值，那么最初一个分片就会决裂成两个，实现了 region 的横向扩大。

03 利用场景

JuiceFS 的利用场景次要包含 4 个场景：机器学习、文件长久化存储、共享数据拜访和大数据分析。目前，机器学习是咱们最大的业务畛域，大数据及大模型方面咱们正在积极探索中。

上图展现了咱们整体业务倒退的状况。咱们的繁多集群曾经达到了数十亿文件和 PB 级别的数据量，吞吐量达到数百 Gbps 的级别。

在过来的两年中，咱们正式地将 JuiceFS 接入到了咱们的学习平台。目前，它次要用于提供主动驾驶训练、局部手机训练和新一代语音训练的反对。

去年，咱们还反对了容器平台，公布了公共集群，并提供了容器平台的接口，以满足不同利用的需要。接着，咱们接入了小爱语音的训练业务。他们以前的部署形式是应用物理机上的 SSD 来运行 NFS 服务。然而，随着数据量的一直增长以及团队规模的扩充，他们很难进行扩容。此外，他们在数据管理方面也面临挑战。因而，去年他们决定采纳咱们的服务。

往年，咱们进行了一些新业务畛域的尝试，其中包含将大数据 Iceberg 迁徙到云端进行性能验证和比拟。此外，在大型模型的存储方面，咱们曾经反对了残缺的存储，包含原始语料的接入、算法训练和根本模型文件的存储。

大数据上云场景摸索

在将大数据 Iceberg 迁徙到云端的性能验证与同类产品相比，JuiceFS 在多种规格的 IO 读写场景下均表现出色，某些场景性能略优。

如上图所示，工夫越短越好，能够看到 JuiceFS 在某些场景的速度更快，某些场景略慢，整体性能能够和私有云产品媲美。同时值得一提的是，我也理解到一些其余的存储产品，在数据组织治理和减速设计方面或多或少受到了 JuiceFS 的启发。

语音场景业务收益

咱们目前曾经有许多业务迁徙并应用了 JuiceFS 文件存储服务，上面是以语音训练业务为例，介绍一下迁徙到 JuiceFS 后，给业务方带来的收益：

• 容量收益 ：语音组数据之前次要寄存在 NFS 上，常常遇到某台存储机器被写满，导致该机器上同学无奈持续写入的问题。随着训练规模的减少，容量扩大和容量治理都不不便。云平台 - 云存储组提供的 JuiceFS 实践上能够更好的满足咱们的需要。
• 老本收益 ：JuiceFS 单位容量的老本低于 NFS，目前语音组数据已由（NFS+FDS）迁徙至 JuiceFS，依据机器成本计算，每 T 容量每月的老本更低。
• 安全性 ：语音 NFS 采纳 RAID10 与 RAIDO 混部的形式，而目前采纳 3 正本模式存储，JuiceFS 上的数据安全性更有保障。
• 并发性 ：NFS 在应用时，用户的 IO 常常会集中在某一个存储节点上，某一台存储节点上的某个用户运行重 IO 工作后，同存储节点下的其余用户会受影响。而 JuiceFS 将数据扩散到多个节点上，多用户多机并发拜访时，用户相互影响小，IO 下限更高。

04 将来布局

更低成本

1. 冷热分层：咱们激励更多地应用私有云对象存储，以升高数据存储老本。
2. IDC 优化：咱们引入了高密度机型以缩小老本，并对存储形式进行了优化，采纳了 EC 纠删码存储形式，并实现了大小 IO 的拆散。
3. 元数据管理：咱们的元数据目前采纳了全内存模式，对于大量小文件的利用场景，元数据在内存中的占用可能会相当大，老本很高。为了升高解决老本，咱们须要反对 DB 模式，即不再应用全内存存储，而是采纳本地的 rocksdb + ssd 形式存储。

晋升性能

1. 进步全闪存储性能，反对 RDMA、SPDK，升高延时
2. GDS (GPU Direct Storage) 面向 AI 大模型场景，提供高速存储 能力
3. 优化 Meta 传输 proto 协定，缩小 marshal 开销及数据传输量

丰盛性能

1. 适配社区版本最新性能，如目录配额性能。
2. 心愿能实现 JuiceFS 商业版的局部能力，如反对分布式缓存性能，快照性能
3. lifecycle 生命周期治理
4. QoS 限速能力

05 JuiceFS 应用教训分享

• 客户端降级优化 ：在晚期，咱们面临了客户端降级的一些挑战。具体来说，Mount Pod 客户端降级要求迁徙 Mount Pod 上的所有业务，从新构建 Mount Pod，而后 Mount Pod 能力更新。这一过程十分繁琐，给业务方带来了很多困扰。

  为了解决这个问题，咱们实现了热重启性能，无需卸载即可降级客户端。通过 Unix Domain Socket 传递 /dev/fuse 文件描述符，并从新构建文件句柄，从而实现了新过程对挂载点的重建。这一改良使得 CSI Driver 降级时则无需从新调度 Mount Pod，大大降低了降级的难度。

• 本地磁盘缓存优化 ：在容器场景中，客户端磁盘通常是机械硬盘。当须要读取的数据集较大时，如果本地缓存空间无限，会导致缓存命中率非常低。尤其是当将 Ceph 作为存储池时，个别不倡议在业务中启用缓存。
• 预读优化 ：针对偏差于随机读取的场景，预读可能导致带宽大幅减少（高达数十倍）。为了解决这个问题，咱们引入了预读放大带宽的监控机制。当预读放大过多时，咱们倡议业务敞开预读配置。须要指出的是，这种状况绝对较为极其，在大多数数据场景中，启用预读依然能够显著晋升性能。
• 客户端开销优化 ：因为咱们是通过 Fuse 用户态过程挂载文件系统，会引入额定的开销。如果宿主机挂载了大量卷，可能会导致内存资源的大量占用。因而，咱们倡议在应用卷的时候提前布局好，能够思考应用子目录形式代替多卷挂载，以缩小内存资源开销。