HDFS 作為 Hadoop 提供儲存元件，已經成為大資料生態裡面資料儲存最常用的選擇，通常在機房環境部署。
JuiceFS 是一個基於物件儲存的分散式檔案系統，使用者可以在雲上快速地搭建按需擴容的彈性檔案系統。
如果企業正在考慮在雲上構建大資料平臺，瞭解這兩種產品的差異和優缺點，可以為企業遷移或切換儲存產品提供參考。這篇文章將從技術架構、功能特性、使用場景等多個方面來解析 HDFS 和 JuiceFS 的異同。
1. 架構
1.1 HDFS 架構
HDFS（Hadoop Distributed File System）是 Hadoop 生態系統中的分散式檔案系統。在 HDFS 的架構中，有兩種型別的節點：NameNode 和 DataNode。一個最簡單的 HDFS 叢集就是由一個 NameNode 和一組 DataNode 組成。
NameNode 是 HDFS 的後設資料管理節點，負責管理檔案系統的名稱空間和響應客戶端對檔案後設資料的請求（比如 create，open，rename，delete 等請求），同時， NameNode 也負責管理 DataNode 和資料塊的對映關係，維護所有檔案和目錄的層次結構，記錄檔案的名稱、檔案大小、檔案塊的位置等資訊。在生產環境使用時，HDFS 需要部署多個 NameNode 並結合 ZooKeeper 和 JournalNode 來實現高可用。
DataNode 是 HDFS 的資料儲存節點，負責儲存實際的資料。一個檔案會被分割成一個或多個檔案塊，每個 DataNode 節點儲存一部分資料塊，並向 NameNode 彙報儲存的塊的列表和狀態資訊。DataNode 節點處理客戶端的讀寫請求，向客戶端提供檔案塊的資料。
1.2 JuiceFS 架構
與 HDFS 不同，JuiceFS 社群版採用的是外掛化架構，JuiceFS 的檔案資料是被切分後並儲存在物件儲存（如 Amazon S3、MinIO）中，後設資料則儲存在使用者選擇的資料庫中，例如 Redis、TiKV、MySQL等。這種架構的設計使得 JuiceFS 可以透過共享同一個資料庫和物件儲存實現強一致性保證的分散式檔案系統。
JuiceFS 的後設資料管理是完全獨立於資料儲存的，這意味著 JuiceFS 可以支援大規模資料儲存和快速檔案系統操作，同時保持高可用性和資料的一致性。JuiceFS 提供了相容於 Hadoop 生態的 Java SDK，支援 HDFS 到 JuiceFS 的無縫切換，與此同時，JuiceFS 還提供了包括 POSIX、S3 Gateway、Kubernetes CSI Driver 等多種 API 和工具，使其易於整合到現有的應用程式中。
JuiceFS 企業版有著與社群版一致的技術架構，不同之處在於 JuiceFS 企業版面向對效能、可靠性和可用性要求更高的企業級使用者提供了一套自研的分散式後設資料儲存引擎。同時在社群版的基礎上提供了一系列高階功能，包括 Web 控制檯、快照、跨區資料複製、檔案系統映象等。
2. 基礎能力
這部分內容將對 HDFS 與 JuiceFS 的架構核心進行拆解，進一步對比它們在後設資料管理、資料管理以及訪問協議支援方面的特點和差異。
2.1 後設資料
2.1.1 後設資料儲存
HDFS 將後設資料儲存在記憶體中，使用 FsImage 和 EditLog 兩種技術來保證後設資料不丟失和重啟後快速恢復。
JuiceFS 社群版採用獨立的第三方資料庫來儲存後設資料，比如Redis、MySQL、TiKV等。截止本文釋出，JuiceFS 社群版支援三類共 10 種事務型資料庫。
JuiceFS 企業版採用自研的高效能後設資料儲存引擎，JuiceFS 企業版將後設資料儲存在記憶體中，透過 changelog 和 checkpoint （類似於 HDFS 的 EditLog 和 FsImage） 保證資料不丟失和重啟快速恢復。
2.1.2 後設資料記憶體消耗
HDFS 每個檔案的後設資料約佔用 300 位元組記憶體空間。
JuiceFS 社群版使用 Redis 作為後設資料引擎時，每個檔案的後設資料約佔用 300位元組 記憶體空間;
JuiceFS 企業版熱資料每個檔案的後設資料約佔用 300位元組 記憶體空間。JuiceFS 企業版支援記憶體壓縮，針對不常使用的冷資料，記憶體佔用可以降低到每個檔案 80位元組左右。
2.1.3 後設資料擴容
後設資料儲存是一個關鍵的元件，因為它包含了檔案系統中所有檔案和目錄的資訊。如果後設資料儲存的容量不足，那麼就會對檔案系統的效能和可靠性造成影響。
HDFS 可以採用聯邦的方式來解決單個NameNode的容量限制問題。聯邦中的每個 NameNode 是獨立的名稱空間，它們可以共享同一個DataNode 叢集來簡化管理。應用需要訪問指定的NameNode或者透過靜態配置的 ViewFS 來構成統一名稱空間，但垮NameNode 的操作都是不支援的。
JuiceFS 社群版使用第三方資料庫作為後設資料儲存，這些資料庫系統通常都有較為成熟的擴容方案，一般來說只需簡單的增加資料庫的容量或者新增資料庫的叢集節點即可實現儲存擴容。
JuiceFS 企業版也支援後設資料叢集的水平擴容，多個後設資料服務節點共同組成單一名稱空間，以支撐更大規模的資料和處理更多的訪問請求，進行橫向擴充套件時無需客戶端做任何修改。
2.1.4 後設資料操作
HDFS 對檔案路徑的解析是基於完整路徑的。HDFS 客戶端會將需要訪問的完整路徑直接傳送到 NameNode，因此，任何深度檔案的請求都只需要進行一 RPC 次呼叫。
JuiceFS 社群版基於 inode 進行檔案路徑訪問，根據檔案層級從根目錄開始逐層查詢，直到找到最終檔案。因此，根據檔案深度可能存在多次 RPC 呼叫。為了加速此過程，一些支援快速路徑解析的後設資料引擎，如 Redis，服務端能夠直接解析最終檔案。如果使用的資料庫不支援快速路徑解析，可以透過啟用後設資料快取來加速此過程。同時，啟用後設資料快取後，可以減輕後設資料服務的壓力。但是，啟用後設資料快取後會導致一致性語義有所改變，需要根據具體場景調節引數。
JuiceFS 企業版支援服務端路徑解析，請求任何深度的檔案都只需一次 RPC 呼叫即可。
2.1.5 後設資料快取
後設資料快取可以顯著提高檔案系統的效能和吞吐量，透過將最常用的檔案後設資料儲存在快取中，後設資料快取可以避免頻繁地從後設資料伺服器獲取後設資料，從而減少 RPC 呼叫，提高效能。
HDFS 不支援客戶端後設資料快取。
JuiceFS 社群版和企業版均支援在客戶端快取後設資料，以加速 open、list、getattr 等後設資料操作，降低後設資料服務的負載。
2.2 資料管理
2.2.1 資料儲存
HDFS 預設以 128M 的塊來儲存檔案，會在三個不同的 DataNode 上儲存每個資料塊的三個副本進行容錯，以此來保證儲存的可靠性，可以透過修改配置來調整副本數量。此外，HDFS 還支援糾刪碼（ Erasure Coding），一種高效的資料編碼技術，透過將資料塊切分成多個資料塊並編碼儲存來提供容錯機制。與副本相比，糾刪碼可以節省儲存空間，但會增加計算負載。
JuiceFS 則將資料拆分成 4M 的塊儲存在物件儲存中，同時為大資料場景引入了 128 M 的邏輯分塊用來做計算任務劃分。由於 JuiceFS 採用物件儲存作為資料儲存層，資料的可靠性取決於選用的物件儲存，一般的物件儲存服務會透過多副本複製、糾刪碼等技術為儲存的可靠性提供保證。
2.2.2 資料快取
HDFS 可以將指定資料快取在服務端 DataNode 的堆外記憶體中，從而來提高資料訪問的速度和效率。比如 Hive 場景下，可以將小表快取在 DataNode 記憶體中，提高 join 速度。
JuiceFS 的資料持久化層一般在物件儲存上，而物件儲存通常都有較高的基礎時延。為了解決這個問題，JuiceFS 提供了客戶端資料快取功能，透過將物件儲存上的資料塊快取在本地磁碟上，從而提高資料訪問的速度和效率。
JuiceFS 企業版除了基本的客戶端快取能力外，還提供了快取共享功能，多個客戶端可以組成快取叢集，共享本地快取。此外，JuiceFS 企業版還可以搭建獨立的快取叢集，為彈性伸縮的計算節點提供穩定的快取能力。
2.2.3 資料親和性
HDFS 為每個資料塊提供儲存位置資訊，可以被 YARN 等資源排程器用於實現親和性排程。
JuiceFS 支援使用本地磁碟快取來加速資料訪問。它透過預先設定的計算節點列表為每個資料塊計算生成偏好的位置資訊，讓 YARN 等資源排程器將同一個資料分配的計算排程到固定節點， 以提高快取資料的命中率。
JuiceFS 企業版還支援在多個計算節點之間共享資料快取，即使計算任務沒有排程到偏好的節點，也可以透過計算節點間的網路訪問其他節點上快取的資料。
3. 功能與特性
3.1 資料一致性
HDFS 和 JuiceFS 的後設資料都是保證強一致性的（CP系統），可以為檔案系統資料提供強一致性保證。
JuiceFS 支援後設資料的客戶端快取，當啟用客戶端快取時，可能會影響資料一致性，需要應用的一致性要求合理設定。
對於讀寫混合場景，HDFS 和 JuiceFS 均提供 open-after-close 語義，即保證新開啟的檔案，能夠讀到之前已經 close 的檔案所寫入的資料。而當一個檔案持續開啟時，它可能讀不到其他客戶端寫入的資料。
3.2 資料可靠性
一般應用往 HDFS 寫資料時，都是依賴成功的關閉檔案來確保資料被持久化，JuiceFS 也是一樣的。
為了給 HBase 提供低時延的資料寫入方式（通常在 HBase 的 WAL 檔案使用），HDFS 提供 hflush 方法來犧牲資料持久化（只寫入到多個DataNode 的記憶體中）以獲得低時延。
JuiceFS 的 hflush 會將資料持久化到客戶端的快取盤上（writeback 模式），依賴於快取盤的效能和可靠性。另外，當往物件儲存上傳的速度更不上時，或者客戶端退出，可能導致其他節點讀不到剛寫入的資料，會影響 HBase 的故障恢復能力。
為了更高的資料可靠性，HBase 可以透過 HDFS 的 hsync 介面來保證資料持久化。JuiceFS 也支援 hsync, 此時 JuiceFS 會將資料持久化到物件儲存中。
3.3 併發讀寫
HDFS 和 JuiceFS 都支援多機併發讀同一個檔案，可以獲得比較高的讀效能。
在併發寫方面，HDFS 不支援多個客戶端同時對同一個檔案進行寫操作。而 JuiceFS 支援併發寫，但需要應用自己管理檔案的偏移量(offset)，如果多個客戶端同時向相同的偏移量寫入資料，可能會導致資料的相互覆蓋。
HDFS 和 JuiceFS 一樣，如果多個客戶端同時開啟一個檔案，其中一個客戶端對檔案進行了修改，其他客戶端可能不能讀到最新的修改。
3.4 安全性
Kerberos 用於身份認證。HDFS 和 JuiceFS 企業版均支援。JuiceFS 社群版本僅支援使用認證後的使用者名稱，無法判斷使用者真偽。
Apache Ranger 用於授權。HDFS 和 JuiceFS 企業版均支援。JuiceFS 社群版不支援。
HDFS 和 JuiceFS 企業版均支援給目錄和檔案設定額外的訪問規則（ACL），JuiceFS 社群版不支援。
3.5 資料加密
HDFS實現了透明的端到端加密。一旦配置完成，使用者從特殊的 HDFS 目錄中讀寫資料時，資料會被自動加密和解密，無需對應用程式程式碼進行修改，操作過程對使用者透明。詳見：Apache Hadoop 3.3.4 – Transparent Encryption in HDFS
JuiceFS 也支援透明的端到端加密，包括傳輸加密（encryption in transit）及靜態加密（encryption at rest）。在使用者開啟了靜態加密時，需要使用者一個自行管理的金鑰，所有寫入的資料都會基於此金鑰進行資料加密，詳情見 《資料加密》。這些加密都應用都是透明的，無需修改應用程式碼。
3.6 快照
HDFS 的快照是指對某個目錄的只讀映象，能夠讓使用者持續方便一個目錄在某個時間點上的狀態。快照中的資料是隻讀的，任何原目錄的修改都不會影響到快照。在 HDFS 中，快照是透過記錄檔案系統目錄樹上的後設資料資訊來實現的，具有以下特點：
- 快照的建立是即時的：成本是O(1)，不包括節點查詢時間。
- 只有在相對於快照進行修改時才會使用額外的記憶體：記憶體使用量為O(M)，其中M是修改的檔案/目錄的數量。
- 資料節點中的塊不被複制：快照檔案記錄了塊列表和檔案大小。沒有資料複製。
- 快照不會對常規的HDFS操作產生不利影響：修改是按時間順序倒過來記錄的，因此可以直接訪問當前資料。快照資料是透過從當前資料中減去修改內容來計算的。
另外利用快照差異（snapshot diff），可以快速的複製增量資料。
JuiceFS 企業版快照功能採用了類似克隆的方式實現，快速複製後設資料而不復制底層資料，建立快照是 O(N), 記憶體使用量也是 O(N)。與 HDFS 的快照不同，JuiceFS 的快照可以被修改的。
3.7 儲存配額
HDFS 和 JuiceFS 均支援檔案數和儲存空間配額。JuiceFS 社群版需要升級到即將釋出的 1.1 版本。
3.8 符號連結
HDFS 不支援符號連線。
JuiceFS 社群版支援符號連結，Java SDK 可以訪問透過 POSIX 介面建立的符號連結（相對路徑）。
JuiceFS 企業版除了支援相對路徑的符號連結外，還支援連結到外部儲存系統（HDFS 相容），實現類似於 Hadoop 的 ViewFS 的效果。
3.9 目錄使用量統計
HDFS 提供 du 命令可以獲得某個目錄的實時使用量統計，JuiceFS 也支援 du 命令，企業版可以提供跟 HDFS 類似的實時結果， 社群版則需要在客戶端遍歷子目錄來統計。
3.10 彈性伸縮
HDFS 在儲存空間的彈性伸縮方面支援動態節點調整，但這可能涉及資料遷移和負載均衡問題。相比之下，JuiceFS 通常使用雲上物件儲存，其天然的彈性使得儲存空間可以按需使用。
3.11 運維管理
在運維管理方面，HDFS 各個大版本存在不相容性，同時需要匹配其他生態元件版本，升級過程較為複雜。相比之下，JuiceFS 社群版和企業版均支援 hadoop2 和 hadoop3，升級簡便，只需要替換 jar 檔案即可。此外，JuiceFS 提供工具來匯出和匯入後設資料，方便在不同叢集之間進行資料遷移。
4. 適用場景
在比較選擇 HDFS 和 JuiceFS 時，需要考慮不同的使用場景和需求。
HDFS 更適合規模比較固定的機房環境，使用裸盤作為儲存介質，無需考慮彈性和存算分離需求的使用場景。而在公有云環境下，公有云可提供的裸盤節點型別比較少，物件儲存成為了更好的儲存選擇，透過 JuiceFS 可以實現存算分離以獲得更好的彈性，同時支援 Hadoop 大資料生態的絕大部分應用，會是更高效的選擇。
此外，當大資料場景還需要跟其他應用（比如AI) 共享資料時，由於 JuiceFS 提供了更豐富的介面協議，可以很方便地在各個應用之間共享資料，省去了資料複製的麻煩，也會是更方便的選擇。
5. 總結：
特性
| 特性 | HDFS | JuiceFS 社群版 | JuiceFS 企業版 |
|---|---|---|---|
| 釋出時間 | 2005 | 2021 | 2017 |
| 程式語言 | Java | Go | Go |
| 開源 | Apache V2 | Apache V2 | 閉源 |
| 高可用 | 支援（依賴ZK） | 依賴後設資料引擎 | 支援 |
| 後設資料擴充套件 | 獨立名稱空間 | 依賴後設資料引擎 | 橫向擴充套件，單一名稱空間 |
| 後設資料儲存 | 記憶體 | 資料庫 | 記憶體 |
| 後設資料快取 | 不支援 | 支援 | 支援 |
| 資料儲存 | 磁碟 | 物件儲存 | 物件儲存 |
| 資料快取 | Datanode 記憶體快取 | 客戶端快取 | 客戶端快取/分散式快取 |
| 資料親和性 | 支援 | 支援 | 支援 |
| 一致性 | 強一致 | 強一致 | 強一致 |
| 重新命名原子性 | 是 | 是 | 是 |
| 追加寫 | 支援 | 支援 | 支援 |
| 檔案截斷（truncate） | 支援 | 支援 | 支援 |
| 併發寫 | 不支援 | 支援 | 支援 |
| hflush(HBase WAL 使用) | 多個DataNode記憶體 | 寫快取盤 | 寫快取盤 |
| ApacheRanger | 支援 | 不支援 | 支援 |
| Kerberos認證 | 支援 | 不支援 | 支援 |
| 資料加密 | 支援 | 支援 | 支援 |
| 快照 | 支援 | 不支援 | 支援（克隆） |
| 儲存配額 | 支援 | 支援 | 支援 |
| 符號連結 | 不支援 | 支援 | 支援 |
| 目錄統計 | 支援 | 不支援（需要遍歷） | 支援 |
| 彈性伸縮 | 手動 | 自動 | 自動 |
| 運維管理 | 較為複雜 | 簡單 | 簡單 |
訪問協議
| 協議 | HDFS | JuiceFS |
|---|---|---|
| FileSystem Java API | ✅ | ✅ |
| libhdfs (C API) | ✅ | ✅ |
| WebHDFS (REST API) | ✅ | ❌ |
| POSIX (FUSE or NFS) | ❌ | ✅ |
| Kubernetes CSI | ❌ | ✅ |
| S3 | ❌ | ✅ |
雖然 HDFS 也提供了 NFS Gateway 和 基於 FUSE 的客戶端，但因為跟 POSIX 的相容性比較差，效能也不夠好而很少被使用。
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)