元數據性能大比拼：HDFS vs S3 vs JuiceFS

2022 年 11 月 8 日
筆記

元數據是存儲系統的核心大腦，元數據性能對整個大數據平台的性能和擴展能力至關重要。尤其在處理海量文件的時候。在平台任務創建、運行和結束提交階段，會存在大量的元數據 create，open，rename 和 delete 操作。因此，在進行文件系統選型時，元數據性能可謂是首當其衝需要考量的一個因素。

目前主流的大數據存儲方案中， HDFS 是使用最為廣泛的方案，已經過十幾年的沉澱和積累；以 Amazon S3 為代表的對象存儲是近年來雲上大數據存儲的熱門方案；JuiceFS 是大數據圈的新秀，專為雲上大數據打造，基於對象存儲來進行大數據存儲。因此，我們選取了這 3 個典型的存儲方案 HDFS、Amazon S3 與 JuiceFS 社區版進行元數據的性能測試。

測試方法

NNBench 是Hadoop 中有一個專門壓測文件系統元數據性能的組件，本次測試就是使用它來進行的。

原版的 NNBench 有一些局限性，我們做了調整：

原版 NNBench 的單個測試任務是單執行緒的，資源利用率低，我們將它改成多執行緒，便於增加並發壓力。
原版 NNBench 使用 hostname 作為路徑名的一部分，沒有考慮同一個主機里多個並發任務的衝突問題，會導致多個測試任務重複創建和刪除文件，不太符合大數據工作負載的實際情況，我們改成使用 Map 的順序號來生成路徑名，避免的一個主機上多個測試任務的產生衝突。

測試環境

測試區域：us-east-1

測試軟體：

emr-6.4.0，hadoop3.2.1，HA部署
master（3台）：m5.xlarge, 4 vCore, 16 GiB
core（3台): m5.xlarge, 4 vCore, 16 GiB

JuiceFS 社區版本：v1.0.0

JuiceFS 元數據引擎：ElastiCache，6.2.6，cache.r5.large

性能表現

先來看看大家都熟悉的 HDFS 的性能表現：

此圖描述的是 HDFS 每秒處理的請求數（TPS）隨著並發數增長的曲線，隨著並發的增加，TPS基本呈現線性增長。

S3 速度比 HDFS 慢了一個數量級，但它的各種操作的速度基本保持穩定，總的 TPS 隨著並發數的增長而增長。
但 S3 性能不太穩定，可以看到 Delete 請求在 100 並發下反而出現了下降的情況，猜測可能和 S3 本身的負載有關。

整體趨勢和 HDFS 類似，Open 會比其他操作快很多。
JuiceFS 的 TPS 也是在 20 個並發以內基本保持線性增長，之後增長放緩，在 80 個並發左右達到上限

性能對比

為了更直觀的看出這三者的性能差異，我們直接把 HDFS、AWS S3 和 JuiceFS 放在一起比較：

JuiceFS 在所有元數據操作上均大幅領先於 S3。
JuiceFS 在 Create 和 Open 操作上領先於 HDFS。
此次測試中使用的元數據引擎是ElastiCache ，各操作在 80 並發左右會達到性能瓶頸，表現比 HDFS 差。

總結

一般我們在看一個系統的性能時，主要關注它的操作時延（單個操作所消耗的時間）和吞吐量（滿負載下的處理能力），我們把這兩個指標再匯總一下：

上圖是 20 個並發下的各操作的時延（未跑滿負載），可以發現：

S3 非常慢，尤其是 Rename 操作，因為它是通過 Copy + Delete 實現的。本文測試的還只是單個空文件的 Rename，而大數據場景常用的是對整個目錄的 Rename，差距會更大。
JuiceFS 的速度比 HDFS 更快。

上圖是 100 個並發時的吞吐量對比，可以發現：

S3 的吞吐量非常低，和其它兩個產品有一到兩個數量級的差距，意味著它需要使用更多的計算資源，產生更高的並發，才能獲得同等的處理能力。
JuiceFS 比 HDFS 的處理能力基本和 HDFS 持平，部分操作性能高於 HDFS。
隨著並發的持續升高，HDFS 的性能仍然可以繼續提升，但 JuiceFS 受制於元數據引擎本身的性能，到達瓶頸。如果需要高吞吐，可以使用 TiKV 作為元數據引擎。

JuiceFS 社區版可以適配各種成熟的元數據引擎，各種元數據引擎性能都有其相應的特點。比如 Redis 的低時延遲，MySQL 的可靠性，TiKV 的高吞吐。更多測試詳見：元數據引擎性能對比測試 | JuiceFS Document Center

如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0ᴗ0✿)