JuiceFS：雲原生時代的分佈式文件系統

文章作者：蘇銳 Juicedata 合夥人

內容來源：Juicedata

在這張幻燈中，我列出了過去 40 年文件存儲的產品形態和架構設計的變化，自上世紀 80 年代一直到 2000 年左右，也就是從局域網的普及到互聯網的普及，文件存儲都是由專業廠商提供軟硬件一體的產品，這類產品都依賴專有硬件，擴展性有限。所以到 21 世紀初，隨着寬帶網絡的普及，Web2.0 時代的到來，UGC 數據（User Generated Content）爆發，整個互聯網的數據呈指數增長，大家第一次開始面對 “大數據” 這個概念，當時 Google 的一篇論文「Google File System」提供了大數據存儲的一種思路，然後有了一個開源實現 HDFS，也是今天大數據領域最流行的分佈式文件系統。同時也出現了 Ceph、MooseFS 等不同思路的分佈式文件系統，這些項目的重要意義在於它們第一次基於普通、標準的 x86 硬件，使用純軟件的方式將成百上千臺機器管理起來，成爲一套存儲系統。

直到 2006 年，Amazon 發佈了第一個雲服務 S3（Simple Storage Service），正如它的名字，S3 具備兩個非常重要的特點：簡單 & 服務。首先，S3 簡化了 File System 的能力，僅提供非常簡單的數據結構（Key-Value）和訪問接口，同時 S3 也是第一次把數據存儲作爲一種 “服務” 提供給用戶，大家不用再操心擴容、監控、數據維護等工作。在此之前，大家從來沒有想象過這樣的體驗。S3 發佈的時間同時也是移動互聯網出現的時間，這樣便捷的服務正好滿足了移動互聯網時代數據規模進一步爆發帶來的存儲需求。

S3 提供的 Key-Value 類型現在都叫做 對象存儲，它簡化了文件系統中數據與數據之間的組織結構，這種簡單的組織方式可以很好滿足 UGC 數據的需求，用戶上傳數據，服務進行存儲，然後交給 CDN 網絡分發。但是放到大數據分析，機器學習訓練，還有很多行業對數據處理的需求中，對象存儲並不適合。因爲對象存儲爲了滿足高可用、高擴展性、價格便宜的需要，簡化了數據結構，原來文件系統的一些訪問接口也就無法原生實現，雖然有模擬行爲的接口，但是會帶來性能大幅下降、數據一致性下降等問題。隨着數據規模的增加，管理員想對一個對象存儲 Bucket 中的數據做管理、維護等工作的難度都是巨大的。

上面提到的這些對象存儲面臨的問題，正是文件系統擅長的，所以我們從 2017 年開始探索雲原生文件系統的方向，有了 JuiceFS 這個項目。起初我們學習 S3 的方法，在全球所有公有云上提供 JuiceFS 文件存儲服務，在經過業務驗證、場景打磨，收穫幾十個互聯網行業客戶之後，讓我們對 JuiceFS 有了非常堅定的信心。同時，JuiceFS 作爲一種新的產品形態和體驗，爲了讓更多開發者可以瞭解和探索，建設一個開源社區一定是可以讓更多開發者受益的方式。

一方面雲原生架構提供了很多設計理念，一方面我們也更關注用戶在自己的業務場景中遇到的痛點和對應的需求，比如希望存儲系統服務化，可以彈性伸縮，在海量數據面前對人、對程序同樣友好，如何支持 Hadoop 生態、OLAP 產品等實現存儲計算分離。同時簡單、可靠、高性能、低成本當然也是一個文件存儲服務必須具備的。

接下來第二部分介紹 JuiceFS 的設計目標和架構。

在考慮 JuiceFS 設計目標的時候，我們再重新分析一下對象存儲的優劣勢。正如上圖左邊列出的，優勢在 JuiceFS 中應該都繼承，然後結合業務場景的需求，針對性的解決對象存儲的劣勢。這裏我們提出了幾個重點能力：

  1. 數據強一致性，這是文件系統必須的；

  2. 高性能元數據，解決對象存儲在計算、分析場景中的痛點；

  3. 多訪問協議互通，包括 POSIX、HDFS、S3，其實 POSIX 是最久經考驗，生態豐富的文件訪問接口，但是考慮到已有的 Hadoop 生態和基於 S3 API 開發的程序，JuiceFS 需要提供一個平滑對接的體驗纔好，不要讓開發者改代碼；

  4. 小文件管理能力，無論在大數據場景還是 AI 訓練場景，十億、百億甚至千億文件的管理需求被越來越多的提起。在實際的生產環境中，也已經有客戶使用 JuiceFS 管理數十億的文件了。

  5. Kubernetes 友好，這是雲原生時代最重要的用戶體驗，JuiceFS 必須支持，而且必須支持的很好。

基於這些設計目標再來看看架構設計的思路。在分佈式文件系統中有核心三要素：元數據、數據、客戶端。在 Google File System（GFS）的論文中給出了一個簡單經典的設計。大家看下圖，系統從頂層架構角度看分爲三大塊，用 GFS 和 HDFS 做個比較，GFS Master 對應 HDFS NameNode，GFS ChunkServer 對應 HDFS DataNode，然後都有一個 Client 負責程序和存儲系統交互。

下面是 JuiceFS 的架構設計，可以看出來系統也分爲三個部分，這裏 JuiceFS 做個兩個很重要的創新。

首先，架構圖下面的對象存儲對應 ChunkServer 和 DataNode 的角色，是 JuiceFS 的存儲層。JuiceFS 沒有再重新設計一個數據存儲層，而是藉助了已經被廣泛使用的對象存儲技術，這樣選擇是因爲對於數據存儲層（ChunkServer）的需求核心是擴展性、持久性安全、低成本，這幾點剛好是對象存儲的優勢，無論在公有云還是私有云都能找到成熟、可靠的對象存儲產品。所以 JuiceFS 選擇站在對象存儲的肩膀上來構建文件系統，而不是重複造輪子。

第二個創新是元數據管理，JuiceFS 在元數據管理上做了分析和抽象之後，明確了管理元數據的引擎所需要的能力，包括數據結構、事務能力、效率、擴展性和成本等。在這些方面找到一個簡單、可靠、都滿足的引擎並不容易，結合業務需求看往往也是可以取捨的，所以 JuiceFS 計劃做支持多引擎的元數據管理服務。目前社區版選用了 Redis，因爲它有合適的數據類型支持、事務能力、高效等優勢，而且最重要的是它已經被廣大開發者熟悉和信任，把它作爲 JuiceFS 的元數據存儲引擎，學習門檻就很低了。當然 Redis 也有自身的侷限，JuiceFS 已經在社區中計劃推出第二、第三款元數據引擎。

第三點講客戶端，在架構圖的右上方。這裏麪包含了很多核心工作來實現文件系統各方面的能力。比如 GFS 和 HDFS 都是隻能追加數據，不能修改數據，對象存儲也存在同樣的不足。JuiceFS 的目標則是做一個提供全功能的文件系統，要支持隨機讀寫，很多的工作都是在客戶端裏實現的。今天的分享不展開講，有興趣的朋友請關注我們後續的分享，也可以在 GitHub 關注項目直接看代碼 ；）

下面講講我們和客戶交流中遇到的幾個普遍存在於雲原生環境中的業務挑戰。

再看看 Kubernetes 和存儲的關係。現在 Kubernetes 已經成爲了越來越多業務的資源管理和部署管理的基礎，也是雲原生環境中的基礎。當 Spark 資源調度和管理遷移到 Kubernetes，當 Presto 查詢引擎的管理遷移到 Kubernetes，當 AI 平臺整體遷移到 Kubernetes，當大量的有狀態應用要遷移到 Kubernetes，都要和數據打交道，都需要一個可靠的存儲服務，文件存儲一定是最普遍適用的方案。在 Kubernetes 中也有 PersistentVolume 和 CSI 驅動的定義來讓存儲以合適的方式在 Kubernetes 中使用。

這裏我舉一個業務邊界融合的例子 - AI 平臺。AI 平臺分爲多個環節，每個環節都在和數據打交道，實際上就是一個 Data Pipeline，在過去的 AI 平臺中，每個業務環節都按照自己的數據處理需求選擇存儲系統，從下圖可以看出，在整個 Pipeline 中會涉及到多套存儲系統，這樣一來數據就要在不同業務環境上搬來搬去，同時還要運維多套系統，複雜度很高，工程效率低下。

如果能將不同的存儲系統統一起來是什麼樣子呢？JuiceFS 作爲共享文件存儲服務支持整個 Pipeline 中所有業務環節的需要，運維一套系統，數據不用搬家，學習和使用門檻低，效率提升。

我今天的分享就到這裏，謝謝大家！歡迎各位到 GitHub 上關注 JuiceFS。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/IwoPTa2C2IWLUrqU6uYoTA

猜你喜歡