Hbase和Hadoop操作文件性能測試
本節(jié)向大家介紹一下測試Hbase和Hadoop操作文件的性能的方法，主要有六個方面的內(nèi)容，希望通過本節(jié)簡單的介紹大家能夠掌握測試Hbase和Hadoop操作文件的性能的方法，下面就讓我們一起來學(xué)習(xí)吧。
測試Hbase和Hadoop操作文件的性能
1:單線程hbase的文件存入
StringparentPath="F:/pic/2003-zhujiajian";
File[]files=getAllFilePath(parentPath);
HBaseConfigurationconfig=newHBaseConfiguration();
HTabletable=newHTable(config,newText("offer"));
longstart=System.currentTimeMillis();
for(Filefile:files){
if(file.isFile()){
byte[]data=getData(file);
createRecore(table,file.getName(),"image_big",data);
}
}
longend=System.currentTimeMillis();
System.out.println("timecost="+(end-start));
108037206bytes,303個fileswritefromlocalwindowstoremotehbase,cost23328or21001milliseconds
2:單線程hadoop的文件存入
Configurationconf=newConfiguration();
FileSystemfs=FileSystem.get(conf);
Pathsrc=newPath("F:/pic/2003-zhujiajian");
Pathdst=newPath("/user/zxf/image");
longstart=System.currentTimeMillis();
fs.copyFromLocalFile(src,dst);
longend=System.currentTimeMillis();
System.out.println("timecost="+(end-start));
108037206bytes,303fileswritefromlocalwindowstoremotehdfs,cost26531or32407milliseconds
3:單線程hbase的文件讀取
108037206bytes,303filesreadfromhdfstolocalcost479350milliseconds
4:單線程hadoop的文件讀取
108037206bytes,303filesreadfromhdfstolocalcost14188milliseconds
5:深入測試Hbase和Hadoop操作文件性能
取幾個文件對比
fileSize(byte)hdfstime(ms)hbasetime(ms)
12341140131314688
708474634359
82535153907
5529616125
6思考
測試Hbase和Hadoop操作文件性能期間發(fā)生了一個regionoffline的錯誤,重啟服務(wù)也還是報錯,后然重新formatnamenode,deletedatanode上數(shù)據(jù),重啟發(fā)現(xiàn)還有datanode沒有起來,ssh上去發(fā)現(xiàn)java進程死了
浪費了1個多小時,仔細(xì)想了一下HTable分散到各個HRegionServer上的各子表,一臺datanode掛了,當(dāng)有數(shù)據(jù)請求時,連不上,所以報regionoffline錯誤
為什么hbase讀取的performance那么差?我單個讀取11m的文件需要14000milliseconds,而hdfs真?zhèn)€文件目錄的讀取才14188milliseconds
DBMSorHBase-butdousallafavorandjustkeepthepathinthemetadata，看來,hbase不合適存放二進制文件,存放圖片這樣的application還是hdfs更合適了。
a:重新測試了幾遍,包括重啟hbase,hdfs,hbase的讀取速度還是和原先沒大差別
b:刪除原有數(shù)據(jù),重新寫入后,再測試讀發(fā)現(xiàn),小文件的讀取效率搞了很多
fileSize(byte)1(ms)2(ms)3(ms)
12341140117501110911718
708474625610672
82535787878
55296476247
這樣就是說讀cache有較大的性能提升,在data數(shù)量不是非常大的時候,瓶頸是在讀取速度上,100k一下的數(shù)據(jù)讀取效率還是可以的,花費時間基本上和要讀取的data的長度成正比
但是之前的效率為什么沒有變?難道不能cache從磁盤讀取的數(shù)據(jù)?
然后試著讀取了最先放入的一批文件中的幾個,現(xiàn)在還是很慢,重復(fù)b的操作后效率提升了。原因可能是系統(tǒng)在創(chuàng)建row'sclunmdata的時候打上了cache標(biāo)志,cache適合clunm系統(tǒng)綁定在一起的,hbase啟動的時候會把打了cache標(biāo)志的colunm數(shù)據(jù)讀到memory中.
所以在我執(zhí)行altertableofferchangeimage_bigIN_MEMORY之前所創(chuàng)建的數(shù)據(jù)都沒有cache標(biāo)志,此cache不是像其他的cache,啟動的時候不做load,訪問后再cache,這樣一來,cache的數(shù)據(jù)愈多必然造成啟動速度的加慢。本節(jié)關(guān)于測試Hbase和Hadoop操作文件的性能介紹完畢，請關(guān)注本節(jié)其他相關(guān)報道。
【編輯推薦】
- Hdoop/Hbase文件配置方法詳解
- HadoopHBase實現(xiàn)配置簡單的單機環(huán)境
- Hadoop集群與Hadoop性能優(yōu)化
- Hadoop 從Yahoo向Google的技術(shù)轉(zhuǎn)折
- 深入剖析Hadoop HBase
