作者：蘇昆輝，花名撫月，阿裡巴巴計算平台事業部 EMR 技術專家, Apache HDFS committer，目前從事開源大資料存儲和優化方面的工作。
主要介紹
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億檔案數，進而測試其是否可以保持穩定的性能。
測試環境
| 主執行個體組 (MASTER) | 核心執行個體組 (CORE) |
| 主機數量: 3 機型規格: ecs.g5.8xlarge CPU: 32核 記憶體: 128GB 資料盤配置: 640GB ESSD雲盤*1 | 主機數量: 4 機型規格: ecs.i2g.8xlarge 資料盤配置: 1788GB 本地盤*2 |
資料集（共4組）
為了測試在不同的中繼資料規模下，JIndoFS中繼資料服務的性能。我們準備4組資料。分别是：初始狀态（0檔案數）、1億檔案數、5億檔案數、10億檔案數。我們使用一份真實的經過使用者脫敏的HDFS FsImage檔案，将其還原到JindoFS中繼資料服務當中。檔案大小按1：1相應地建立block資訊一起存入JindoFS中繼資料。最終生成的資料集如下。
中繼資料磁盤空間占用
| 0檔案數（初始狀态） | 1億檔案數 | 5億檔案數 | 10億檔案數 |
| 50MB | 17GB | 58GB | 99GB |
檔案大小的分布（以10億檔案數為例）
| 檔案大小 | 比例 |
| 0（目錄） | 1.47% |
| 0（檔案） | 2.40% |
| 大于0，小于等于128KB | 33.66% |
| 大于128KB，小于等于1MB | 16.71% |
| 大于1MB，小于等于8MB | 15.49% |
| 大于8MB，小于等于64MB | 18.18% |
| 大于64MB，小于等于512MB | 9.26% |
| 大于512MB | 2.82% |
另外，目錄層級主要分布在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個）
測試結果
| 操作 | 0檔案數 | |||
| create_write | 5836 | 5791 | 5598 | 5153 |
| open_read | 24853 | 24097 | 23521 | 23567 |
NNBench的結果很好地回報了随着中繼資料規模增長，中繼資料服務的性能變化曲線。通過結果我們可以分析得出：
- 當達到10億檔案數時，寫入TPS受到略微影響，TPS 下降為原先的88%。
- 當達到5億檔案數時，讀TPS受到略微影響，TPS 下降為原先的94%。而10億檔案數時，讀TPS保持穩定，跟5億檔案數時基本持平。
TPC-DS測試
使用的是官方TPC-DS資料集，5TB資料量，使用的是ORC格式，Spark作為執行引擎進行測試。
測試成績如下，時間機關秒：
99個查詢總耗時對比：
| 查詢 | ||||
| 總計 | 13032.51 | 13015.226 | 13022.914 | 13052.728 |
通過觀察發現，去掉誤差影響，随着中繼資料規模從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 | 7.321 | 7.322 | 7.425 |
| count | 5.425 | 5.445 | 5.478 |
測試結果發現，對于周遊（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 的本地緩存加速能力，組成一個雲上穩定、可靠、高性能的大資料存儲方案，給上層計算分析引擎提供強大有力的支撐。
另外，JindoFS SDK可以單獨使用，替代Hadoop社群OSS用戶端實作。相比于Hadoop社群實作，JindoFS SDK對讀寫OSS的能力上做了很多的性能優化，可以通路
github repo下載下傳使用。
歡迎試用
歡迎對阿裡雲 JindoFS 感興趣的朋友加入阿裡雲EMR釘釘群交流測試，群内會定期進行精品内容分享，測試請@揚流，釘釘群如下