對提高HBase寫效能的一些思考

以下為使用Hbase一段時間的三個思考，由於在記憶體充足的情況下hbase能提供比較滿意的讀效能，因此寫效能是思考的重點。希望讀者提出不同意見討論

1 autoflush=false的影響

    無論是官方還是很多blog都提倡為了提高hbase的寫入速度而在應用程式碼中設定autoflush=false，然後lz認為在線上應用中應該謹慎進行該設定。原因如下：

    a autoflush=false的原理是當客戶端提交delete或put請求時，將該請求在客戶端快取，直到資料超過2M(hbase.client.write.buffer決定)或使用者執行了hbase.flushcommits()時才向regionserver提交請求。因此即使htable.put()執行返回成功，也並非說明請求真的成功了。假如還沒有達到該快取而client崩潰，該部分資料將由於未傳送到regionserver而丟失。這對於零容忍的線上服務是不可接受的。

    b autoflush=true雖然會讓寫入速度下降2-3倍，但是對於很多線上應用來說這都是必須開啟的，也正是hbase為什麼讓它預設值為true的原因。當該值為true時，每次請求都會發往regionserver,而regionserver接收到請求後第一件事就是寫hlog，因此對io的要求是非常高的，為了提高hbase的寫入速度，應該儘可能高地提高io吞吐量，比如增加磁碟、使用raid卡、減少replication因子數等

2 hbase.hregion.max.filesize應該設定多少合適 
    hbase中hfile的預設最大值(hbase.hregion.max.filesize)是256MB，而google的bigtable論文中對tablet的最大值也推薦為100-200MB，這個大小有什麼祕密呢？ 
    眾所周知hbase中資料一開始會寫入memstore，當memstore滿64MB以後，會flush到disk上而成為storefile。當storefile數量超過3時，會啟動compaction過程將它們合併為一個storefile。這個過程中會刪除一些timestamp過期的資料，比如update的資料。而當合並後的storefile大小大於hfile預設最大值時，會觸發split動作，將它切分成兩個region。 
    lz進行了持續insert壓力測試，並設定了不同的hbase.hregion.max.filesize，根據結果得到如下結論：值越小，平均吞吐量越大，但吞吐量越不穩定；值越大，平均吞吐量越小，吞吐量不穩定的時間相對更小。

    為什麼會這樣呢？推論如下：

    a 當hbase.hregion.max.filesize比較小時，觸發split的機率更大，而split的時候會將region offline，因此在split結束的時間前，訪問該region的請求將被block住，客戶端自我block的時間預設為1s。當大量的region同時發生split時，系統的整體訪問服務將大受影響。因此容易出現吞吐量及響應時間的不穩定現象 
    b 當hbase.hregion.max.filesize比較大時，單個region中觸發split的機率較小，大量region同時觸發split的機率也較小，因此吞吐量較之小hfile尺寸更加穩定些。但是由於長期得不到split，因此同一個region內發生多次compaction的機會增加了。compaction的原理是將原有資料讀一遍並重寫一遍到hdfs上，然後再刪除原有資料。無疑這種行為會降低以io為瓶頸的系統的速度，因此平均吞吐量會受到一些影響而下降。 
    綜合以上兩種情況，hbase.hregion.max.filesize不宜過大或過小，256MB或許是一個更理想的經驗引數。對於離線型的應用，調整為128MB會更加合適一些，而線上應用除非對split機制進行改造，否則不應該低於256MB 

3 從效能的角度談table中family和qualifier的設定 
    對於傳統關係型資料庫中的一張table，在業務轉換到hbase上建模時，從效能的角度應該如何設定family和qualifier呢？ 
    最極端的，可以每一列都設定成一個family，也可以只有一個family，但所有列都是其中的一個qualifier，那麼有什麼區別呢？ 
    family越多，那麼獲取每一個cell資料的優勢越明顯，因為io和網路都減少了，而如果只有一個family，那麼每一次讀都會讀取當前rowkey的所有資料，網路和io上會有一些損失。 
    當然如果要獲取的是固定的幾列資料，那麼把這幾列寫到一個family中比分別設定family要更好，因為只需一次請求就能拿回所有資料。 
    以上是從讀的方面來考慮的，那麼寫呢？可以參考一下這篇文章： 
http://hbase.apache.org/book/number.of.cfs.html 
    首先，不同的family是在同一個region下面。而每一個family都會分配一個memstore，所以更多的family會消耗更多的記憶體。 
    其次,目前版本的hbase，在flush和compaction都是以region為單位的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中只有很少的資料也會觸發flush而生成小檔案。這樣就增加了compaction發生的機率，而compaction也是以region為單位的，這樣就很容易發生compaction風暴從而降低系統的整體吞吐量。 
    第三，由於hfile是以family為單位的，因此對於多個family來說，資料被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導致該region的體積比較大，由於balance是以region的數目而不是大小為單位來進行的，因此可能會導致balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的線上服務。 
    上述第三點的好處對於線上應用來說是明顯的，而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。 
     因此對於寫比較多的系統，如果是離線應該，我們儘量只用一個family好了，但如果是線上應用，那還是應該根據應用的情況合理地分配family。