历时四年，分布式文件系统JuiceFS正式开源

作者 InfoQ编辑部

云原生分布式文件系统JuiceFS正式开源

1月11日，Juicedata果汁数据科技官方账号宣布JuiceFS 正式开源，这是一个云原生分布式文件系统，经过了四年的持续迭代和累计几千万小时的线上考验。Davies （刘洪清，Juicedata创始人、TGO鲲鹏会会员）在文中表示：

GitHub地址：https://github.com/juicedata/juicefs

2020年2月份，Davies曾在接受TGO采访时聊起了一路创办Juicedata的故事（可阅读：《离开Facebook与百万美元后，他的技术故事才刚刚开始 | TGO深焦》）。Davies在清华硕士毕业后即加入豆瓣成为早期员工，并研发了国内最早的开源KV存储Beansdb和DPark （ Python clone of Spark ）;2013年他加入Facebook总部负责HDFS方面的研发，2014年加入Databricks，帮助Spark SQL实现了上百倍的性能提升。2017年，似乎是顺利成章，在大数据领域摸爬滚打了近十年的Davies，开始了与几个伙伴的创业之旅。

“创业太艰难了，对一个团队的要求太全面了。你不能犯任何错误，要竭尽全力，然后要借助所有可能借助的力量，还要借助偶然的机遇才可能成功……（我）觉得这个事情是非常难的，还是不要创业。”

话虽如此，但创业似乎对Davies有种奇妙的吸引力。

在他长达13年的职业生涯中，居然有近12年身在创业企业。2016年，正是在硅谷创业企业Databricks任职期间，他萌生了创业的想法。

时值Davies负责为Databricks的存储层提速，虽然AWS已有相关的存储方案，但问题很多，且迟迟无法解决。于是，他提议，自研新的存储方案，系统性地解决问题。

不过，在当时的Databricks，从架构师到管理层，几乎全部认为风险太大，无人支持Davies的提议。Davies说：“当时，CTO （注：Matei Zaharia, Apache Spark作者）亲口对我说：‘存储这不是我们擅长的事情，能不碰尽量不要碰。'“

在Databricks否决Davies的技术方案后，大概Matei Zaharia也没有想到，这个中国来的工程师颇有“美式英雄主义”精神。他不但没有放弃，反而用业余时间单枪匹马地写了个原型出来。之后，Davies回忆道：“我找了一些朋友的公司去试用，发现效果也可以，所以我在想既然有这么不错的东西，就不能埋没它。”

2017年，Davies在美国远程敲定了国内的投资和早期客户，叫上当时也在创业的苏锐，共同创立了Juicedata，并将产品命名为JuiceFS。

经过了四年的历练，整个团队最终决定将JuiceFS正式开源。Davies表示：在创业之初，我们认为SaaS可以为用户提供最佳的体验，同时让我们更快地迭代产品，决定优先把SaaS做好。经过4年的持续迭代和积累，JuiceFS已经在几十家科技企业的大数据、AI、容器平台、归档、备份等场景中形成最佳实践，SaaS使用量也持续快速增长，并且在过去的2020年首次实现了盈亏平衡。我们相信找到了可持续发展的模式，有信心保障JuiceFS的长期运营。

此外，Davies等人也发现闭源的基础软件会限制使用者对它的深度理解，不利于服务更多人，依靠SaaS产品的收入支撑和开源社区的力量或许可以让JuiceFS走得更远。

为什么我们需要新的文件系统？

文件系统是计算机中一个非常重要的组件，为存储设备提供一致的访问和管理方式。在不同的操作系统中，文件系统会有一些差别，但也有一些共性几十年都没怎么变化：

·数据是以文件的形式存在，提供Open、Read、Write、Seek、Close等API进行访问；

· 文件以树形目录进行组织，提供原子的重命名（Rename）操作改变文件或者目录的位置。

文件系统提供的访问和管理方法支撑了绝大部分的计算机应用，Unix的“万物皆文件”的理念更是凸显了它的重要地位。文件系统的复杂性使得它的可扩展性未能跟得上互联网的高速发展，极大简化了的对象存储及时填补了空缺得以快速发展起来。因为对象存储缺乏树状结构也不支持原子重命名操作，跟文件系统有很大的差别，本文暂不讨论。

绝大多数文件系统都是单机的，在单机操作系统内为一个或者多个存储设备提供访问和管理。随着互联网的高速发展，单机文件系统面临很多的挑战：

·共享：无法同时为分布在多个机器中的应用提供访问，于是有了NFS协议，可以将单机文件系统通过网络的方式同时提供给多个机器访问。

· 容量：无法提供足够空间来存储数据，数据只好分散在多个隔离的单机文件系统里。

· 性能：无法满足某些应用需要非常高的读写性能要求，应用只好做逻辑拆分同时读写多个文件系统。

· 可靠性：受限于单个机器的可靠性，机器故障可能导致数据丢失。

· 可用性：受限于单个操作系统的可用性，故障或者重启等运维操作会导致不可用。

· 随着互联网的高速发展，这些问题变得日益突出，涌现出了一些分布式文件系统来应对这些挑战。

如今，我们耳熟能详的分布式文件系统有GlusterFS、CephFS、GFS以及HDFS等，每种方案各有优劣（详细对比可阅读《分布式文件系统架构对比》一文）, JuiceFS与这些相比的差异性在于更加适合云原生的环境。

具体而言，GFS、HDFS和MooseFS都是针对自建机房这种软硬件环境设计的，将数据的可靠性和节点可用性合在一起用多机多副本的方式解决。但是在公有云或者私有云的虚拟机里，块设备已经是具有三副本可靠性设计的虚拟块设备，如果再通过多机多副本的方式来做，会导致数据的成本居高不下（实际上是9个拷贝）。

于是，整个团队针对公有云，改进HDFS和MooseFS的架构，设计了JuiceFS，架构如下图所示：

JuiceFS使用公有云中已有的对象存储来替换DataNode和ChunkServer，实现一个完全弹性的Serverless的存储系统。公有云的对象存储已经很好地解决了大规模数据的安全高效存储，JuiceFS只需要专注元数据的管理，也大大降低了元数据服务的复杂度（GFS和MooseFS的master要同时解决元数据的存储和数据块的健康管理）。团队也对元数据部分做了很多改进，从一开始就实现了基于Raft的高可用。要真正提供一个高可用高性能的服务，元数据的管理和运维仍然是很有挑战的，元数据是以服务的形式提供给用户。因为POSIX文件系统API是应用最最广泛的API，团队基于FUSE实现了高度POSIX兼容的客户端，用户可以通过一个命令行工具把JuiceFS挂载到Linux或者macOS中，像本地文件系统一样快速访问。

上图中右边虚线部分是负责数据存储和访问的部分，涉及用户的数据隐私，它们是完全在客户自己的账号和网络环境中，不会跟元数据服务接触。Juicedata没有任何方法接触到客户的内容（元数据除外，请不要把敏感内容放到文件名里）。

上图中蓝色项目主要是给大数据场景使用的，实现的是POSIX的子集，而绿色的则是POSIX兼容的文件系统。

他们中以GFS为代表的元数据和数据分离的系统设计能够有效平衡系统的复杂度，有效解决大规模数据的存储问题（通常也都是大文件），有更好的可扩展性。这个架构下支持元数据的分布式存储的Colossus和WarmStorage更是具有无限的可扩展能力。

JuiceFS作为后来者，学习了MooseFS实现分布式POSIX文件系统的方式，也学习了Facebook的WarmStorage等元数据和数据彻底分开的思路，希望为公有云或者私有云等场景下提供最好的分布式存储体验。JuiceFS通过将数据存储到对象存储的方式，有效避免了使用以上分布式文件系统时的双层冗余（块存储的冗余和分布式系统的多机冗余）导致的成本过高问题。JuiceFS还支持所有的公有云，不用担心某个云服务锁定，还能平滑地在公有云或者区之间迁移数据。

为开源做好准备，架构再升级

借助对象存储的帮助，JuiceFS已经大大降低了分布式文件系统的复杂度，元数据管理是它最核心的问题。JuiceFS的SaaS使用的元数据引擎，是专为文件系统打造的数据库，整个团队已经积累了丰富的运维经验，仍然如履薄冰。如果开源的话，让社区用户自己运维仍然会是一个大的挑战和负担，一旦运维失误导致数据丢失，后果非常严重。

带着这个问题，团队将元数据服务改造为支持多引擎的插件式架构，可以利用已有的开源数据库实现元数据存储。这样可以更灵活地适应不同场景，根据场景的规模、性能和成本需求，选用不同的元数据实现。这是JuiceFS的架构再升级，为未来的发展翻开新的篇章。

至于为什么选用Redis作为第一个开源存储引擎，是因为该引擎：

·是全内存的，可以满足元数据的低延时和高IOPS要求；

·支持乐观事务，能够满足文件系统元数据操作的原子性要求；

· 有丰富的数据结构，易于实现文件系统的诸多API；

· 有着非常广泛的社区和成熟的生态，运维Redis不会是一个问题；

· 在各个云上都有托管的服务，在云上使用会更简单；

未来，团队还会增加SQL数据库、TiKV等支持事务的KV数据库支持。

未来规划

最近几年，数据库领域发生了一件有趣的事情：当NoSQL数据库在满足了数据的快速增长后，它在一致性、访问便捷性和管理能力方面的不足逐渐显露，把这些复杂性转嫁到了业务系统和运维上，开始被人诟病。同时，SQL数据库也有了长足的进展，已经能够满足现在的数据规模需求，经过全面的对比分析后，大家又在回归SQL数据库，曾经的NoSQL运动也逐渐显出颓势。

估计类似的事情也会发生在非结构数据领域。对象存储在媒体文件等场景取得了巨大的成功，但当人们以为它就是未来的存储形态，开始推广到更大范围时，它牺牲掉的树形目录结构、可修改性、元数据性能、一致性等等，变成了一只只拦路虎，影响它在其他场景的使用效果。

团队坚信文件系统是最好的管理非结构化数据的方式，对象存储只适用于某些简单场景。分布式文件系统一直是基础软件中难啃的骨头，JuiceFS通过对文件系统中元数据和数据的独立抽象，大大减低了系统复杂度，使得文件系统能够借助这些年来对象存储和分布式数据库的进展，管理超大规模的数据。同时，复杂度的降低可以让更多的开发者参与进来，未来更多的应用也会建立在文件系统接口之上。

团队将通过开源社区的相互协作，一方面为各个应用提供更好的存储支持，也会在底层存储引擎和对象存储上加深协作，一起推动文件存储的快速发展，打造未来数据生态的坚实底座。

消息来源：

https://mp.weixin.qq.com/s/asUFtorMB1pcOwhNvlDyKw