背景
儲存是大資料的基石，儲存系統的後設資料又是它的核心大腦，後設資料的效能對整個大資料平臺的效能和擴充套件能力非常關鍵。本文選取了大資料平臺中 3 個典型的儲存方案來壓測後設資料的效能，來個大比拼。
其中 HDFS 是被廣為使用的大資料儲存方案，已經經過十幾年的沉澱和積累，是最合適的參考標杆。
以 Amazon S3 和 Aliyun OSS 為代表的物件儲存也是雲上大資料平臺的候選方案，但它只有 HDFS 的部分功能和語義，效能也差不少，實際使用並不廣泛。在這個測試中物件儲存以 Aliyun OSS 為代表，其他物件儲存類似。
JuiceFS 是大資料圈的新秀，專為雲上大資料打造，是符合雲原生特徵的大資料儲存方案。JuiceFS 使用雲上物件儲存儲存客戶資料內容，通過 JuiceFS 後設資料服務和 Java SDK 來實現 HDFS 的完整相容，不需要對資料分析元件做任何修改就可以得到跟 HDFS 一樣的體驗。
測試方法
Hadoop 中有一個專門壓測檔案系統後設資料效能的元件叫 NNBench，本文就是使用它來做壓測的。
原版的 NNBench 有一些侷限性，我們做了調整：
- 原版 NNBench 的單個測試任務是單執行緒的，資源利用率低，我們將它改成多執行緒，便於增加併發壓力。
- 原版 NNBench 使用 hostname 作為路徑名的一部分，沒有考慮同一個主機裡多個併發任務的衝突問題，會導致多個測試任務重複建立和刪除檔案，不太符合大資料工作負載的實際情況，我們改成使用 Map 的順序號來生成路徑名，避免的一個主機上多個測試任務的產生衝突。
我們使用了 3 臺阿里雲 4核 16G 的虛擬機器來做壓力測試。CDH 5 是目前被廣泛使用的發行版，我們選用 CDH 5 作為測試環境，其中的 HDFS 是 2.6 版本。 HDFS 是使用 3 個 JournalNode 的高可用配置，JuiceFS 是 3 個節點的 Raft 組。HDFS 使用內網 IP，JuiceFS 使用的是彈性 IP，HDFS 的網路效能會好一些。OSS 是使用內網介面訪問。
資料分析
先來看看大家都熟悉的 HDFS 的效能表現：
此圖描述的是 HDFS 每秒處理的請求數（TPS）隨著併發數增長的曲線，有兩個發現：
- 其中 Open/Read 和 Delete 操作的效能要遠高於 Create 和 Rename。
- 在 20 個併發前，TPS 隨著併發數線性增長，之後就增長緩慢了，到 60 個併發已經能壓到 TPS 的極限（滿負載）。
再來看看 OSS 的效能情況：
OSS 速度比 HDFS 慢了一個數量級，但它的各種操作的速度基本保持穩定，總的 TPS 隨著併發數的增長而增長，在 80 個併發下還沒遇到瓶頸。受測試資源所限，未能進一步加大壓測知道它的上限。
最後看下 JuiceFS 的表現：
從圖中可以看出，整體趨勢和 HDFS 類似，Open/Read 和 Delete 操作明顯比 Create/Rename 快很多。JuiceFS 的 TPS 也是在 20 個併發以內基本保持執行緒增長，之後增長放緩，在 60 個併發左右達到上線。但 JuiceFS 增幅更快，上限更高。
詳細效能對比
為了更直觀的看出這三者的效能差異，我們直接把 HDFS、Aliyun OSS 和 JuiceFS 放在一起比較：
可見無論是哪種後設資料操作，JuiceFS 的 TPS 增長更快，上限也更高，明顯優於 HDFS 和 OSS。
總結
一般我們在看一個系統的效能時，主要關注它的操作時延（單個操作所消耗的時間）和吞吐量（滿負載下的處理能力），我們把這兩個指標再彙總一下：
上圖是 20 個併發下的各操作的時延（未跑滿負載），可以發現：
- OSS 非常慢，尤其是 Rename 操作，因為它是通過 Copy + Delete 實現的。本文測試的還只是單個檔案的 Rename，而大資料場景常用的是對整個目錄的 Rename，差距會更大。
- JuiceFS 的速度比 HDFS 更快，快一倍多。
上圖是 80 個併發時的吞吐量對比，可以發現：
- OSS 的吞吐量非常低，和其它兩個產品有一到兩個數量級的差距，意味著它需要使用更多的計算資源，產生更高的併發，才能獲得同等的處理能力。
- JuiceFS 比 HDFS 的處理能力高 50-200%，同樣的資源能夠支撐更大規模的計算。
從以上兩個核心效能指標來看，物件儲存不適合要求效能的大資料分析場景。
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)