簡介： Apache Hadoop FileSystem (HDFS) 是被廣為使用的大資料儲存方案，其核心元資料服務 NameNode 將全部元資料存放在記憶體中，因此所能承載的元資料規模受限於記憶體，單個例項所能支撐的檔案個數大約 4億。JindoFS塊模式是阿里雲基於 OSS 海量儲存自研的一個儲存最佳化系統，提供了高效的資料讀寫加速能力和元資料最佳化能力。JindoFS 實際表現如何，我們在 10億檔案數規模下做了壓測，驗證 JindoFS 在達到這個規模的時候是否還可以保持穩定的效能。
主要介紹Apache Hadoop FileSystem (HDFS) 是被廣為使用的大資料儲存方案，其核心元資料服務 NameNode 將全部元資料存放在記憶體中，因此所能承載的元資料規模受限於記憶體，單個例項所能支撐的檔案個數大約 4億。JindoFS塊模式是阿里雲基於 OSS 海量儲存自研的一個儲存最佳化系統，提供了高效的資料讀寫加速能力和元資料最佳化能力。在設計上避免了 NameNode 上的記憶體限制，與HDFS不同的一點是，JindoFS元資料服務採用RocksDB作為底層元資料儲存，RocksDB可以儲存在大容量本地高速磁碟，解決了記憶體容量瓶頸問題。藉助於記憶體快取，將10%~40%的熱檔案元資料存放於記憶體快取，從而保持穩定的優秀的讀寫效能。藉助於Raft機制，JindoFS元資料服務可以組成3個主備例項，實現服務高可用。JindoFS 實際表現如何，我們在 10億檔案數規模下做了壓測，驗證 JindoFS 在達到這個規模的時候是否還可以保持穩定的效能。同時在一些關鍵的元資料操作上，我們也跟 HDFS 做了個測試對比。
JindoFS 10億檔案數測試HDFS NameNode 單個例項所能支撐的檔案個數大約 4億，主要原因是受限於記憶體大小。除此之外，由於檔案數增加，需要處理的DataNode上報塊也增加，造成了效能上的巨大抖動。大量檔案資訊儲存在一個很大的FsImage檔案，用於下次啟動時載入，而很大的FsImage檔案使得 NameNode 啟動需要花費10分鐘以上的時間。
JindoFS 解決了以上系列問題，它使用 RocksDB 儲存元資料，相比於 NameNode 可以儲存更大規模的檔案數，不受限於記憶體。另外不需要Worker節點上報塊資訊，沒有效能抖動的問題。JindoFS 元資料服務可以在1s內完成啟動，毫秒內完成主備節點切換。所以本次測試，我們分別測試了 JindoFS 從1億檔案數增長到10億檔案數，從而測試其是否可以保持穩定的效能。
資料集（共4組）為了測試在不同的元資料規模下，JIndoFS元資料服務的效能。我們準備4組資料。分別是：初始狀態（0檔案數）、1億檔案數、5億檔案數、10億檔案數。我們使用一份真實的經過使用者脫敏的HDFS FsImage檔案，將其還原到JindoFS元資料服務當中。檔案大小按1：1相應地建立block資訊一起存入JindoFS元資料。最終生成的資料集如下。
元資料磁碟空間佔用
另外，目錄層級主要分佈在5到7級目錄居多。資料集的檔案大小分佈、目錄層級分佈一定程度上比較接近生產環境的情況。
NNBench測試NNBench全稱NameNode Benchmark，是HDFS官方自帶的用於測試NameNode效能的工具。由於它使用的是標準的FileSystem介面，因此我們可以使用它來測試JindoFS服務端的效能。NNBench的執行引數如下：
測試寫效能
-operation create_write -maps 200 -numberOfFiles 5000 -bytesToWrite 512
測試讀效能
-operation open_read -maps 200 -numberOfFiles 5000 -bytesToWrite 512
啟動200個Map Task，每個Task寫（讀）5000個檔案，共計100萬個檔案。（受測試叢集規模限制，實際同時執行Map個數為128個）
測試結果
NNBench的結果很好地反饋了隨著元資料規模增長，元資料服務的效能變化曲線。透過結果我們可以分析得出：
當達到10億檔案數時，寫入TPS受到略微影響，TPS 下降為原先的88%。當達到5億檔案數時，讀TPS受到略微影響，TPS 下降為原先的94%。而10億檔案數時，讀TPS保持穩定，跟5億檔案數時基本持平。TPC-DS測試使用的是官方TPC-DS資料集，5TB資料量，使用的是ORC格式，Spark作為執行引擎進行測試。
測試成績如下，時間單位秒：
99個查詢總耗時對比：
透過觀察發現，去掉誤差影響，隨著元資料規模從0增加到10億檔案數，TPC-DS成績基本不受影響。
ls -R/count測試上述NNBench工具主要測試高併發下元資料服務單點寫入、單點查詢的效能。然而，檔案列表匯出（ls -R)操作、檔案大小統計（du/count)操作也是使用者使用頻率較高的操作，這些命令的執行時間，反應了元資料服務遍歷操作的執行效率。
我們使用兩個樣本資料進行測試：
對一個表（半年資料，154個分割槽，270萬個檔案）執行ls -R操作，統計執行時間，使用以下命令time hadoop fs -ls -R jfs://test/warehouse/xxx.db/tbl_xxx_daily_xxx > /dev/null
對一個數據庫（50萬個目錄，1800萬個檔案）執行count操作，統計執行時間，使用以下命令time hadoop fs -count jfs://test/warehouse/xxx.db
測試結果發現，對於遍歷（ls -R/count)相同數量的檔案（目錄），元資料服務的效能保持穩定，不會隨著元資料總量的增長有所變化。
對於10億級別的檔案數，磁碟佔用有近100GB，JindoFS元資料服務只會快取部分熱檔案元資料，那麼元資料檔案的page cache是否會對效能有所影響？我們為此做了測試。
熱啟動：直接重啟元資料服務服務，此時系統存在page cahe。
冷啟動：我們使用命令echo 3 > /proc/sys/vm/drop_caches清空快取，並重啟元資料服務。
測試結果如下（使用10億檔案資料集）
透過觀察發現，冷啟動情況下，這些操作耗時增加了約0.2秒，只受到細微的影響。
與HDFS橫向對比測試透過上面的測試我們得知 JindoFS 在10億檔案數下，依然保持了穩定的效能。另外我們補充測試了 JindoFS 跟 HDFS 的對比。由於 HDFS 儲存10億規模檔案數需要極高規格的機器，因此本輪測試我們主要測試1億檔案數場景，我們透過橫向對比list、du、count等常用操作，對比兩者的效能差異。
樣本說明抽取 a, b, c, d 共 4 組目錄，
目錄 a：Hive warehouse目錄包含 31.7萬目錄，1250萬檔案；
目錄 b：某 database 目錄包含 1萬2目錄，32萬檔案；
目錄 c：某 table 目錄包含 91個目錄，7.7萬檔案；
目錄 d：spark 結果存放目錄包含4.2萬目錄，7.1萬檔案；
測試結果（用時更短，效能更好）單層 list 操作
對單層目錄進行展開並輸出，取樣方法： time hadoop dfs -ls [DIR] > /dev/null
遞迴 list 操作
對目錄進行逐層展開並輸出，取樣方法： time hadoop dfs -ls -R [DIR] > /dev/null
du 操作
對目錄佔用的儲存空間進行計算，取樣方法： time hadoop dfs -du [DIR] > /dev/null
count 操作
對目錄的檔案(夾)數量、容量進行計算，取樣方法： time hadoop dfs -count [DIR] > /dev/null
結果分析透過上述測試結果，可以明顯發現 JindoFS 在list、du、count等常用操作上速度明顯快於 HDFS。分析原因，HDFS NameNode 記憶體中使用了全域性的讀寫鎖，所以對於查詢操作，尤其是對目錄的遞迴查詢操作都需要拿讀鎖。拿鎖之後使用了單執行緒序列的方式做目錄遞迴操作，速度較慢。拿鎖時間長繼而又影響了其它rpc請求的執行。JindoFS 從設計上解決了這些問題。它對目錄的遞迴操作使用了多執行緒併發加速，因此在對目錄樹的遞迴操作上速度更快。同時使用了不同的目錄樹儲存結構，配合細粒度鎖，從而減少了多個請求之間的影響。
總結JindoFS 塊模式可以輕鬆地儲存10億+檔案數，並且提供高效能的讀寫請求處理能力。跟 HDFS NameNode 相比佔用記憶體更小、效能更好、運維更加簡單。我們可以利用 JindoFS 作為儲存引擎，將底層資料存放在物件儲存（比如OSS）上，並且利用 JindoFS 的本地快取加速能力，組成一個雲上穩定、可靠、高效能的大資料儲存方案，給上層計算分析引擎提供強大有力的支撐。