元數據是存儲系統的核心大腦 ， 元數據性能對整個大數據平臺的性能和擴展能力至關重要 。尤其在處理海量文件的時候 。在平臺任務創建、運行和結束提交階段 ， 會存在大量的元數據 create，open ， rename 和 delete 操作 。因此，在進行文件系統選型時，元數據性能可謂是首當其沖需要考量的一個因素 。
目前主流的大數據存儲方案中，HDFS 是使用最為廣泛的方案 ， 已經過十幾年的沉淀和積累；以 Amazon S3 為代表的對象存儲是近年來云上大數據存儲的熱門方案；JuiceFS 是大數據圈的新秀 ， 專為云上大數據打造，基于對象存儲來進行大數據存儲 。因此，我們選取了這 3 個典型的存儲方案 HDFS、Amazon S3 與 JuiceFS 社區版 進行元數據的性能測試 。
測試方法NNBench 是Hadoop 中有一個專門壓測文件系統元數據性能的組件，本次測試就是使用它來進行的 。
原版的 NNBench 有一些局限性，我們做了調整：
- 原版 NNBench 的單個測試任務是單線程的，資源利用率低，我們將它改成多線程，便于增加并發壓力 。
- 原版 NNBench 使用 hostname 作為路徑名的一部分 ， 沒有考慮同一個主機里多個并發任務的沖突問題，會導致多個測試任務重復創建和刪除文件，不太符合大數據工作負載的實際情況，我們改成使用 Map 的順序號來生成路徑名 ， 避免的一個主機上多個測試任務的產生沖突 。
測試軟件：
- 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 元數據引擎：ElastiCache，6.2.6，cache.r5.large
性能表現先來看看大家都熟悉的 HDFS 的性能表現：
文章插圖
此圖描述的是 HDFS 每秒處理的請求數（TPS）隨著并發數增長的曲線，隨著并發的增加 ， TPS基本呈現線性增長 。
【元數據性能大比拼：HDFS vs S3 vs JuiceFS】
文章插圖
- S3 速度比 HDFS 慢了一個數量級，但它的各種操作的速度基本保持穩定，總的 TPS 隨著并發數的增長而增長 。
- 但 S3 性能不太穩定 ， 可以看到 Delete 請求在 100 并發下反而出現了下降的情況，猜測可能和 S3 本身的負載有關 。
文章插圖
- 整體趨勢和 HDFS 類似，Open 會比其他操作快很多 。
- JuiceFS 的 TPS 也是在 20 個并發以內基本保持線性增長，之后增長放緩 ， 在 80 個并發左右達到上限
文章插圖
文章插圖
文章插圖
文章插圖
- JuiceFS 在所有元數據操作上均大幅領先于 S3 。
- JuiceFS 在 Create 和 Open 操作上領先于 HDFS 。
- 此次測試中使用的元數據引擎是ElastiCache，各操作在 80 并發左右會達到性能瓶頸 ， 表現比 HDFS 差 。
文章插圖
上圖是 20 個并發下的各操作的時延（未跑滿負載），可以發現：
- S3 非常慢，尤其是 Rename 操作，因為它是通過 Copy + Delete 實現的 。本文測試的還只是單個空文件的 Rename，而大數據場景常用的是對整個目錄的 Rename ， 差距會更大 。
- JuiceFS 的速度比 HDFS 更快 。
文章插圖
上圖是 100 個并發時的吞吐量對比，可以發現：
- S3 的吞吐量非常低，和其它兩個產品有一到兩個數量級的差距，意味著它需要使用更多的計算資源，產生更高的并發，才能獲得同等的處理能力 。
- JuiceFS 比 HDFS 的處理能力基本和 HDFS 持平，部分操作性能高于 HDFS 。
推薦閱讀
- 全國狀元-今年高考全國狀元是誰啊
- JS數據結構與算法-隊列結構
- 驍龍888和驍龍870性能對比-驍龍888和驍龍870哪個好
- Day04：Java數據類型
- 關于入門深度學習mnist數據集前向計算的記錄
- 天璣920和天璣900有什么區別_性能差多少
- .NET性能優化-是時候換個序列化協議了
- EasyPoi大數據導入導出百萬級實例
- JAVA開發搞了一年多的大數據，究竟干了點啥
- 重新整理 .net core 實踐篇 ———— linux上性能排查 [外篇]
