初探云原生下的AI应用文件系统-JuiceFS

导读：本文由梯度科技资深开发工程师屈骏对撰写，主要在云原生环境下介绍大数据，下文件存储提出的挑战和需求，在这样的背景下产生的JuiceFS的目标和架构设计，以及在大数据、人工智能等方案业务领域中的价值与收益。

前言

Kubernetes已经成为事实的应用编排标准，越来越多的应用在不断的向云原生靠拢，实现弹性伸缩、故障自愈等特性，其中还包括了大数据、人工智能等应用，等应用的使用大规模的非结构，在传统场景下已经有自己的解决方案，比如 HDFS、对象存储，然而当它们迁移到云端时，对架构也提出了新的挑战。

大数据上云，由于云端的动态迁移特性，需要支持存算分离，这也是数据湖架构发展的趋势，而标准的 HDFS 计算全局网络应用以及其NameNode所带来的扩展性困难都让其不再应用云端存储，与 HDFS 相比，对象存储采用了关键值的存储，方式简化了文件系统中数据与之间的组织结构，具备云原生所特有的易成本、高可用等特点，但也同样存在一些不足：

• List/Rename慢：对象存储按照目录进行list/Rename性能表现。

• 缺少完整的问题：多客户端可能出现的问题。

• 数据管理困难：非原生目录结构不监督管理员维护。

• 应用对接复杂：必须使用SDK或HTTP API，对应用有限制。

那么在这种场景下，我们所需要的云原生文件系统存储的呢：

1. 多互通：包括POSIX、HDFS、S3，其POSIX是最久经训练，生态的文件访问接口，同时支持多种协议，让各类应用可以连接协议对接平台，避免数据迁移所带来的使用；

2. 有用元数据：解决对象存储在计算、分析场景中的痛点；

3. 小文件管理能力：无论在大数据场景还是人工智能训练场景，十亿、百亿甚至千亿文件的管理需求被越来越多的亿；

4. Kubernetes 友好：支持 kubernetes 接口与生态，容易被运维人员所管理。

面对的需求，我们现有的CephFS、GlusterFS这样的拥有或多或少的不足，像CephFS已经有了Rook项目，可以很好的集成到Kubernetes，其团队的统一内部架构内，支持块存储、文件存储、对象存储，虽然非常吸引人，但系统的复杂性，以及独立的 MDS 元数据服务带来了增长的维护，而 Glusterfs 没有元数据服务器的设计让其更容易扩展，但其性能在小型文件下会出现在线学习，这一点是我们在机器布景下所接受的。

为了解决上述问题，这里我们介