文件系統的發展趨勢與JuiceFS的云上實踐

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

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

　　文件存儲的發展

　　云時代的痛點與挑戰

　　JuiceFS 的設計哲學

　　JuiceFS 的使用場景

　　01 文件存儲的發展

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

　　1. 局域網時代

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

　　2. 互聯網時代

　　2005 年之后，寬帶互聯網在全球范圍內普及，互聯網時代到來了。Web2.0的發展速度非�？�，由第一代互聯網那種簡單呈現消息的門戶網站轉變成了一個所有用戶都可以在網絡上互動的產品形態，出現了像社交網絡這樣的產品。整個互聯網產生的數據爆發式增長，這樣的趨勢也就導致像局域網時代一樣去買硬件的存儲柜已經跟不上網絡時代數據增長的發展了。因為買硬件的柜子會涉及到選型、采購、到貨、上架這樣一個很長的流程，需要做很嚴謹的容量規劃。

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

　　第一代軟件定義存儲的產品像 HDFS 和 CephFS，以及 AI 流行以后的 Lustre 仍然在被很多公司在不同范圍內使用。這些產品在發展過程中面對的新的挑戰就是移動互聯網的出現。

　　3. 移動互聯網時代

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

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

　　4. 云原生時代

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

　　02 云時代的痛點與挑戰

　　1. 各代文件存儲的特性

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

　　2. 軟硬件一體 NAS

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

　　當時這一套軟硬一體 NAS 有一個最大的優勢就是它是 POSIX 兼容的，學習成本很低，對用戶而言就和使用 Linux 本地盤的體驗是一樣的。這就意味著開發上層應用的時候是非常簡單的，無論直接通過系統調用還是通過各種語言的框架去開發都是 POSIX 兼容的，會很方便。

　　3. 第一代軟件定義分布式文件系統

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

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

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

　　4. 對象存儲

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

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

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

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

　　5. 對象存儲與文件系統的區別

　　接下來我們再展開看一下對象存儲和文件系統的幾個區別。

　　6. 訪問接口的數量

　　POSIX

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

　　HDFS

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

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

　　S3

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

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

　　7. Rename 的行為差異

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

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

　　如果此時要執行一個 Rename 操作，把 /foo 這個目錄名改成 /bar，因為文件系統是樹形的數據結構，所以它就能找到這個目錄名對應的 Inode 去執行一個原子的更新，把 foo 替換成 Bar。

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

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

　　8. 最終一致性

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

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

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

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

　　03 JuiceFS 的設計哲學

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

　　1. JuiceFS 的設計目標

　　(1)多場景，多維度

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

　　2. 架構的設計選擇

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

　　完全為云環境設計

　　元數據與數據分離

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

　　插件式引擎

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

　　Simple is better

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

　　3. 關鍵能力

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

　　前面提到 POSIX 協議以及 HDFS 和 S3 各自的標準，雖然 POSIX 是一個訪問接口上的最大集，但經過這些年的發展后，如今 Hadoop 生態中面向 HDFS 開發的組件非常之多，S3 經過十幾年的發展面向它 API 開發的應用也非常多。這三個是今天市面上最流行的訪問標準，因此最理想的情況是在一個文件系統上能夠對外輸出三種不同標準的 API 的訪問能力，這樣已有的這些程序就都可以直接對接進來，新的應用也可以選擇更適合的訪問協議進行開發。

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

　　4. JuiceFS 的架構設計

　　現在讓我們來看一下最終的設計，左邊是 High Level 的架構圖，右邊是數據存取的結構圖。

　　5. 整體架構

　　架構圖能體現出我們插件式的設計，這里有三個大的虛線框分別表示分布式文件系統里的三大組件：左下角的元數據引擎，右下角的數據引擎以及上方的訪問客戶端。元數據引擎，數據引擎和客戶端三個組件都是插件式的設計，開發者可以結合具體應用和自己熟悉的技術棧去做選擇。

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

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

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

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

　　Java SDK：服務于 Hadoop 生態，完全兼容 HDFS API

　　CSI Driver：在 Kubernetes 的環境里面可以用 CSI 的方式訪問

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

　　6. 數據存儲

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

　　7. JuiceFS 的可觀測性

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

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

　　04 JuiceFS 的使用場景

　　最后來分享一下 JuiceFS 社區中用戶最常應用的一些場景。

　　1. Kubernetes

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

　　2. AI

　　因為 JuiceFS 提供了多訪問協議的支持，所以在 AI 場景中很長的 Pipeline 上的各個環節都可以很方便的使用。JuiceFS 還提供了透明的緩存加速能力，可以很好的支持數據清洗、訓練、推理這些環節，也支持了像 Fluid 這樣的 Kubernetes 里面 AI 調度的框架。

　　3. Big Data

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

　　4. NAS Migration to Cloud

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