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亿人见证数字物流,“