對(duì)于Bigtable類型的分布式數(shù)據(jù)庫應(yīng)用來說，用戶往往會(huì)對(duì)其性能狀況有極大的興趣，這其中又對(duì)實(shí)時(shí)數(shù)據(jù)插入性能更為關(guān)注。HBase作為Bigtable的一個(gè)實(shí)現(xiàn)，在這方面的性能會(huì)如何呢？這就需要通過測(cè)試數(shù)據(jù)來說話了。
數(shù)據(jù)插入性能測(cè)試的設(shè)計(jì)場(chǎng)景是這樣的，取隨機(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í)為了簡(jiǎn)單起見，所有的數(shù)據(jù)都將只插入到一個(gè)表格的同一個(gè)Column中。
在測(cè)試之初，需要對(duì)集群進(jìn)行調(diào)優(yōu)，關(guān)閉可能大量耗費(fèi)內(nèi)存、帶寬以及CPU的服務(wù)，例如Apache的Http服務(wù)。保持集群的寧靜度。此外，為了保證測(cè)試不受干擾，Hbase的集群系統(tǒng)需要被獨(dú)立，以保證不與HDFS所在的Hadoop集群有所交叉。
那么做好一切準(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í)間不間斷的測(cè)試后，我得到了如下圖形：
這個(gè)圖形非常有特點(diǎn)，好似一條直線上，每隔一段時(shí)間就會(huì)泛起一個(gè)波浪，且兩個(gè)高峰之間必有一個(gè)較矮的波浪。高峰的間隔則呈現(xiàn)出越來越大的趨勢(shì)。而較矮的波浪恰好處于兩高峰的中間位置。
為了解釋這個(gè)現(xiàn)象，我對(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è)文件中，這個(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”決定的文件大小時(shí)（默認(rèn)是256MB，此時(shí)加上內(nèi)存刷入的數(shù)據(jù)，實(shí)際最大可能到256+64M），該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ù)（該文件大小超過了64M，最大可達(dá)到（256+64）/2=160MB），內(nèi)存中新的數(shù)據(jù)將被保存到一個(gè)重新創(chuàng)建的文件中，該文件大小將為64MB。內(nèi)存每刷新一次，region所在的目錄下就將增加一個(gè)64M的文件，直到總文件數(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ù)進(jìn)行一小段時(shí)間，直到所有的region都被切割分配完畢，Hbase才會(huì)恢復(fù)平靜并等待下一次數(shù)據(jù)從內(nèi)存寫入到HDFS的到來。
理解了上述過程，則必然對(duì)HBase的數(shù)據(jù)插入性能為何是上圖所示的曲線的原因一目了然。與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ù)見，在每?jī)蓚€(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)該提供給用戶。