10亿+文件数压测，阿里云JindoFS轻松应对
簡介： Apache Hadoop FileSystem (HDFS) 是被廣為使用的大數(shù)據(jù)存儲(chǔ)方案，其核心元數(shù)據(jù)服務(wù) NameNode 將全部元數(shù)據(jù)存放在內(nèi)存中，因此所能承載的元數(shù)據(jù)規(guī)模受限于內(nèi)存，單個(gè)實(shí)例所能支撐的文件個(gè)數(shù)大約 4億。JindoFS塊模式是阿里云基于 OSS 海量存儲(chǔ)自研的一個(gè)存儲(chǔ)優(yōu)化系統(tǒng)，提供了高效的數(shù)據(jù)讀寫加速能力和元數(shù)據(jù)優(yōu)化能力。JindoFS 實(shí)際表現(xiàn)如何，我們在 10億文件數(shù)規(guī)模下做了壓測，驗(yàn)證 JindoFS 在達(dá)到這個(gè)規(guī)模的時(shí)候是否還可以保持穩(wěn)定的性能。
主要介紹
Apache Hadoop FileSystem (HDFS) 是被廣為使用的大數(shù)據(jù)存儲(chǔ)方案，其核心元數(shù)據(jù)服務(wù) NameNode 將全部元數(shù)據(jù)存放在內(nèi)存中，因此所能承載的元數(shù)據(jù)規(guī)模受限于內(nèi)存，單個(gè)實(shí)例所能支撐的文件個(gè)數(shù)大約 4億。JindoFS塊模式是阿里云基于 OSS 海量存儲(chǔ)自研的一個(gè)存儲(chǔ)優(yōu)化系統(tǒng)，提供了高效的數(shù)據(jù)讀寫加速能力和元數(shù)據(jù)優(yōu)化能力。在設(shè)計(jì)上避免了 NameNode 上的內(nèi)存限制，與HDFS不同的一點(diǎn)是，JindoFS元數(shù)據(jù)服務(wù)采用RocksDB作為底層元數(shù)據(jù)存儲(chǔ)，RocksDB可以存儲(chǔ)在大容量本地高速磁盤，解決了內(nèi)存容量瓶頸問題。借助于內(nèi)存緩存，將10%~40%的熱文件元數(shù)據(jù)存放于內(nèi)存緩存，從而保持穩(wěn)定的優(yōu)秀的讀寫性能。借助于Raft機(jī)制，JindoFS元數(shù)據(jù)服務(wù)可以組成3個(gè)主備實(shí)例，實(shí)現(xiàn)服務(wù)高可用。JindoFS 實(shí)際表現(xiàn)如何，我們在 10億文件數(shù)規(guī)模下做了壓測，驗(yàn)證 JindoFS 在達(dá)到這個(gè)規(guī)模的時(shí)候是否還可以保持穩(wěn)定的性能。同時(shí)在一些關(guān)鍵的元數(shù)據(jù)操作上，我們也跟 HDFS 做了個(gè)測試對比。
?
JindoFS 10億文件數(shù)測試
HDFS NameNode 單個(gè)實(shí)例所能支撐的文件個(gè)數(shù)大約 4億，主要原因是受限于內(nèi)存大小。除此之外，由于文件數(shù)增加，需要處理的DataNode上報(bào)塊也增加，造成了性能上的巨大抖動(dòng)。大量文件信息保存在一個(gè)很大的FsImage文件，用于下次啟動(dòng)時(shí)加載，而很大的FsImage文件使得 NameNode 啟動(dòng)需要花費(fèi)10分鐘以上的時(shí)間。
JindoFS 解決了以上系列問題，它使用 RocksDB 存儲(chǔ)元數(shù)據(jù)，相比于 NameNode 可以存儲(chǔ)更大規(guī)模的文件數(shù)，不受限于內(nèi)存。另外不需要Worker節(jié)點(diǎn)上報(bào)塊信息，沒有性能抖動(dòng)的問題。JindoFS 元數(shù)據(jù)服務(wù)可以在1s內(nèi)完成啟動(dòng)，毫秒內(nèi)完成主備節(jié)點(diǎn)切換。所以本次測試，我們分別測試了 JindoFS 從1億文件數(shù)增長到10億文件數(shù)，從而測試其是否可以保持穩(wěn)定的性能。
?
數(shù)據(jù)集（共4組）
為了測試在不同的元數(shù)據(jù)規(guī)模下，JIndoFS元數(shù)據(jù)服務(wù)的性能。我們準(zhǔn)備4組數(shù)據(jù)。分別是：初始狀態(tài)（0文件數(shù)）、1億文件數(shù)、5億文件數(shù)、10億文件數(shù)。我們使用一份真實(shí)的經(jīng)過用戶脫敏的HDFS FsImage文件，將其還原到JindoFS元數(shù)據(jù)服務(wù)當(dāng)中。文件大小按1：1相應(yīng)地創(chuàng)建block信息一起存入JindoFS元數(shù)據(jù)。最終生成的數(shù)據(jù)集如下。
?
元數(shù)據(jù)磁盤空間占用
?
另外，目錄層級(jí)主要分布在5到7級(jí)目錄居多。數(shù)據(jù)集的文件大小分布、目錄層級(jí)分布一定程度上比較接近生產(chǎn)環(huán)境的情況。
?
NNBench測試
NNBench全稱NameNode Benchmark，是HDFS官方自帶的用于測試NameNode性能的工具。由于它使用的是標(biāo)準(zhǔn)的FileSystem接口，因此我們可以使用它來測試JindoFS服務(wù)端的性能。NNBench的執(zhí)行參數(shù)如下：
測試寫性能
-operation create_write -maps 200 -numberOfFiles 5000 -bytesToWrite 512
測試讀性能
-operation open_read -maps 200 -numberOfFiles 5000 -bytesToWrite 512
?
啟動(dòng)200個(gè)Map Task，每個(gè)Task寫（讀）5000個(gè)文件，共計(jì)100萬個(gè)文件。（受測試集群規(guī)模限制，實(shí)際同時(shí)執(zhí)行Map個(gè)數(shù)為128個(gè)）
?
測試結(jié)果
?
?
NNBench的結(jié)果很好地反饋了隨著元數(shù)據(jù)規(guī)模增長，元數(shù)據(jù)服務(wù)的性能變化曲線。通過結(jié)果我們可以分析得出：
?
TPC-DS測試
使用的是官方TPC-DS數(shù)據(jù)集，5TB數(shù)據(jù)量，使用的是ORC格式，Spark作為執(zhí)行引擎進(jìn)行測試。
測試成績?nèi)缦?#xff0c;時(shí)間單位秒：
?
99個(gè)查詢總耗時(shí)對比：
?
通過觀察發(fā)現(xiàn)，去掉誤差影響，隨著元數(shù)據(jù)規(guī)模從0增加到10億文件數(shù)，TPC-DS成績基本不受影響。
?
ls -R/count測試
上述NNBench工具主要測試高并發(fā)下元數(shù)據(jù)服務(wù)單點(diǎn)寫入、單點(diǎn)查詢的性能。然而，文件列表導(dǎo)出（ls -R)操作、文件大小統(tǒng)計(jì)（du/count)操作也是用戶使用頻率較高的操作，這些命令的執(zhí)行時(shí)間，反應(yīng)了元數(shù)據(jù)服務(wù)遍歷操作的執(zhí)行效率。
我們使用兩個(gè)樣本數(shù)據(jù)進(jìn)行測試：
time hadoop fs -ls -R jfs://test/warehouse/xxx.db/tbl_xxx_daily_xxx > /dev/null
time hadoop fs -count jfs://test/warehouse/xxx.db
?
測試結(jié)果發(fā)現(xiàn)，對于遍歷（ls -R/count)相同數(shù)量的文件（目錄），元數(shù)據(jù)服務(wù)的性能保持穩(wěn)定，不會(huì)隨著元數(shù)據(jù)總量的增長有所變化。
?
對于10億級(jí)別的文件數(shù)，磁盤占用有近100GB，JindoFS元數(shù)據(jù)服務(wù)只會(huì)緩存部分熱文件元數(shù)據(jù)，那么元數(shù)據(jù)文件的page cache是否會(huì)對性能有所影響？我們?yōu)榇俗隽藴y試。
熱啟動(dòng)：直接重啟元數(shù)據(jù)服務(wù)服務(wù)，此時(shí)系統(tǒng)存在page cahe。
冷啟動(dòng)：我們使用命令echo 3 > /proc/sys/vm/drop_caches清空緩存，并重啟元數(shù)據(jù)服務(wù)。
?
測試結(jié)果如下（使用10億文件數(shù)據(jù)集）
?
通過觀察發(fā)現(xiàn)，冷啟動(dòng)情況下，這些操作耗時(shí)增加了約0.2秒，只受到細(xì)微的影響。
?
與HDFS橫向?qū)Ρ葴y試
通過上面的測試我們得知 JindoFS 在10億文件數(shù)下，依然保持了穩(wěn)定的性能。另外我們補(bǔ)充測試了 JindoFS 跟 HDFS 的對比。由于 HDFS 存儲(chǔ)10億規(guī)模文件數(shù)需要極高規(guī)格的機(jī)器，因此本輪測試我們主要測試1億文件數(shù)場景，我們通過橫向?qū)Ρ萳ist、du、count等常用操作，對比兩者的性能差異。
?
樣本說明
抽取 a, b, c, d 共 4 組目錄，
目錄 a：Hive warehouse目錄包含 31.7萬目錄，1250萬文件；
目錄 b：某 database 目錄包含 1萬2目錄，32萬文件；
目錄 c：某 table 目錄包含 91個(gè)目錄，7.7萬文件；
目錄 d：spark 結(jié)果存放目錄包含4.2萬目錄，7.1萬文件；
?
測試結(jié)果（用時(shí)更短，性能更好）
單層 list 操作
對單層目錄進(jìn)行展開并輸出，采樣方法： time hadoop dfs -ls [DIR] > /dev/null
?
遞歸 list 操作
對目錄進(jìn)行逐層展開并輸出，采樣方法： time hadoop dfs -ls -R [DIR] > /dev/null
?
du 操作
對目錄占用的存儲(chǔ)空間進(jìn)行計(jì)算，采樣方法： time hadoop dfs -du [DIR] > /dev/null
?
count 操作
對目錄的文件(夾)數(shù)量、容量進(jìn)行計(jì)算，采樣方法： time hadoop dfs -count [DIR] > /dev/null
?
結(jié)果分析
通過上述測試結(jié)果，可以明顯發(fā)現(xiàn) JindoFS 在list、du、count等常用操作上速度明顯快于 HDFS。分析原因，HDFS NameNode 內(nèi)存中使用了全局的讀寫鎖，所以對于查詢操作，尤其是對目錄的遞歸查詢操作都需要拿讀鎖。拿鎖之后使用了單線程串行的方式做目錄遞歸操作，速度較慢。拿鎖時(shí)間長繼而又影響了其它rpc請求的執(zhí)行。JindoFS 從設(shè)計(jì)上解決了這些問題。它對目錄的遞歸操作使用了多線程并發(fā)加速，因此在對目錄樹的遞歸操作上速度更快。同時(shí)使用了不同的目錄樹存儲(chǔ)結(jié)構(gòu)，配合細(xì)粒度鎖，從而減少了多個(gè)請求之間的影響。
總結(jié)
JindoFS 塊模式可以輕松地存儲(chǔ)10億+文件數(shù)，并且提供高性能的讀寫請求處理能力。跟 HDFS NameNode 相比占用內(nèi)存更小、性能更好、運(yùn)維更加簡單。我們可以利用 JindoFS 作為存儲(chǔ)引擎，將底層數(shù)據(jù)存放在對象存儲(chǔ)（比如OSS）上，并且利用 JindoFS 的本地緩存加速能力，組成一個(gè)云上穩(wěn)定、可靠、高性能的大數(shù)據(jù)存儲(chǔ)方案，給上層計(jì)算分析引擎提供強(qiáng)大有力的支撐。
作者：蘇昆輝，花名撫月，阿里巴巴計(jì)算平臺(tái)事業(yè)部 EMR 技術(shù)專家, Apache HDFS committer，目前從事開源大數(shù)據(jù)存儲(chǔ)和優(yōu)化方面的工作。
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載
作者：蘇昆輝，花名撫月，阿里巴巴計(jì)算平臺(tái)事業(yè)部 EMR 技術(shù)專家, Apache HDFS committer，目前從事開源大數(shù)據(jù)存儲(chǔ)和優(yōu)化方面的工作。
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載
?
總結(jié)
以上是生活随笔為你收集整理的10亿+文件数压测，阿里云JindoFS轻松应对的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 怕入错行？这群技术人写了本“择业指南”
- 下一篇： 双十一消费近万亿！1亿人见证数字物流，“