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

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

　　今天的介紹會圍繞下面四點展開：

　　文件存儲的發(fā)展

　　云時代的痛點與挑戰(zhàn)

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

　　JuiceFS 的使用場景

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

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

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

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

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

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

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

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

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

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

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

　　4. 云原生時代

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

　　02 云時代的痛點與挑戰(zhàn)

　　1. 各代文件存儲的特性

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

　　2. 軟硬件一體 NAS

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

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

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

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

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

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

　　4. 對象存儲

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

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

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

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

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

　　接下來我們再展開看一下對象存儲和文件系統(tǒng)的幾個區(qū)別。

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

　　POSIX

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

　　HDFS

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

　　HDFS 經(jīng)過十幾年的發(fā)展已經(jīng)成為 Hadoop 領(lǐng)域的一個默認(rèn)標(biāo)準(zhǔn)，但其實在其他領(lǐng)域并沒有得到廣泛的應(yīng)用，就是因為 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)和開放，但是同時也意味著它和現(xiàn)有的應(yīng)用程序是完全不能兼容的，每一個應(yīng)用都需要面向它做對接適配或者針對性的開發(fā)。S3 本身提供了很多語言的 SDK 方便開發(fā)者使用，也誕生了一些第三方項目，其中最著名的是 S3FS 和 Goofys。這兩個項目都是支持將 S3 的 Bucket 掛載到系統(tǒng)里，像訪問本地盤一樣讀寫數(shù)據(jù)，現(xiàn)在各個公有云上也有提供針對自己對象存儲的一些類似方案。

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

　　7. Rename 的行為差異

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

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

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

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

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

　　8. 最終一致性

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

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

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

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

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

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

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

　　(1)多場景，多維度

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

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

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

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

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

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

　　插件式引擎

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

　　Simple is better

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

　　3. 關(guān)鍵能力

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

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

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

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

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

　　5. 整體架構(gòu)

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

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

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

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

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

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

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

　　S3 Gateway：輸出一個 S3 的 End point 去對接 S3 的 API

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

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

　　7. JuiceFS 的可觀測性

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

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

　　04 JuiceFS 的使用場景

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

　　1. Kubernetes

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

　　2. AI

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

　　3. Big Data

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

　　4. NAS Migration to Cloud

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