Juicedata 合伙人：云上文件系统有何不同，看 JuiceFS 如何做？

JuiceFS 是为云设计的分布式文件系统，该项目创立于 2017 年，初始阶段是在全球十几家不同的公有云上发布全托管服务。到 2021 年的时候，我们向社区发布了一个开源的社区版本。

开源之初，我们先选择了 AGPLV3 许可证，在经过一年的发展之后，JuiceFS很快受到了来自全球社区的响应，很多人开始用起来，我们的用户群里也变得挺热闹。在这个过程中，我们也发现在 AGPLv3 许可的选择不够开放。所以开源一年之后，我们发布第一个 LTS 版本 v1. 0 的时候，同时把许可证也改成了Apache2。

希望在整个数据生态，上下游生态，还有一些其他的合作伙伴做集成的时候，都能基于Apache 许可做得更加的轻松和开放。

JuiceFS已开源满两年，目前每天从我们能看到的部分数据，在全球已经有接近 2000 的活跃集群在使用。在 GitHub 上有7700+颗Star。在全球的分布式文件系统里，JuiceFS已经成长到第四的位置，应该是过去这两年间成长最快的一个项目了。

上述做了项目的介绍，今天主要想讲一下JuiceFS项目的一些设计的理念和故事。本期分享主要会以三个部分展开。

首先会简单介绍一下什么是文件存储，它与我们经常听说的 S3 对象存储会有什么差别。也会带大家回顾一下文件存储的发展过程，然后介绍JuiceFS 在设计过程中的一些理念、思考，以及我们最终在工程上的实践。

分享概要：1.回顾文件存储的发展，以及当下的痛点与挑战2.JuiceFS 的设计理念与方法

3.JuiceFS 在业务中的应用与收益

先搞清楚什么是文件系统

文件系统，是一个计算机领域很基础的概念，它基础到往往会被我们日常使用的时候忽视。在 Wikipedia 上的介绍，文件系统是一种用目录来组织数据的方法和数据结构。它为了让我们的数据可以更方便地存储和访问，所以更直观一点看文件系统里我们会接触到的概念，一般会有文件，文件夹（也叫目录），还有像权限、时间戳、软链接、硬链接，还有锁这些概念。我们最常见的肯定是单机文件系统，比如 Linux 里有ext4、XFS， Windows 有FAT32、NTFS， macOS 也有自己的文件系统。它们的作用是把我们买回来的一块硬盘，通过文件系统定义的数据结构去格式化，在硬盘上就占用一小块空间，里面是一个分区表，分区表中的数据管理了整块硬盘上文件与目录的组织形式。单机文件系统和共享文件系统有很多相似的地方，但是在公有云上从 AWS 推出 S3开始，大家也越来越多地了解和使用对象存储。

文件存储和对象存储之间到底有何差别

有些开发者并不清楚文件系统和对象存储二者之间到底有何差别，我举一个例子。

这张图上列出来了一个文件系统，它以目录树的形式。可以看到在根目录上有一个名字为 /foo的目录。在目录下又有多层的子目录。如果将类似的结构展示在对象存储里是什么样？

大家可以看到，在对象存储里没有目录结构，我们所有的文件或者叫做对象都是以扁平的方式存放。在 S3或者所有的对象存储里都有一个最基本的概念，叫做 bucket（桶）。这个桶相当于我们文件系统里的 volume（卷）。比如 Linux 中，我们可以挂载一块硬盘，它就是一个卷，且可以挂载多个卷。 

同样 S3里也你也可以创建多桶。但是在这一个桶里，它是不分上下左右层次的，所有的文件或者数据都是对象，都往桶里扔，它们在桶里是没有层次结构的管理。但是为了方便自己的记忆，每一个对象有一个key，相当于一个 ID 标识符。所以我们可以将之前文件系统中多层的目录结构，用路径风格的写法作为对象 key 的名字。比如 /foo/a/aaa等，看起来也是一个路径，但是在对象存储里并没有对应的数据结构，它就是一个字符串。

从用户的角度看，数据都存进去了。甚至我们在对象存储的控制台里，也能看到文件夹的概念，还能一层一层点进去，这是桌面工具通过这种路径风格的 key 帮助我们做的转换，提供了一个接近本地文件系统使用的用户体验，它其实和对象存储原生的目录结构是不一样的。其差异会体现在哪？

举一个例子。我们要将最顶层的附文件夹改名为 bar。

在 Linux操作里，我写的 Shell 的指令 mv /foo /bar，在文件系统里执行之后，因为有原生目录的数据结构，所以每一层目录之间是一个类似链表的结构。我修改顶层 /foo的目录名，就是一个原子操作，只要找到目录对应的数据结构，将其中的名字改掉即可。所以是原子操作，瞬间完成，也不会影响到数据的一致性。

但是在对象存储里，我们这些对象之间没有数据结构的关联，所以每一个对象都是独立的。我们要想把 /foo的根目录改名，实际上在对象存储里就是要找到所有以 /foo为前缀的 key 对应的对象，这意味着我们要对所有的对象做一次搜索。

在对象存储内部的实现里，它通常会对所有的 key 做一个索引。为了方便我们做查找，将 /foo开头的所有 key 都找出来了，可能是几个、几万个，也可能几百万个。

做改名的时候，根据对象存储自己的设计架构，key 的名字通常会通过哈希算法指定 key 对应的数据要被存放在哪一个节点上，这意味着key 的名字只要改变，数据会被重新分配到另一个存储节点上，所以不能直接对 key 做改名的。

在对象存储里，要想执行 rename 操作，通常需要先做全局的搜索把需要的对象都找出来，做一次数据拷贝，再用新的名字复制一份新的数据出来。假设我们有几万个对象命中，则需要对它们用新名字拷贝一遍。有了上图中右边这一列，同时还要更新 key 的索引，其后再删掉所有旧的 key 和数据。

结合上述所言即可知道一个简单的 rename要分为几个步骤，而且在各步骤之间没有事务保障，需要一步一步地执行完成。一来有可能在中间失败；二来如果在这个过程中，有其他的进程访问数据，得到的结果也是中间状态，也就是说数据没有强一致性保障。客户端可能得到了中间状态的数据，会给上层应用带来一些正确性和稳定性的影响。这也是面向对象存储编程时需要特别注意的。

当然，我们去看 S3标准API 是没有 rename 这样的 API 的，S3 的设计是希望我们的数据一次写进来，要么保留，要么删掉，不会做更新。这也是与文件系统的不同。所以如果我们的数据是需要一次写入，多次访问，只读，甚至可能是通过CDN 要做分发，是非常适合对象存储的一个场景。

如果你的数据需要经常更新，需要读取目录中所有文件做分析训练，比如在大数据和 AI 的这些场景里，对象存储的设计是不适合这些业务场景的，文件存储会更加适合。

文件存储的发展

下文介绍一下文件存储的发展过程，文件存储的发展比对象存储要早得多。在最早的时候，大概在上世纪八九十年代的时候就有了最初的文件存储产品，当时是硬件一体机的形态。今天我们知道有 EMC、NetAPP 这样的品牌，它们都用软硬一体机提供 NAS 产品。但这是为了局域网而设计的，一般就是十几台、几十台机器共享数据。这是当时时代的需求，一般都不能扩展到很大规模，而且整体成本比较高。这一代 NAS 产品都是 POSIX 兼容的。但是到了互联网时代，该种方案太过昂贵，而且扩展能力不够。所以出现了第一代软件定义存储产品，非常著名的项目有大数据生态里的HDFS，也有兼容 POSIX 标准的 Ceph 等产品。软件定义的好处是我们可以用 x86、ARM 等标准硬件，集群扩展性也提高了很多。但是这一代分布式文件系统产品也是为机房设计的，部署、维护一套存储系统的复杂度仍然不低，尤其是大规模存储系统，不是每一个团队都有精力和能力。到移动互联网时代，公有云发布了对象存储，最初是 S3，发布于2006年，流行起来大概是在2010年，也就是智能手机在快速发展的时间。我们的数据量在飞速的爆发，其中最核心的一个场景即存储用户生产的数据，比如音频、视频，通过APP上传，再通过CDN分发给更多的人看。该场景如上述所说非常适合使用S3。因为对象存储在设计时，它锁定了三个核心能力：1.高可用性；2.很强的扩展性；3.低成本。

在上述三个能力之下，它也牺牲了一些其他能力，比如文件系统的语义丰富度，在 S3中做了大幅的裁剪，满足UGC需求是完全没问题的，不过后来因为成本低，扩展能力强，用户在云上的大数据和 AI 等场景，大家也希望能够用这样的存储服务，但也逐渐发现了对象存储在这些复杂的计算分析场景上的不足。我们自己也是遇到了 S3在复杂计算场景上的不足，到 2016、2017 年有了构思一个新产品的想法。JuiceFS 也是在 2017 年开始，我们希望能够为云环境设计一个新的分布式文件系统。

分布式文件存储

上文提到的第一代软件定义的分布式文件系统，此处列了一个列表，现在有一半以上仍然在大量使用，比如GPFS已经是一九九几年的项目了。像Google、阿里巴巴、Meta 的项目都是内部的。Lustre、Ceph、HDFS 这些仍然有很多的用户在用。大家也能看到这里有很多通用的软件系统都是基于 POSIX设计的，也有个别的如HDFS甚至包括 Meta、Google 内部的系统，都没有兼容POSIX，需要用专门的 SDK 开发应用。

云上文件系统要如何设计？

在云上去设计的时候，我们应该如何做？第一，需要适合云的环境，最佳的体验是与对象存储提供相同的体验，它应该是一个全托管的服务。第二，具备对象存储高可用、弹性、低成本的优势。它应该是 Region 级的高可用，也即跨同城机房的高可用。它必须是弹性伸缩的，不应该再像上一代文件系统那样需要规划容量，手工做扩容，这些操作在云上都不应该有。而且到今天除了兼容 POSIX 之外，还需要适合 Kubernetes 环境，比如要符合 CSI 标准。在设计的时候，为云环境设计就要充分地借助云环境上提供的基础设施。同时我们也要为云设计一个功能完整的文件系统，不用使用特殊的接口和 API。下面是 JuiceFS 社区版的架构图。可以看到有 3 个虚线框，是文件系统的三个主要组成部分。左下角 Metadata Engine 是元数据引擎，它主要负责存储文件系统的元信息，即文件名、目录树、属性、时间戳。在社区版里，我们选择使用已经开源的十几款不同的数据库，都可以做JuiceFS的 Metadata Engine，能兼容十几个不同的存储引擎，就是为了让大家可以易上手、选择熟悉的、会用的。另一方面，文件系统的应用场景也非常广泛，不同的场景里对规模、性能、成本有不同的要求。所以不同的存储引擎其实也有不同的特点，我们可以结合使用需求，结合自己的经验去选择一个存储引擎，比如Redis、MySQL、TiKV 都是可以的。上图右下角 Data Storage 是我们的数据持久层，也是真正存储文件内容里的组件。在云上设计的时候，我们选择借助云上已经成熟可靠的对象存储来做持久层。因为上一代存储都是面向裸硬盘设计，在云上我们就把对象存储服务看成一个无限容量的硬盘。左边的 Metadata Engine 相当于分区表，在两者的配合下，就可以形成一个文件系统管理数据了。所以也可以看到 JuiceFS 社区版本身是一个客户端，它自己没有其他的 Service 。上面的客户端功能很丰富，它提供了多种访问方式的支持，比如可以用POSIX，是基于用户态 FUSE 挂载的方式，也有 Hadoop 生态的 Java SDK，它能提供 HDFS API 的100%兼容。在 Kubernetes 里也提供了 CSI Driver，还有兼容 S3 API的Gateway，甚至还包括像 WebDAV、NFS 这些，也都可以兼容。这样就带来一个好处。以前我们可能会因为应用生态的不同选择了不同的访问协议的存储系统。今天JuiceFS 可以把它们统一起来，做成统一存储。以前我们为不同的存储系统的 API 开发的那些程序也都不用改，任何代码都可以对接到JuiceFS上来，这样可以给现有的系统提供巨大便利。在此过程中，我们最初是为大数据和 AI 这些重计算、重分析的场景设计的，所以我们也内建了缓存加速的能力。所有的数据访问，第一次是从远端的对象存储去读数据，然后可以缓存到自己的客户端所在节点的 SSD 上。下一次访问这份数据可以缓存命中，不用再经过网络远程访问数据，这样可以大幅地提升在存储计算分离架构下的计算、训练的性能。JuiceFS 项目目前开源满两年，已经有很多的社区用户在使用了，大家如果有这方面的需求，欢迎试用。同时在云上也提供了我们商业版的服务，会帮助客户运维好。以往在应用系统的监控里，往往只能看到是I/O 瓶颈还是 CPU 瓶颈，如果是 I/O 瓶颈，只能看到 QPS、时延和吞吐几个指标，很难再进行深入的分析。为云环境设计系统的时候，我们认为 JuiceFS 的观测性是一个非常重要的能力。所以我们也提供了一些帮助用户提升观测性的工具。它可以做到跟踪上层应用，看到访问存储系统时的每一个详细的系统调用，包括每一个 open、write、stat 等API 都会记录到详细的日志里，可以跟踪时间开销、是否命中缓存等信息。这些日志收集下来以后，便可很容易地看到在存储系统内部的 I/O 特征是什么样的，可以帮助我们结合其他系统的监控，更精准地定位到系统问题，帮助用户做 tracing，这在大数据和 AI 系统里也是一项非常重要的能力。有可能我们的系统和监控系统结合起来。最后分享下JuiceFS 的一些使用场景。我们看到用户在自己的大数据和 AI 平台中，往往会维护多套的存储系统，可能 NAS、对象存储，可能还有HDFS，为了AI 训练场景的 Lustre 或者GPFS这样的并行文件系统，多套系统上接了很多应用，不同的系统之间也需要做很多数据的同步、迁移、转换。我们希望 JuiceFS能够简化整个流程，将上面这样的复杂数据流变成下面这样的一个架构。JuiceFS 可以作为统一的数据存储，无论是数仓、半结构化数据，或者像图片、声音这些非结构化数据都可以存在里面，将数据引擎都对接进来。在这样的理念下，我们现在的社区中已经有了很多的实践。在这里我举一些例子。比如：

• 云之声，他们是做声音领域的一家AI 科技企业，他们在自己的超算平台里使用 JuiceFS，替代了以前 Ceph的使用，解决大量小文件的管理，同时简化了运维投入。

• 乾象投资是一家快速成长的量化私募基金，他们将自己的量化策略研究构建在云上，JuiceFS 为弹性算力提供了足够的吞吐能力，尤其是访问热点数据所需的吞吐。
• 深势科技是一家做 AI for Science，为新药研发领域服务的科技企业，他们也会利用JuiceFS 去做多云上面的存储统一。
• 理想汽车把他们新能源汽车的数据分析平台，由原来的 HDFS 迁移到JuiceFS上使用，可以使其在云上更方便地扩展，支持业务的快速成长。
• 一面数据是隶属于英国的一家传媒公司旗下的针对电商快消领域分析咨询的公司。他们会关注全网的电商数据，所以数据平台于他们而言是非常重要的一个环节。最初是在机房里建设数据平台，后来借助JuiceFS 帮助他们平滑地迁移、上云，转变为混合云架构，算力继续使用机房资源，存储构建在云上，数据平台也变为存储计算分离架构，更容易做扩缩容，让自己的资源利用率也更加的灵活高效。
• 东南亚的电商Shopee，他们使用JuiceFS实现了 ClickHouse 的数据冷热分层存储，在用户无感的情况下实现了客观的成本优化。

• 火山引擎把JuiceFS 用在了自己边缘云上。

大家能看到JuiceFS作为文件系统有非常丰富的使用场景，在大数据和 AI 场景中是比较聚焦的一部分，在其他的方面也有很多可以探索的场景。这也是我们在设计上将 JuiceFS 的几个部分做了充分的解耦，并且支持了很多更丰富的对象存储、更丰富的存储引擎的初衷。相关更多的实践经验，感兴趣的朋友可以访问网址，我们进一步交流：https://juicefs.com/zh-cn/blog/user-stories。

｜嘉宾介绍｜

苏锐

JuiceFS 社区Juicedata 合伙人

作为 1 号成员参与创建 JuiceFS，一直深度参与在开源社区中支持开发者使用 JuiceFS。

如果您想投稿或想要讨论更多，欢迎在后台输入关键词“投稿”，联系我们。