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

[本文来自：www.ii77.com]

[原文来自：www.ii77.com]

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

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

JuiceFS 的立异架构更相符云原生的成长趋势，我们一起头就以 SaaS 的形式将它供应给公有云的客户，让客户分钟级就能够获得 PB 级企业文件存储办事。同时，我们也和行业精良的对象存储厂商一路办事私有云客户。

2020年2月份，Davies 曾在接管 TGO 采访时聊起了一路开办 Juicedata 的故事。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 经由对文件系统中元数据和数据的自力抽象，大大减低了系统复杂度，使得文件系统可以借助这些年来对象存储和分布式数据库的进展，治理超大规模的数据。同时，复杂度的降低能够让更多的斥地者介入进来，将来更多的应用也会竖立在文件系统接口之上。

团队将经由开源社区的互相协作，一方面为各个应用供应更好的存储支撑，也会在底层存储引擎和对象存储上加深协作，一路鞭策文件存储的快速成长，打造将来数据生态的坚韧底座。