文件系統(tǒng)的發(fā)展趨勢(shì)與JuiceFS的云上實(shí)踐

　　導(dǎo)讀：JuiceFS 是一個(gè)為云環(huán)境而設(shè)計(jì)的分布式文件系統(tǒng)，在 2021 年初開源后，過去一年在開源社區(qū)里發(fā)展很快，也受到了很多關(guān)注。本次分享希望讓大家了解 JuiceFS 的設(shè)計(jì)背景、設(shè)計(jì)理念，以及它能夠?yàn)殚_發(fā)者帶來的幫助和價(jià)值。

　　今天的介紹會(huì)圍繞下面四點(diǎn)展開：

　　文件存儲(chǔ)的發(fā)展

　　云時(shí)代的痛點(diǎn)與挑戰(zhàn)

　　JuiceFS 的設(shè)計(jì)哲學(xué)

　　JuiceFS 的使用場(chǎng)景

　　01 文件存儲(chǔ)的發(fā)展

　　首先我們回顧一下文件存儲(chǔ)的發(fā)展歷程。

　　1. 局域網(wǎng)時(shí)代

　　2005 年之前還是一個(gè)以局域網(wǎng)為主的階段，互聯(lián)網(wǎng)才剛剛開始。這個(gè)時(shí)期的分布式文件系統(tǒng)或者說文件存儲(chǔ)大部分是軟硬一體的產(chǎn)品，我們能在市場(chǎng)上看到 NetApp、EMC 還有華為的一些存儲(chǔ)柜子。這些產(chǎn)品給很多用戶留下了一個(gè)印象，那就是存儲(chǔ)實(shí)際上就是買硬件，買一個(gè)存儲(chǔ)的柜子就搞定了。

　　2. 互聯(lián)網(wǎng)時(shí)代

　　2005 年之后，寬帶互聯(lián)網(wǎng)在全球范圍內(nèi)普及，互聯(lián)網(wǎng)時(shí)代到來了。Web2.0的發(fā)展速度非�？�，由第一代互聯(lián)網(wǎng)那種簡(jiǎn)單呈現(xiàn)消息的門戶網(wǎng)站轉(zhuǎn)變成了一個(gè)所有用戶都可以在網(wǎng)絡(luò)上互動(dòng)的產(chǎn)品形態(tài)，出現(xiàn)了像社交網(wǎng)絡(luò)這樣的產(chǎn)品。整個(gè)互聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)爆發(fā)式增長(zhǎng)，這樣的趨勢(shì)也就導(dǎo)致像局域網(wǎng)時(shí)代一樣去買硬件的存儲(chǔ)柜已經(jīng)跟不上網(wǎng)絡(luò)時(shí)代數(shù)據(jù)增長(zhǎng)的發(fā)展了。因?yàn)橘I硬件的柜子會(huì)涉及到選型、采購、到貨、上架這樣一個(gè)很長(zhǎng)的流程，需要做很嚴(yán)謹(jǐn)?shù)娜萘恳?guī)劃。

　　就在這個(gè)時(shí)間點(diǎn)上 Google 提出了他們的 Google File System 的論文，同時(shí)在技術(shù)社區(qū)里面出現(xiàn)了第一代純軟件定義存儲(chǔ)的分布式文件系統(tǒng)產(chǎn)品。大家熟知的像大數(shù)據(jù)領(lǐng)域的 HDFS，已經(jīng)被紅帽收購的 CephFS、GlusterFS，還有當(dāng)時(shí)面向 HPC 場(chǎng)景的 Lustre、BeeGFS 這些產(chǎn)品都是在 2005 年到 2009 年這樣一個(gè)很短的時(shí)間窗口內(nèi)誕生的。這也就意味著這些產(chǎn)品都有一個(gè)共同的時(shí)代背景以及面向當(dāng)時(shí)硬件環(huán)境的設(shè)計(jì)，比如說當(dāng)時(shí)還沒有云的存在，所有的這些分布式文件系統(tǒng)都是面向機(jī)房里的物理機(jī)設(shè)計(jì)的。而當(dāng)時(shí)的機(jī)房環(huán)境和今天最大的區(qū)別就是網(wǎng)絡(luò)環(huán)境，當(dāng)時(shí)機(jī)房里面是以百兆網(wǎng)卡為主的，如今機(jī)房里面基本都是萬兆網(wǎng)卡了，這些給我們的軟件設(shè)計(jì)和 IT 基礎(chǔ)架構(gòu)的設(shè)計(jì)帶來了很多的改變。

　　第一代軟件定義存儲(chǔ)的產(chǎn)品像 HDFS 和 CephFS，以及 AI 流行以后的 Lustre 仍然在被很多公司在不同范圍內(nèi)使用。這些產(chǎn)品在發(fā)展過程中面對(duì)的新的挑戰(zhàn)就是移動(dòng)互聯(lián)網(wǎng)的出現(xiàn)。

　　3. 移動(dòng)互聯(lián)網(wǎng)時(shí)代

　　2010 年之后的十年時(shí)間，移動(dòng)互聯(lián)網(wǎng)相比 Web2.0 最大的變化就是以前人們只能坐在電腦前使用網(wǎng)絡(luò)產(chǎn)生數(shù)據(jù)，而到了移動(dòng)互聯(lián)網(wǎng)時(shí)代，每個(gè)人每天醒著的時(shí)候都可以使用手機(jī)來產(chǎn)生數(shù)據(jù)，這就意味著整個(gè)互聯(lián)網(wǎng)上數(shù)據(jù)的增長(zhǎng)速度又快了一兩個(gè)數(shù)量級(jí)。

　　第一代面向機(jī)房，用軟件搭建分布式存儲(chǔ)和分布式系統(tǒng)的方案在移動(dòng)互聯(lián)網(wǎng)時(shí)代也遇到了挑戰(zhàn)，這也就讓公有云應(yīng)運(yùn)而生。最早的像 AWS 就是在 2006 年發(fā)布了第一個(gè)產(chǎn)品 S3，在當(dāng)時(shí)都還沒有整個(gè)公有云的體系，沒有 EC2 這樣的計(jì)算環(huán)境，只有一個(gè)存儲(chǔ)服務(wù) S3。S3 就是想簡(jiǎn)化之前人們自己搭建機(jī)房，采購硬件然后通過軟件去搭建分布式系統(tǒng)這個(gè)復(fù)雜的過程。對(duì)象存儲(chǔ)在移動(dòng)互聯(lián)網(wǎng)時(shí)代有了一個(gè)非�？焖俚陌l(fā)展，它的誕生是為了解決之前分布式文件系統(tǒng)的一些問題，但也導(dǎo)致犧牲了一些能力，這個(gè)我們后面會(huì)再展開講。

　　4. 云原生時(shí)代

　　在移動(dòng)互聯(lián)網(wǎng)蓬勃發(fā)展之后，現(xiàn)在又迎來了物聯(lián)網(wǎng)的發(fā)展，這對(duì)存儲(chǔ)的規(guī)模、易管理性和擴(kuò)展能力等各方面都有了一個(gè)全新的要求。當(dāng)我們回顧公有云時(shí)會(huì)發(fā)現(xiàn)缺少一個(gè)非常適合云環(huán)境的分布式文件系統(tǒng)，直接將上一時(shí)代的 HDFS、CephFS、Lustre 這樣的產(chǎn)品放到公有云上又不能體現(xiàn)出云的優(yōu)勢(shì)。

　　02 云時(shí)代的痛點(diǎn)與挑戰(zhàn)

　　1. 各代文件存儲(chǔ)的特性

　　下圖展示了這四個(gè)時(shí)代對(duì)應(yīng)的存儲(chǔ)產(chǎn)品的特點(diǎn)，以今天的視角回看，其中紅字是每代產(chǎn)品中存在的問題，綠字是其好的特性。

　　2. 軟硬件一體 NAS

　　第一代硬件產(chǎn)品在當(dāng)時(shí)都是采用專有的硬件，擴(kuò)容并不方便，因?yàn)榧嫒輪栴}無法將不同廠商的硬件對(duì)接到一起使用。并且當(dāng)時(shí)這一代軟硬一體 NAS 也缺少高可用，大部分采取主從互備的方式。對(duì)于今天更大負(fù)載，更大規(guī)模的系統(tǒng)主從互備的可用性是不夠的。此外，還存在整體成本較高的問題，因?yàn)樾枰獙ｉT的硬件，網(wǎng)絡(luò)環(huán)境和相匹配的維護(hù)能力。

　　當(dāng)時(shí)這一套軟硬一體 NAS 有一個(gè)最大的優(yōu)勢(shì)就是它是 POSIX 兼容的，學(xué)習(xí)成本很低，對(duì)用戶而言就和使用 Linux 本地盤的體驗(yàn)是一樣的。這就意味著開發(fā)上層應(yīng)用的時(shí)候是非常簡(jiǎn)單的，無論直接通過系統(tǒng)調(diào)用還是通過各種語言的框架去開發(fā)都是 POSIX 兼容的，會(huì)很方便。

　　3. 第一代軟件定義分布式文件系統(tǒng)

　　到了互聯(lián)網(wǎng)時(shí)代，第一代軟件定義分布式文件系統(tǒng)包括 HDFS、CephFS 不再依賴于專有硬件，都是用標(biāo)準(zhǔn)的 X86 機(jī)器就可以搞定了。相比第一代軟硬一體的擴(kuò)展性有所提高，但是和后來的云存儲(chǔ)相比還是不易擴(kuò)展，能看到像 CephFS、HDFS 也都有一些單集群的上限，這是在當(dāng)時(shí)的容量規(guī)模下進(jìn)行設(shè)計(jì)造就的局限。

　　此外仍然缺少高可用的設(shè)計(jì)，大部分依舊采用主從互備，這樣一來仍然要為機(jī)房獨(dú)立的采購硬件，研究、維護(hù)大規(guī)模的分布式系統(tǒng)，因此整體的 TCO 還是相對(duì)較高的。同時(shí)相比上個(gè)時(shí)代對(duì)于運(yùn)維的挑戰(zhàn)更高了，因?yàn)椴淮嬖趶S商的服務(wù)了，需要自己構(gòu)建一套運(yùn)維團(tuán)隊(duì)，擁有足夠的運(yùn)維能力，深入掌握這套開源的文件系統(tǒng)。

　　好在像 CephFS、Lustre 這些仍然是 POSIX 兼容的，而 HDFS 為了滿足大數(shù)據(jù) Hadoop 生態(tài)架構(gòu)提出了一套新的存儲(chǔ)接口 HDFS API。如果詳細(xì)的去分析這套 API 能發(fā)現(xiàn)它其實(shí)是 POSIX 的一個(gè)子集，假設(shè)說 POSIX 有 200 個(gè)接口，到 HDFS 大概就剩下一半。從文件系統(tǒng)的功能上來看，它是對(duì)一個(gè)完整的文件系統(tǒng)做了一些裁剪，比如 HDFS 是 Append Only 的文件系統(tǒng)，也就是只能寫新數(shù)據(jù)、追加文件，而不能對(duì)已有的文件做覆蓋寫。這是當(dāng)時(shí) HDFS 為了實(shí)現(xiàn)更大規(guī)模數(shù)據(jù)的存儲(chǔ)而犧牲掉的一部分文件系統(tǒng)語義上的能力。

　　4. 對(duì)象存儲(chǔ)

　　對(duì)象存儲(chǔ)相比之前的文件系統(tǒng)提出了三個(gè)核心的能力：易擴(kuò)展、高可用和低成本。在這三個(gè)核心能力的基礎(chǔ)上提出要實(shí)現(xiàn)服務(wù)化，即用戶不再需要投入任何成本在搭建、運(yùn)維、擴(kuò)容這些事情上了;此外還提出作為一個(gè)云服務(wù)要能裝下足夠海量的數(shù)據(jù)。

　　但是與此同時(shí)也犧牲了很多文件系統(tǒng)原生支持的能力。

　　第一是接口少了。對(duì)象存儲(chǔ)提供的 API 往往是 HDFS 的一個(gè)子集，相比 POSIX 能提供的能力就更少了。前面舉例說假如 POSIX 有 200 個(gè) API，那到 HDFS 可能只有 100 個(gè)了，到 S3 的時(shí)候大概只剩 20-30 個(gè)了。

　　第二是元數(shù)據(jù)操作性能下降了。對(duì)象存儲(chǔ)本身并不是為那些需要操作復(fù)雜元數(shù)據(jù)的應(yīng)用設(shè)計(jì)的，最開始設(shè)計(jì)對(duì)象存儲(chǔ)只是想實(shí)現(xiàn)數(shù)據(jù)上傳再通過 CDN 進(jìn)行分發(fā)這樣一個(gè)簡(jiǎn)單的業(yè)務(wù)模型。最初S3里的接口其實(shí)只有 PUT、GET 和 DELETE，后來又衍生出了 LIST、HEAD，但能看到像 RENAME、MV 這些在文件系統(tǒng)里很常見的操作至今對(duì)象存儲(chǔ)都是不支持的。

　　5. 對(duì)象存儲(chǔ)與文件系統(tǒng)的區(qū)別

　　接下來我們?cè)僬归_看一下對(duì)象存儲(chǔ)和文件系統(tǒng)的幾個(gè)區(qū)別。

　　6. 訪問接口的數(shù)量

　　POSIX

　　POSIX 協(xié)議已經(jīng)內(nèi)置到 Linux 操作系統(tǒng)的內(nèi)核里了，可以通過系統(tǒng)調(diào)用直接訪問一個(gè) POSIX 兼容的存儲(chǔ)系統(tǒng)，Open、Write、Read 這些標(biāo)準(zhǔn)的接口也已經(jīng)內(nèi)置到各個(gè)編程語言里面了。在 POSIX 之上構(gòu)建出來的應(yīng)用生態(tài)從 Linux 開始流行到現(xiàn)在至少有三十年的時(shí)間了，再基于 POSIX 標(biāo)準(zhǔn)去做全新的文件系統(tǒng)上層應(yīng)用不需要做任何的適配修改，也不需要提供任何特殊的 SDK，各個(gè)語言都是可以直接訪問的。

　　HDFS

　　HDFS 是一個(gè)只能追加的文件系統(tǒng)。它提供了一套自己的 SDK，比如說有大家熟知的用在 Hadoop 里面的 Java SDK。但這給上層的應(yīng)用開發(fā)帶來了一些新的挑戰(zhàn)，即原來的程序是沒辦法直接使用 HDFS 的，必須在跟文件系統(tǒng)打交道這一層去做替換。替換的過程中就要去考慮接口之間是不是一一對(duì)應(yīng)的，不對(duì)應(yīng)的時(shí)候用什么方式能構(gòu)建平滑的映射關(guān)系。

　　HDFS 經(jīng)過十幾年的發(fā)展已經(jīng)成為 Hadoop 領(lǐng)域的一個(gè)默認(rèn)標(biāo)準(zhǔn)，但其實(shí)在其他領(lǐng)域并沒有得到廣泛的應(yīng)用，就是因?yàn)?HDFS 有著一套自己的 API 標(biāo)準(zhǔn)。HDFS 今天最成熟的還是用在 Hadoop 體系里面的 Java SDK。而其他的像 C、C++、Python、Golang 這些語言的 SDK 成熟度都還不夠，包括通過 FUSE、WebDAV、NFS 這些訪問 HDFS 的方式也不是很成熟，所以至今 HDFS 主要還只停留在 Hadoop 體系內(nèi)去使用。

　　S3

　　S3 最開始是基于 HTTP 協(xié)議提供了一套 RESTful API，好處是更加的標(biāo)準(zhǔn)和開放，但是同時(shí)也意味著它和現(xiàn)有的應(yīng)用程序是完全不能兼容的，每一個(gè)應(yīng)用都需要面向它做對(duì)接適配或者針對(duì)性的開發(fā)。S3 本身提供了很多語言的 SDK 方便開發(fā)者使用，也誕生了一些第三方項(xiàng)目，其中最著名的是 S3FS 和 Goofys。這兩個(gè)項(xiàng)目都是支持將 S3 的 Bucket 掛載到系統(tǒng)里，像訪問本地盤一樣讀寫數(shù)據(jù)，現(xiàn)在各個(gè)公有云上也有提供針對(duì)自己對(duì)象存儲(chǔ)的一些類似方案。

　　雖然這些能夠?qū)崿F(xiàn)把 Bucket 掛載到操作系統(tǒng)里，但是無法提供的是數(shù)據(jù)強(qiáng)一致性的保證，然后是高性能的 Listing，以前在本地盤里列目錄是一個(gè)很輕量的動(dòng)作，但是在對(duì)象存儲(chǔ)的 Bucket 里去列目錄性能代價(jià)是很高的。此外，對(duì)象存儲(chǔ)也還沒有支持原子的 Rename 和對(duì)文件進(jìn)行隨機(jī)寫。POSIX 兼容的文件系統(tǒng)里是有 API 支持對(duì)文件的隨機(jī)寫的，打開一個(gè)文件然后 Seek 指定的偏移量去更新它的內(nèi)容。但是在對(duì)象存儲(chǔ)上面要想實(shí)現(xiàn)對(duì)數(shù)據(jù)或者說對(duì)文件的局部進(jìn)行更新，唯一能做的就是先將文件完整的下載到本地，更新其中需要修改的那一部分?jǐn)?shù)據(jù)，再把這個(gè)文件完整的上傳回對(duì)象存儲(chǔ)里面。整個(gè)隨機(jī)寫的操作代價(jià)是非常大的，無法支持需要隨機(jī)寫的應(yīng)用。

　　7. Rename 的行為差異

　　現(xiàn)在 S3 原生的 API 里仍然沒有 Rename，官方 SDK 和很多第三方工具的確提供了這個(gè)功能，比如通過 Goofys 或者 S3FS 把 Bucket 掛載到機(jī)器上再執(zhí)行 Rename。但這里的 Rename 和文件系統(tǒng)原生的 Rename 是有差別的，這里舉一個(gè)例子。

　　左邊模擬文件系統(tǒng)，這是一個(gè)樹形結(jié)構(gòu)的目錄樹。而對(duì)象存儲(chǔ)是不存在原生的樹形結(jié)構(gòu)的，它會(huì)通過設(shè)置對(duì)象的 Key 值(對(duì)象名)來模擬出一個(gè)路徑，實(shí)際上對(duì)象存儲(chǔ)里面的數(shù)據(jù)結(jié)構(gòu)是扁平的，即右邊這樣的結(jié)構(gòu)。

　　如果此時(shí)要執(zhí)行一個(gè) Rename 操作，把 /foo 這個(gè)目錄名改成 /bar，因?yàn)槲募�系統(tǒng)是樹形的數(shù)據(jù)結(jié)構(gòu)，所以它就能找到這個(gè)目錄名對(duì)應(yīng)的 Inode 去執(zhí)行一個(gè)原子的更新，把 foo 替換成 Bar。

　　因?yàn)閷?duì)象存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)是扁平的，所以需要在對(duì)象存儲(chǔ)里對(duì)這個(gè) Key 的索引去做一次搜索，找到所有以 foo 為前綴的對(duì)象，可能是 1 個(gè)也可能是 100 萬個(gè)。搜索出來以后要將這些對(duì)象進(jìn)行一次 lO 拷貝，用新的名字作為 Key 值復(fù)制一遍，復(fù)制之后再更新相關(guān)的索引信息同時(shí)刪掉舊的對(duì)象。

　　能看到這是一個(gè)比較長(zhǎng)的操作過程，要先搜索對(duì)象，然后拷貝，再更新索引，整個(gè)過程其實(shí)是沒有事務(wù)去保證的，有可能會(huì)出現(xiàn)一致性問題。目前大部分的對(duì)象存儲(chǔ)會(huì)保證最終一致性，只有少數(shù)的對(duì)象存儲(chǔ)會(huì)在自己原生的 API 里面保證強(qiáng)一致性，但是在第三方工具做的像 Rename 這樣的衍生 API 里仍然只是保證最終一致性。

　　8. 最終一致性

　　這里再通過一個(gè)例子來解釋最終一致性以及它可能對(duì)應(yīng)用造成的影響。

　　這里畫了一副漫畫，講了老奶奶的一只貓跑到了樹上，她想請(qǐng)這個(gè)小朋友幫她救貓，小朋友說沒問題，我?guī)湍惆沿埬没貋�。大家可以看到他居然從另外一個(gè)畫面里把貓給取了出來，老奶奶很疑惑，為什么樹上和小朋友手里各有一只貓?小朋友說這只是一個(gè) SYNC 的問題，你再去 Check 一下就好了，老奶奶再往樹上看的時(shí)候樹上的貓已經(jīng)不見了。這里其實(shí)就體現(xiàn)了前面講的 Rename 的過程，即在一個(gè)很長(zhǎng)的流程里數(shù)據(jù)沒有保持完整的一致性狀態(tài)。

　　對(duì)應(yīng)的命令在左邊，首先列了一下這個(gè) Bucket 的目錄，發(fā)現(xiàn)有一個(gè)文件 cat.txt，將它 MV 到新的目錄，換完目錄之后看到原來的這個(gè)目錄里面還有這個(gè)cat.txt，而新的目錄里也有了一個(gè) cat.txt，此時(shí)看到了兩只貓，這看起來就不像是 MV 的操作了。但其實(shí)這是一個(gè) SYNC 狀態(tài)的問題，可能過了一會(huì)再去原來的舊目錄里查看文件就會(huì)發(fā)現(xiàn) cat.txt 不見了，在操作過程中去觀察時(shí)數(shù)據(jù)狀態(tài)還沒有一致，但是系統(tǒng)會(huì)保證最終是一致的狀態(tài)。而如果上層的應(yīng)用在數(shù)據(jù)狀態(tài)不一致的時(shí)候就已經(jīng)去依賴它來進(jìn)行下一步操作的話，那應(yīng)用可能就會(huì)出錯(cuò)了。

　　這里舉了幾個(gè)例子來說明雖然今天對(duì)象存儲(chǔ)是能夠給我們提供優(yōu)秀的擴(kuò)展性、低廉的成本和便捷的使用方式，但是當(dāng)我們需要對(duì)數(shù)據(jù)進(jìn)行更復(fù)雜的分析、計(jì)算操作時(shí)對(duì)象存儲(chǔ)仍然會(huì)給我們帶來一些不方便的地方，比如說接口很少、需要針對(duì)性的開發(fā)、元數(shù)據(jù)的性能差。以前在文件系統(tǒng)里很輕量的操作，在對(duì)象存儲(chǔ)里可能會(huì)變得很復(fù)雜;此外還可能會(huì)引入一些一致性的問題，對(duì)數(shù)據(jù)精確性要求很高的場(chǎng)景就不適合了。

　　03 JuiceFS 的設(shè)計(jì)哲學(xué)

　　從軟硬一體到第一代軟件定義文件系統(tǒng)再到 S3 各有各的優(yōu)缺點(diǎn)，所以今天當(dāng)我們?cè)谠频沫h(huán)境里面去看的時(shí)候會(huì)發(fā)覺缺少一個(gè)非常完善，非常適合云環(huán)境又能很好的支持大數(shù)據(jù)、AI 還有一些新興的海量數(shù)據(jù)處理或者密集計(jì)算這些場(chǎng)景的文件系統(tǒng)產(chǎn)品，既可以讓開發(fā)者非常容易的使用又有足夠的能力去應(yīng)對(duì)這些業(yè)務(wù)上的挑戰(zhàn)，這就是我們?cè)O(shè)計(jì) JuiceFS 的初衷。

　　1. JuiceFS 的設(shè)計(jì)目標(biāo)

　　(1)多場(chǎng)景，多維度

　　前面分析了當(dāng)前市面上的場(chǎng)景，當(dāng)我們想去為云環(huán)境設(shè)計(jì) JuiceFS 這個(gè)產(chǎn)品的時(shí)候，我們開始考慮自己的設(shè)計(jì)目標(biāo)，要比較前面這些產(chǎn)品的一些優(yōu)劣勢(shì)和它們的設(shè)計(jì)思路，同時(shí)也要更多的關(guān)注用戶業(yè)務(wù)場(chǎng)景的需求。文件系統(tǒng)是在整個(gè) IT 基礎(chǔ)架構(gòu)中非常底層的產(chǎn)品，使用它的場(chǎng)景會(huì)非常的豐富，在不同的場(chǎng)景里對(duì)文件系統(tǒng)本身的規(guī)模、擴(kuò)展性、可用性、性能、共享的訪問能力以及成本甚至還有很多維度的要求都是不一樣的，我們要做的是云環(huán)境通用型產(chǎn)品，就需要在這個(gè)矩陣上去做取舍。

　　2. 架構(gòu)的設(shè)計(jì)選擇

　　在多場(chǎng)景、多維度的前提下做架構(gòu)設(shè)計(jì)時(shí)有幾個(gè)宏觀的方向是我們非常堅(jiān)持的：

　　完全為云環(huán)境設(shè)計(jì)

　　元數(shù)據(jù)與數(shù)據(jù)分離

　　這種設(shè)計(jì)會(huì)為我們?cè)诙鄨?chǎng)景多維度上去做取舍的時(shí)候帶來更多的靈活性。像 HDFS 是元數(shù)據(jù)和數(shù)據(jù)分離的方案，而 CephFS 就更像是元數(shù)據(jù)和數(shù)據(jù)一體的方案。

　　插件式引擎

　　我們提出把 JuiceFS 設(shè)計(jì)成一種插件式的引擎，讓數(shù)據(jù)管理、元數(shù)據(jù)管理包括客戶端都能提供一種插件式的能力，讓用戶結(jié)合自己的場(chǎng)景去做不同維度上插件的選擇，來拼插出一個(gè)最適合自身業(yè)務(wù)場(chǎng)景需求的產(chǎn)品。

　　Simple is better

　　我們一直堅(jiān)持 Linux 的一個(gè)最基本的設(shè)計(jì)哲學(xué)“Simple is better”，要盡可能的保持簡(jiǎn)單，一個(gè)基礎(chǔ)設(shè)施產(chǎn)品只有足夠簡(jiǎn)單才能做的足夠健壯，才能給用戶提供一個(gè)易維護(hù)的使用體驗(yàn)。

　　3. 關(guān)鍵能力

　　再細(xì)化一層到 JuiceFS 產(chǎn)品設(shè)計(jì)的關(guān)鍵能力上，我們提出在運(yùn)維上做服務(wù)化，像 S3 一樣使用，不需要用戶自己維護(hù);能支持多云，而非針對(duì)某一個(gè)云或者某一種環(huán)境設(shè)計(jì)，要在公有云、私有云、混合云的環(huán)境里都能用;支持彈性伸縮，不需要手動(dòng)擴(kuò)容縮容;盡可能做到高可用、高吞吐和低時(shí)延。

　　前面提到 POSIX 協(xié)議以及 HDFS 和 S3 各自的標(biāo)準(zhǔn)，雖然 POSIX 是一個(gè)訪問接口上的最大集，但經(jīng)過這些年的發(fā)展后，如今 Hadoop 生態(tài)中面向 HDFS 開發(fā)的組件非常之多，S3 經(jīng)過十幾年的發(fā)展面向它 API 開發(fā)的應(yīng)用也非常多。這三個(gè)是今天市面上最流行的訪問標(biāo)準(zhǔn)，因此最理想的情況是在一個(gè)文件系統(tǒng)上能夠?qū)ν廨敵鋈�種不同標(biāo)準(zhǔn)的 API 的訪問能力，這樣已有的這些程序就都可以直接對(duì)接進(jìn)來，新的應(yīng)用也可以選擇更適合的訪問協(xié)議進(jìn)行開發(fā)。

　　強(qiáng)一致性是文件系統(tǒng)必備的能力，最終一致性是不能被接受的;還有海量小文件的管理，這是上一代文件系統(tǒng)普遍都沒有解決的問題，因?yàn)樵谏弦淮�的時(shí)間點(diǎn)上根本不存在海量小文件的場(chǎng)景，而今天我們看到在 AI 的領(lǐng)域里面，管理海量小文件逐漸變?yōu)榛�礎(chǔ)需求。比如說在自動(dòng)駕駛、人臉識(shí)別、聲文分析這些場(chǎng)景里面大家都在面對(duì)著十幾億，數(shù)十億甚至上百億的文件，而又沒有一個(gè)文件系統(tǒng)能夠應(yīng)對(duì)這樣的規(guī)模，我們?cè)O(shè)計(jì) JuiceFS 就要解決這個(gè)核心問題。后面還包括用透明的緩存做加速，盡量保持低成本這些也都在我們的設(shè)計(jì)目標(biāo)里。

　　4. JuiceFS 的架構(gòu)設(shè)計(jì)

　　現(xiàn)在讓我們來看一下最終的設(shè)計(jì)，左邊是 High Level 的架構(gòu)圖，右邊是數(shù)據(jù)存取的結(jié)構(gòu)圖。

　　5. 整體架構(gòu)

　　架構(gòu)圖能體現(xiàn)出我們插件式的設(shè)計(jì)，這里有三個(gè)大的虛線框分別表示分布式文件系統(tǒng)里的三大組件：左下角的元數(shù)據(jù)引擎，右下角的數(shù)據(jù)引擎以及上方的訪問客戶端。元數(shù)據(jù)引擎，數(shù)據(jù)引擎和客戶端三個(gè)組件都是插件式的設(shè)計(jì)，開發(fā)者可以結(jié)合具體應(yīng)用和自己熟悉的技術(shù)棧去做選擇。

　　在元數(shù)據(jù)引擎上用戶可以選擇市面上最流行的開源數(shù)據(jù)庫包括 Redis、MySQL、PostgreSQL、TiKV，最近還支持了單機(jī)的 SQLite、BadgerDB 和 Kubernetes 上大家比較熟悉的 ETCD，還包括我們目前正在自研的一個(gè)內(nèi)存引擎，總共已經(jīng)支持了 9-10 款不同的存儲(chǔ)引擎能夠去管理 JuiceFS 的元數(shù)據(jù)。這樣設(shè)計(jì)一是為了降低學(xué)習(xí)成本和使用門檻，二是可以方便用戶結(jié)合具體場(chǎng)景對(duì)數(shù)據(jù)規(guī)模、性能、持久性、安全性的要求去做取舍。

　　數(shù)據(jù)引擎是用來存取數(shù)據(jù)文件的，我們兼容了市場(chǎng)上所有的對(duì)象存儲(chǔ)服務(wù)。回顧上一代的分布式文件系統(tǒng)，HDFS 里有 Datanode，CephFS 里有 RADOS，幾乎每一個(gè)文件系統(tǒng)都做了一件共同的事情就是把大量的裸機(jī)節(jié)點(diǎn)里的磁盤通過一個(gè)服務(wù)管理好，包括數(shù)據(jù)內(nèi)容和數(shù)據(jù)副本。當(dāng)我們考慮為云環(huán)境設(shè)計(jì)的時(shí)候就發(fā)現(xiàn)公有云上的對(duì)象存儲(chǔ)已經(jīng)能把數(shù)據(jù)管理做的非常完美了，它有足夠強(qiáng)的擴(kuò)展性，足夠低的成本，足夠安全的能力。所以我們?cè)谠O(shè)計(jì) JuiceFS 的時(shí)候就不再自己去做數(shù)據(jù)管理而是完全交給對(duì)象存儲(chǔ)來做。無論是公有云私有云還是一些開源項(xiàng)目提供的，我們認(rèn)為它們都是高可用，安全和低成本的。

　　上方的虛線框代表了 JuiceFS 的客戶端，其中最底層這個(gè)是 JuiceFS 客戶端里面的一個(gè) Core Lib，負(fù)責(zé)與元數(shù)據(jù)引擎和數(shù)據(jù)引擎通信，并面向應(yīng)用輸出四種不同的訪問方式：

　　FUSE：百分之百兼容 POSIX，通過 LTP 和 pjd-fstest 測(cè)試

　　Java SDK：服務(wù)于 Hadoop 生態(tài)，完全兼容 HDFS API

　　CSI Driver：在 Kubernetes 的環(huán)境里面可以用 CSI 的方式訪問

　　S3 Gateway：輸出一個(gè) S3 的 End point 去對(duì)接 S3 的 API

　　6. 數(shù)據(jù)存儲(chǔ)

　　右側(cè)的圖說明了我們是如何利用對(duì)象存儲(chǔ)做數(shù)據(jù)持久化的。類似 HDFS，一個(gè)文件通過 JuiceFS 寫到對(duì)象存儲(chǔ)里時(shí)會(huì)被切割，默認(rèn)是每 4M 為一個(gè)數(shù)據(jù)塊存到對(duì)象存儲(chǔ)里。這樣切割的好處是可以提高讀寫的并發(fā)度，提升性能，這是在原來的對(duì)象存儲(chǔ)里很難做到的。數(shù)據(jù)切割也有助于我們實(shí)現(xiàn)一個(gè)機(jī)制，即寫到對(duì)象存儲(chǔ)中的所有數(shù)據(jù)塊只新增不修改。當(dāng)需要對(duì)數(shù)據(jù)做覆蓋寫的時(shí)候，會(huì)把覆蓋寫的內(nèi)容作為一個(gè)新的數(shù)據(jù)塊寫到對(duì)象存儲(chǔ)里并同步更新元數(shù)據(jù)引擎，這樣的話就可以讀到新數(shù)據(jù)但是又不用修改舊數(shù)據(jù)塊。這樣的設(shè)計(jì)既可以支持隨機(jī)寫又可以規(guī)避掉對(duì)象存儲(chǔ)的最終一致性問題，同時(shí)利用這個(gè)機(jī)制還可以為客戶端提供細(xì)粒度的本地緩存的能力。

　　7. JuiceFS 的可觀測(cè)性

　　我們?cè)O(shè)計(jì) JuiceFS 的時(shí)候還有一個(gè)很重要的目標(biāo)就是提升用戶體驗(yàn)。這里指的用戶既包括使用文件系統(tǒng)的開發(fā)者又包括維護(hù)文件系統(tǒng)的運(yùn)維和 SRE 同學(xué)。要做到好用好維護(hù)，我們就考慮提供在云原生設(shè)計(jì)中經(jīng)常提及的可觀測(cè)性。以往我們使用文件系統(tǒng)時(shí)認(rèn)為系統(tǒng)是快是慢更偏向于感性的判斷，很難看到非常詳細(xì)的數(shù)據(jù)。

　　而 JuiceFS 提供了可觀測(cè)性的能力，可以在客戶端里打開一個(gè)詳細(xì)的 accesslog，里面會(huì)輸出上層應(yīng)用訪問文件系統(tǒng)時(shí)所有操作的細(xì)節(jié)，包括所有對(duì)元數(shù)據(jù)的請(qǐng)求，所有數(shù)據(jù)訪問請(qǐng)求的細(xì)節(jié)以及消耗的時(shí)間。再通過一個(gè)工具將這些信息進(jìn)行匯總，就可以看到上層應(yīng)用運(yùn)行過程中與文件系統(tǒng)這一層是如何交互的。當(dāng)再遇到文件系統(tǒng)慢時(shí)，就可以很容易的分析出這個(gè)慢是什么原因造成的，是因?yàn)橛刑�多的隨機(jī)寫，還是因?yàn)槎嗑�程并發(fā)之間存在阻塞。這里我們提供了 CLI 工具，在我們公有云的云服務(wù)上還提供了一些基于 GUI 的可視化工具去做觀測(cè)，相信這樣的觀測(cè)能力對(duì)于上層應(yīng)用的開發(fā)以及對(duì)于文件系統(tǒng)本身的運(yùn)維都是很有幫助的。

　　04 JuiceFS 的使用場(chǎng)景

　　最后來分享一下 JuiceFS 社區(qū)中用戶最常應(yīng)用的一些場(chǎng)景。

　　1. Kubernetes

　　在 Kubernetes 里一些有狀態(tài)的應(yīng)用需要一個(gè)持久卷，這個(gè) PV 的選擇一直是 Kubernetes 社區(qū)里面用戶經(jīng)常討論的問題。以前大家可能會(huì)選擇 CephFS，但是帶來的挑戰(zhàn)就是運(yùn)維相對(duì)復(fù)雜，JuiceFS 希望給大家提供一個(gè)更易運(yùn)維的選項(xiàng)。

　　2. AI

　　因?yàn)?JuiceFS 提供了多訪問協(xié)議的支持，所以在 AI 場(chǎng)景中很長(zhǎng)的 Pipeline 上的各個(gè)環(huán)節(jié)都可以很方便的使用。JuiceFS 還提供了透明的緩存加速能力，可以很好的支持?jǐn)?shù)據(jù)清洗、訓(xùn)練、推理這些環(huán)節(jié)，也支持了像 Fluid 這樣的 Kubernetes 里面 AI 調(diào)度的框架。

　　3. Big Data

　　JuiceFS 有一個(gè)很重要的能力就是海量文件的管理能力，JuiceFS 就是為管理數(shù)十億文件的場(chǎng)景去做設(shè)計(jì)和優(yōu)化的。在大數(shù)據(jù)場(chǎng)景下，因?yàn)樗�完全兼�?HDFS API，所以老的系統(tǒng)無論是什么發(fā)行版都可以很平滑的遷移進(jìn)來。此外，在 Hadoop 體系外的很多MPP數(shù)據(jù)庫像 ClickHouse、Elasticsearch、TDengine 和 MatrixDB 作為新的數(shù)據(jù)查詢引擎，默認(rèn)設(shè)計(jì)是為了追求更高性能的寫入，需要配備 SSD 這樣的存儲(chǔ)磁盤。但是經(jīng)過長(zhǎng)時(shí)間的使用后，在大數(shù)據(jù)量下就能發(fā)現(xiàn)這些數(shù)據(jù)是有熱數(shù)據(jù)也有溫、冷數(shù)據(jù)的，我們希望能用更低成本的去存儲(chǔ)溫、冷數(shù)據(jù)。JuiceFS 就支持簡(jiǎn)單透明的存儲(chǔ)溫、冷數(shù)據(jù)，上層的數(shù)據(jù)庫引擎基本不需要做任何修改，可以直接通過配置文件對(duì)接進(jìn)來。

　　4. NAS Migration to Cloud

　　前面更多提到的是在互聯(lián)網(wǎng)行業(yè)中應(yīng)用較多的場(chǎng)景，而很多其他領(lǐng)域以往的行業(yè)應(yīng)用都是基于 NAS 構(gòu)建的，我們看到當(dāng)前的趨勢(shì)是這些行業(yè)都在向云環(huán)境遷移，借助云彈性的能力，利用更大規(guī)模的分布式環(huán)境去完成他們需要的諸如數(shù)據(jù)處理、仿真、計(jì)算這些場(chǎng)景。這里存在一個(gè)挑戰(zhàn)就是如何把原先機(jī)房里的 NAS 遷移到云上。無論是社區(qū)還是商業(yè)的客戶，JuiceFS 這邊都支持了從傳統(tǒng)的機(jī)房環(huán)境上云這樣一個(gè)遷移 NAS 的過程，我們已經(jīng)接觸過的有基因測(cè)序、藥物研究、遙感衛(wèi)星，甚至像 EDA 仿真、超算這些領(lǐng)域，他們都已經(jīng)借助 JuiceFS 實(shí)現(xiàn)了將機(jī)房中的 NAS 很平滑的上云。