?元數(shù)據(jù)性能大比拼：HDFS vs S3 vs JuiceFS

發(fā)布于?2022-11-16 19:14:06

6270

舉報

元數(shù)據(jù)是存儲系統(tǒng)的核心大腦，元數(shù)據(jù)性能對整個大數(shù)據(jù)平臺的性能和擴展能力至關(guān)重要。尤其在處理海量文件的時候。在平臺任務(wù)創(chuàng)建、運行和結(jié)束提交階段，會存在大量的元數(shù)據(jù) create，open，rename 和 delete 操作。因此，在進行文件系統(tǒng)選型時，元數(shù)據(jù)性能可謂是首當其沖需要考量的一個因素。

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

測試方法

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

原版的 NNBench 有一些局限性，我們做了調(diào)整：

1. 原版 NNBench 的單個測試任務(wù)是單線程的，資源利用率低，我們將它改成多線程，便于增加并發(fā)壓力。

2. 原版 NNBench 使用 hostname 作為路徑名的一部分，沒有考慮同一個主機里多個并發(fā)任務(wù)的沖突問題，會導致多個測試任務(wù)重復(fù)創(chuàng)建和刪除文件，不太符合大數(shù)據(jù)工作負載的實際情況，我們改成使用 Map 的順序號來生成路徑名，避免的一個主機上多個測試任務(wù)的產(chǎn)生沖突。

測試環(huán)境

測試區(qū)域：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 社區(qū)版本：v1.0.0

JuiceFS 元數(shù)據(jù)引擎：ElastiCache，6.2.6，cache.r5.large

性能表現(xiàn)

先來看看大家都熟悉的 HDFS 的性能表現(xiàn)：

此圖描述的是 HDFS 每秒處理的請求數(shù)（TPS）隨著并發(fā)數(shù)增長的曲線，隨著并發(fā)的增加，TPS基本呈現(xiàn)線性增長。

• S3 速度比 HDFS 慢了一個數(shù)量級，但它的各種操作的速度基本保持穩(wěn)定，總的 TPS 隨著并發(fā)數(shù)的增長而增長。

• 但 S3 性能不太穩(wěn)定，可以看到 Delete 請求在 100 并發(fā)下反而出現(xiàn)了下降的情況，猜測可能和 S3 本身的負載有關(guān)。

• 整體趨勢和 HDFS 類似，Open 會比其他操作快很多。

• JuiceFS 的 TPS 也是在 20 個并發(fā)以內(nèi)基本保持線性增長，之后增長放緩，在 80 個并發(fā)左右達到上限

性能對比

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

• JuiceFS 在所有元數(shù)據(jù)操作上均大幅領(lǐng)先于 S3。

• JuiceFS 在 Create 和 Open 操作上領(lǐng)先于 HDFS。

• 此次測試中使用的元數(shù)據(jù)引擎是ElastiCache ， 各操作在 80 并發(fā)左右會達到性能瓶頸，表現(xiàn)比 HDFS 差。

總結(jié)

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

上圖是 20 個并發(fā)下的各操作的時延（未跑滿負載），可以發(fā)現(xiàn)：

1. S3 非常慢，尤其是 Rename 操作，因為它是通過 Copy + Delete 實現(xiàn)的。本文測試的還只是單個空文件的 Rename，而大數(shù)據(jù)場景常用的是對整個目錄的 Rename，差距會更大。

2. JuiceFS 的速度比 HDFS 更快。

上圖是 100 個并發(fā)時的吞吐量對比，可以發(fā)現(xiàn)：

1. S3 的吞吐量非常低，和其它兩個產(chǎn)品有一到兩個數(shù)量級的差距，意味著它需要使用更多的計算資源，產(chǎn)生更高的并發(fā)，才能獲得同等的處理能力。

2. JuiceFS 比 HDFS 的處理能力基本和 HDFS 持平，部分操作性能高于 HDFS。

3. 隨著并發(fā)的持續(xù)升高，HDFS 的性能仍然可以繼續(xù)提升，但 JuiceFS 受制于元數(shù)據(jù)引擎本身的性能，到達瓶頸。如果需要高吞吐，可以使用 TiKV 作為元數(shù)據(jù)引擎。

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

如有幫助的話歡迎關(guān)注我們項目 Juicedata/JuiceFS 喲！ (0?0?)