建站
咨詢
售后
建站咨詢
新聞中心
對(duì)于BigTable類型的分布式數(shù)據(jù)庫應(yīng)用來說，用戶往往會(huì)對(duì)其性能狀況有極大的興趣，這其中又對(duì)實(shí)時(shí)數(shù)據(jù)插入性能更為關(guān)注。HBase作為BigTable的一個(gè)實(shí)現(xiàn)，在這方面的性能會(huì)如何呢？這就需要通過測試數(shù)據(jù)來說話了。
數(shù)據(jù)插入性能測試的設(shè)計(jì)場景是這樣的：取隨機(jī)值的Rowkey長度為2000字節(jié)，固定值的Value長度為4000字節(jié)，由于單行Row插入速度太快，系統(tǒng)統(tǒng)計(jì)精度不夠，所以將插入500行Row做一次耗時(shí)統(tǒng)計(jì)。
這里要對(duì)HBase的特點(diǎn)做個(gè)說明，首先是Rowkey值為何取隨機(jī)數(shù)，這是因?yàn)镠Base是對(duì)Rowkey進(jìn)行排序的，隨機(jī)Rowkey將被分配 到不同的region上，這樣才能發(fā)揮出分布式數(shù)據(jù)庫的性能優(yōu)點(diǎn)。而Value對(duì)于HBase來說不會(huì)進(jìn)行任何解析，其數(shù)據(jù)是否變化，對(duì)性能是不應(yīng)該有任 何影響的。同時(shí)為了簡單起見，所有的數(shù)據(jù)都將只插入到一個(gè)表格的同一個(gè)Column中。
初次分析
在測試之初，需要對(duì)集群進(jìn)行調(diào)優(yōu)，關(guān)閉可能大量耗費(fèi)內(nèi)存、帶寬以及CPU的服務(wù)（例如Apache的HTTP服務(wù)），保持集群的寧靜度。此外，為了保證測試不受干擾，HBase的集群系統(tǒng)需要被獨(dú)立，以保證不與HDFS所在的Hadoop集群有所交叉。
實(shí)驗(yàn)
那么做好一切準(zhǔn)備之后，就開始進(jìn)行數(shù)據(jù)灌入，客戶端從Zookeeper上查詢到Regionserver的地址后，開始源源不斷地向HBase的Regionserver上喂入Row。
這里，我寫了一個(gè)通過JFreeChart來實(shí)時(shí)生成圖片的程序，每3分鐘，喂數(shù)據(jù)的客戶端會(huì)將獲取到的耗時(shí)統(tǒng)計(jì)打印在一張十字坐標(biāo)圖中，這些圖又被保存在制定的Web站點(diǎn)中，并通過HTTP服務(wù)展示出來。在通過長時(shí)間不間斷的測試后，我得到了圖1。
圖1 插入Row的性能測試
圖1好似一條直線上，每隔一段時(shí)間就會(huì)泛起一個(gè)波浪，且兩個(gè)高峰之間必有一個(gè)較矮的波浪。高峰的間隔呈現(xiàn)出越來越大的趨勢(shì)，而較矮的波浪恰好處于兩高峰的中間位置。
解讀
為了解釋，我對(duì)HDFS上HBase所在的主目錄下文件，以及被插入表格的region情況進(jìn)行了實(shí)時(shí)監(jiān)控，以期發(fā)現(xiàn)這些波浪上發(fā)生了什么事情。
回溯到客戶端喂入數(shù)據(jù)的開始階段，創(chuàng)建表格，在HDFS上便被創(chuàng)建了一個(gè)與表格同名的目錄，該目錄下將出現(xiàn)第一個(gè)region，region中會(huì)以 family名創(chuàng)建一個(gè)目錄，這個(gè)目錄下才存在記錄具體數(shù)據(jù)的文件。同時(shí)在該表表名目錄下，還會(huì)生成一個(gè)“compaction.dir”目錄，該目錄將 在family名目錄下region文件超過指定數(shù)目時(shí)用于合并region。當(dāng)?shù)谝粋€(gè)region目錄出現(xiàn)時(shí)，內(nèi)存中最初被寫入的數(shù)據(jù)將被保存到該文件 中，這個(gè)間隔是由選項(xiàng)“hbase.hregion.memstore.flush.size”決定的，默認(rèn)是64MB，該region所在的 Regionserver的內(nèi)存中一旦有超過64MB的數(shù)據(jù)時(shí)，就將被寫入到region文件中。這個(gè)文件將不斷增殖，直到超過由 “hbase.hregion.max.filesize”決定的文件大?。J(rèn)是256MB，此時(shí)加上內(nèi)存刷入的數(shù)據(jù)，實(shí)際最大可能到 256MB+64MB）時(shí)，該region將被執(zhí)行split，立即被一切為二，其過程是在該目錄下創(chuàng)建一個(gè)名為“.splits”的目錄作為標(biāo)記，然后 由Regionserver將文件信息讀取進(jìn)來，分別寫入到兩個(gè)新的region目錄中，最后再將老的region刪除。這里的標(biāo)記目錄 “.splits”可以避免在split過程中發(fā)生其他操作，起到類似于多線程安全的鎖功能。在新的region中，從老的region中切分出的數(shù)據(jù)獨(dú) 立為一個(gè)文件并不再接收新的數(shù)據(jù)（該文件大小超過了64MB，最大可達(dá)到（256+64）/2=160MB）），內(nèi)存中新的數(shù)據(jù)將被保存到一個(gè)重新創(chuàng)建的 文件中，該文件大小將為64MB。內(nèi)存每刷新一次，region所在的目錄下就將增加一個(gè)64MB的文件，直到總文件數(shù)超過由 “hbase.hstore.compactionThreshold”指定的數(shù)量時(shí)（默認(rèn)為3），compaction過程就將被觸發(fā)了。在上述值為3 時(shí)，此時(shí)該region目錄下，實(shí)際文件數(shù)只有兩個(gè)，還有額外的一個(gè)正處于內(nèi)存中將要被刷入到磁盤的過程中。Compaction過程是HBase的一個(gè) 大動(dòng)作。HBase不僅要將這些文件轉(zhuǎn)移到“compaction.dir”目錄進(jìn)行壓縮，而且在壓縮后的文件超過256MB時(shí)，還必須立即進(jìn)行 split動(dòng)作。這一系列行為在HDFS上可謂是翻山倒海，影響頗大。待Compaction結(jié)束之后，后續(xù)的split依然會(huì)持續(xù)一小段時(shí)間，直到所有 的region都被切割分配完畢，HBase才會(huì)恢復(fù)平靜并等待下一次數(shù)據(jù)從內(nèi)存寫入到HDFS。
圖2 再次的數(shù)據(jù)插入測試
理解了上述過程，就必然會(huì)對(duì)HBase的數(shù)據(jù)插入性能為何是圖1所示的曲線的原因一目了然。與X軸幾乎平行的直線，表明數(shù)據(jù)正在被寫入HBase的 Regionserver所在機(jī)器的內(nèi)存中。而較低的波峰意味著Regionserver正在將內(nèi)存寫入到HDFS上，較高的波峰意味著 Regionserver不僅正在將內(nèi)存刷入到HDFS，而且還在執(zhí)行Compaction和Split兩種操作。如果調(diào)整 “hbase.hstore.compactionThreshold”的值為一個(gè)較大的數(shù)量，例如改成5，可以預(yù)見，在每兩個(gè)高峰之間必然會(huì)等間隔地出 現(xiàn)三次較低的波峰，并可預(yù)見到，高峰的高度將遠(yuǎn)超過上述值為3時(shí)的高峰高度（因?yàn)镃ompaction的工作更為艱巨）。由于region數(shù)量由少到多， 而我們插入的Row的Rowkey是隨機(jī)的，因此每一個(gè)region中的數(shù)據(jù)都會(huì)均勻的增加，同一段時(shí)間插入的數(shù)據(jù)將被分布到越來越多的region上， 因此波峰之間的間隔時(shí)間也將會(huì)越來越長。
再次理解上述論述，我們可以推斷出HBase的數(shù)據(jù)插入性能實(shí)際上應(yīng)該被分為三種情況：直線狀態(tài)、低峰狀態(tài)和高峰狀態(tài)。在這三種情況下得到的性能數(shù) 據(jù)才是最終HBase數(shù)據(jù)插入性能的真實(shí)描述。那么提供給用戶的數(shù)據(jù)該是采取哪一個(gè)呢？我認(rèn)為直線狀態(tài)由于所占時(shí)間會(huì)較長，尤其在用戶寫入數(shù)據(jù)的速度也許 并不是那么快的情況下，所以這個(gè)狀態(tài)下得到的性能數(shù)據(jù)結(jié)果更應(yīng)該提供給用戶。
圖3 圖1的數(shù)據(jù)分布圖
再度分析
前面的HBase性能深度分析，提出了一個(gè)猜想，是關(guān)于調(diào)整“hbase.hstore.compaction-Threshold”值的假設(shè)。猜 想的內(nèi)容為：如果改變?cè)撝?，例如調(diào)整為5，那么耗時(shí)圖形會(huì)在每兩個(gè)高峰之間出現(xiàn)等間隔的三次較低的波峰，并且高峰將會(huì)更加突出，超過上述值較低時(shí)的波峰高 度。
為了證明這個(gè)猜想，我將“hbase.hstore.compactionThreshold”值調(diào)整為5，并重新做了數(shù)據(jù)插入測試，一段時(shí)間后， 得到如圖2所示的性能圖形（Y軸表示耗時(shí)，X軸為插入次數(shù)，Sandy建議這里的Y軸應(yīng)該改為插入速度，但是由于前次已經(jīng)使用了耗時(shí)為Y軸，因此改變Y軸 顯示的工作只能放到下次測試中了）。
通過相比發(fā)現(xiàn)，圖1和圖2的Y軸比例尺是不同的，圖1中Y軸最大為30秒，圖2中最大為50秒。可見假設(shè)中聲稱低峰會(huì)在兩個(gè)高峰之間等間隔的出現(xiàn)3 次的現(xiàn)象的確是成立的。當(dāng)高峰出現(xiàn)第5次以后，可以從圖2看到代表耗時(shí)的點(diǎn)的高峰段已經(jīng)達(dá)到了25秒以上，而對(duì)于前次來說，高峰段基本上處于20秒左右， 由此可以認(rèn)為Compaction的壓力的確是增加了?，F(xiàn)在換一個(gè)角度來分析這一情況。我為圖1制作了一張數(shù)據(jù)分布圖（圖3），與圖2進(jìn)行比較（圖4）。
雖說第二次測試經(jīng)歷的時(shí)間不如第一次，但是基于統(tǒng)計(jì)學(xué)的觀點(diǎn)，分布圖的外形是不會(huì)受樣本容量大小影響的，因此圖3和圖4可以進(jìn)行外觀上的比較。這兩 張分布圖都是典型的正態(tài)分布圖，但又不是標(biāo)準(zhǔn)正態(tài)分布，原因在于，波峰段的數(shù)據(jù)影響了正態(tài)分布的標(biāo)準(zhǔn)性，表現(xiàn)之一在于右側(cè)的長尾，表現(xiàn)之二在于眾數(shù)所在位 置右移，以至于左側(cè)凸顯了一個(gè)小波峰。
圖4 圖2的數(shù)據(jù)分布圖
計(jì)算本次分布圖與前次分布圖中位于右側(cè)長尾部分的數(shù)據(jù)的標(biāo)準(zhǔn)差（計(jì)算公式：），我們可以得到前次右側(cè)標(biāo)準(zhǔn)差為4.10390692438，而本次右側(cè)標(biāo)準(zhǔn)差為7.12068861446，說明高峰段影響的數(shù)據(jù)右偏更為嚴(yán)重了。
從外觀上表現(xiàn)在右側(cè)長尾在整圖比例尺中的寬度和高度要大于前次分布圖中的右側(cè)長尾。這說明Compaction的壓力增大了。
推導(dǎo)到這里，我發(fā)現(xiàn)右側(cè)標(biāo)準(zhǔn)差與Compaction的壓力之間是存在顯著關(guān)系的，今后對(duì)Compaction壓力增減的估算，貌似可以轉(zhuǎn)換為對(duì)右 側(cè)標(biāo)準(zhǔn)差的計(jì)算。壓力增加的比率是否等于標(biāo)準(zhǔn)差的比值呢？這里先做一個(gè)標(biāo)記，等后面有時(shí)間再仔細(xì)思考一下這個(gè)問題。現(xiàn)在假設(shè)中的說法“高峰將會(huì)更加突出， 超過上述值較低時(shí)的波峰高度”，應(yīng)該算是被證明了。
以上論證結(jié)束之后，按照慣例還是要提出一些假設(shè)和推斷。
HBase在已經(jīng)發(fā)布的0.90.x版對(duì)Compaction和Split機(jī)制作了調(diào)整，將Split過程提到了Compaction之前，也就是 說，當(dāng)region目錄下，HFiles數(shù)目超過“hbase.hstore.compactionThreshold”指定值之 后，Regionserver會(huì)首先計(jì)算一下Compaction之后的文件大小是否會(huì)超過“hbase.hregion.max.filesize”確 定的Split上限大小，如果超過了，那么HFiles首先被切分，然后才會(huì)將切分好的文件轉(zhuǎn)移到新的region中Compaction。這樣將大大減 小Compaction的壓力，由此可以推斷，HBase的性能調(diào)優(yōu)必然與“hbase.hstore.compactionThreshold”和 “hbase.hregion.max.filesize”這兩個(gè)值的大小息息相關(guān)。理論上，可以將某次設(shè)定了確定值的實(shí)驗(yàn)中獲得的數(shù)據(jù)代入到一個(gè)特定公 式中，上述兩值作為該公式的自變量，其應(yīng)變量，即性能數(shù)據(jù)，將可以輕松地計(jì)算出來。
是否真的如此，且待進(jìn)一步的詳細(xì)測試。
本文標(biāo)題：HBase性能深度分析
當(dāng)前URL：http://www.dlmjj.cn/article/djephid.html
