HBase 寫入優化

1、Hbase 寫入慢時的集羣異常指標

         關於hbase寫入優化的文章不少，這裏主要記錄下，生產hbase集羣針對寫入的一次優化過程。

hbase寫入慢時，從hbase集羣監控到的一些指標  -hbase 採用HDP 2.6 ，Hbase  -1.1.2

• HBase的吞吐量 達到一個峯值以後，瞬間降低，沒法穩定 ，對應的Grafana 面板-RPC Received bytes/s   
• hbase 每臺服務器的寫入條數不均衡 ，對應監控面板 --Num Write Requests /s
• hbase的member store 一直維持在較小的數據，遠沒有達到機器 設置的 讀寫內容的比例，好比 讀寫內容各站0.4,  對應監控面板-Memstore Size

    基於此 任務 目前的寫入慢，並不是集羣硬件配置形成，而是hbase集羣參數設計等設置有問題。

2、從新梳理了hbase了 寫入流程 
     

    hbase 寫入流程，這裏就不在追溯，以上是根據理解，本身畫的寫入流程圖 。能夠查詢的資料較多，這裏推薦幾個地址

     hbase 社區 http://hbase.group/
     w3c:https://www.w3cschool.cn/hbase_doc/hbase_doc-vxnl2k1n.html
    牛人博客：https://www.iteblog.com/archives/category/hbase/

3、參數優化

     基於以上，優化的思路主要分爲以下     

• 利用分佈式集羣優點，確保請求負載均衡
• 集羣的RegionServer 在某些狀況下會阻止數據的寫入，儘可能減小這種狀況的發生
• 提升RegionServer 處理外部請求的能力
• 減小客戶端和服務端ipc,請求的次數,能夠批量寫入的採用批量寫入
• 增長hbaserest 端並行執行的能力

  3.1  利用分佈式集羣優點，確保請求負載均衡

•   建立預分區

         結合具體數據的RowKey特徵建立預分區，注意：若是rowkey 業務數據爲GUID，此時要注意guid 的首字母已經作了限制 即0-9 a-f 此時建立再多的分區，起做用的僅是0-9 a-f 開頭的分區

        create 'Monitor_RowDataMapping6','d', SPLITS => ['HSF.Response.Receive|', 'HSF.Response.Sent|', 'Teld.SQL|','HSF.Request.Time|', 'HSF.Request.Count|',                   'HSF.Request.Receive|','HSF.Request.Sent|','Teld.Boss|','Teld.Core|','Teld.Redis|','Teld.WebApi|','TeldSG.Invoke|']

• rowkey的均衡
  • 經常使用的方法：rowkey的哈希、rowkey的逆轉、 固然 配套的查詢也要作響應的修改

    3.2 減小集羣阻止寫入的頻率和時間

•         根據數據靈活調整WAL的持久化等級 --固然容許regionserver 重啓以後數據能夠丟一部分
   WAL默認的等級爲同步,會阻塞數據的寫入,通常的持久化等級採用異步便可

   對於寫入量很大的監控數據不在寫入wal,alter 'Monitor_RowData', METHOD => 'table_att', DURABILITY => 'SKIP_WAL‘

          

• 調整 hbase.hstore.blockingStoreFiles 的大小，默認值爲7， 生產環境調整到100000
       Memstore 在flush前,會進行storeFile的文件數量校驗，若是大於設定值,則阻止這個Memsore的數據寫入，等待其餘線程將storeFile進行合併，爲了建設合併的機率，建設寫入的阻塞,提升該參數值

• 因爲region split 期間,大量的數據不能讀寫,防止對大的region進行合併形成數據讀寫的時間較長,調整對應的參數,
  若是region 大小大於20G，則region 不在進行split
      hbase.hstore.compaction.max.size 調整爲20G 默認爲 Long.MAX_VALUE（9223372036854775807）

• region server在寫入時會檢查每一個region對應的memstore的總大小是否超過了memstore默認大小的2倍(hbase.hregion.memstore.block.multiplier決定)，
  若是超過了則鎖住memstore不讓新寫請求進來並觸發flush，避免產生OOM
     hbase.hregion.memstore.block.multiplier  生產爲8 默認爲2

• 調整 hbase.hstore.blockingStoreFiles 的大小，默認值爲7， 生產環境調整到100000  

  Memstore 在flush前,會進行storeFile的文件數量校驗，若是大於設定值,則阻止這個Memsore的數據寫入，
  等待其餘線程將storeFile進行合併，爲了建設合併的機率，建設寫入的阻塞,提升該參數值

• 增長hlog 同步到磁盤的線程個數
   hbase.hlog.asyncer.number 調整大10  默認爲5

• 寫入數據量比較大的狀況下，避免region中過多的待刷新的memstore,增長memstore的刷新線程個數
    hbase.hstore.flusher.count 調整到20 默認爲1

    3.3   增長RegionServer 服務端的處理能力

•  針對目前每次寫入的數據量變大，調整服務端處理請求的線程數量  

            hbase.regionserver.handler.count  默認值爲10  調整到400

     3.4 客戶端請求參數設置

•  增長hbrest 並行處理的線程個數 ---寫入部分是hbrest 服務寫入

            hbase.rest.threads.max 調整到400

•  採用hbase的批量寫入    hbase.client.write.buffer  修改成5M