• HBase讀資料流程：

前置關鍵詞描述：

  • Block Cache ：讀快取，快取上一次讀的資料，整個ReginServer只有一個
  • MemStore ：寫快取，快取上一次寫的資料，每個Store有一個
  • WAL： 預寫入日誌

讀取資料流程：

  • 1.請求zk 查詢meta表的地址
  • 2.根據meta表的地址查詢rowkey屬於哪個reginserver的哪個regin，元資料快取到MetaCache
  • 3.先去BlockCache 和MemStore查詢，找不到才去storeFile找，如果在storeFile 查詢到，就快取到BlockCache裡

HBase寫資料流程：

寫資料流程：

  • 1.請求zk 查詢meta表的地址
  • 2.根據meta表的地址查詢rowkey屬於哪個reginserver的哪個regin，元資料快取到MetaCache
  • 3.先寫WAL，再寫MemStore，寫入MemStore就返回了，
  • 如果MemStore記憶體不夠，會flush storeFile檔案，然後合併多個storeFile

注： Hbase的寫流程比讀流程效率高，因為寫流程只需要寫入記憶體，讀流程先讀記憶體，如果讀不到，還需要讀磁碟檔案。

HBase的flush（刷寫） 機制：

刷寫條件：

  • 1.MemStore大小達到128M
  • 2.時間超過1小時
  • 3.Reginserver的所有Memstore大小達到reginserver佔用的堆記憶體大小的40%

　注：　上述條件預設每10s檢查一次

為防止檢查之前達到刷寫條件，會觸發阻塞機制.

阻塞機制觸發條件：

  • Memstore達到512M
  • Reginserver的所有Memstore大小達到堆記憶體的0.95*0.4

避免阻塞機制的解決方案：

如果出現這種情況，可以增大memstore大小，增大reginserver的堆記憶體大小。

Compact合併機制：

minor compact 小合併：　　　

檔案被選中條件：

  • 1. 待合併檔案數量大於3
  • 2.待合併檔案數量 小於10
  • 3.檔案大小小於128M的檔案一定會加入
  • 4.排除特別大的檔案

合併觸發條件：

  • 1.menstore flush
  • 2.定期檢查，預設10s

Major compact：

  • 合併所有的HFile，預設7天執行一次，生產中預設關閉
  • 手動：major_compact 表名

　　注意：真正的刪除是在這一步進行

Region 拆分機制：

IncreasingToUpperBoundRegionSplitPolicy：

0.94版本~2.0版本預設切分策略：

切分策略稍微有點複雜，總體看和ConstantSizeRegionSplitPolicy思路相同，一個region大小大於設

置閾值就會觸發切分。但是這個閾值並不像ConstantSizeRegionSplitPolicy是一個固定的值，而是會

在一定條件下不斷調整，調整規則和region所屬表在當前regionserver上的region個數有關係.

region split的計算公式是：

regioncount^3 * 128M * 2，當region達到該size的時候進行split

例如：

第一次split：1^3 * 256 = 256MB

第二次split：2^3 * 256 = 2048MB

第三次split：3^3 * 256 = 6912MB

第四次split：4^3 * 256 = 16384MB > 10GB，因此取較小的值10GB

後面每次split的size都是10GB了

SteppingSplitPolicy：

　　2.0版本預設切分策略，其它版本參考百度：

這種切分策略的切分閾值又發生了變化，相比 IncreasingToUpperBoundRegionSplitPolicy 簡單了

一些，依然和待分裂region所屬表在當前regionserver上的region個數有關係，如果region個數等於

1，

切分閾值為flush size（128M） * 2，否則為MaxRegionFileSize（10GB）。這種切分策略對於大叢集中的大表、小表會

比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不會再產生大量的小region，而是

適可而止。

Hbase 預分割槽：

　　為了負載均衡，提高讀寫效率，否則剛開始讀寫都在一個機器上進行。

　　通常解決負載均衡問題，還有以下解決方案：

  • 給row key 加字首
  • 對row key 進行hash
  • 反轉

Region 合併：

　　Region的合併不是為了效能，而是出於維護的目的。

通過Merge類冷合併Region：

  • 需要先關閉hbase叢集
  • 需求：需要把student表中的2個region資料進行合併：

　　　　student,,1593244870695.10c2df60e567e73523a633f20866b4b5.

　　　　student,1000,1593244870695.0a4c3ff30a98f79ff6c1e4cc927b3d0d.

這裡通過org.apache.hadoop.hbase.util.Merge類來實現，不需要進入hbase shell，直接執行（需要 先關閉hbase叢集）：

hbase org.apache.hadoop.hbase.util.Merge student \

student,,1595256696737.fc3eff4765709e66a8524d3c3ab42d59. \

student,aaa,1595256696737.1d53d6c1ce0c1bed269b16b6514131d0.

通過online_merge熱合並Region：

  • 不需要關閉hbase叢集，線上進行合併。
與冷合併不同的是，online_merge的傳參是Region的hash值，而Region的hash值就是Region名稱的最

後那段在兩個.之間的字串部分。

需求：需要把lagou_s表中的2個region資料進行合併：

student,,1587392159085.9ca8689901008946793b8d5fa5898e06. \

student,aaa,1587392159085.601d5741608cedb677634f8f7257e000.

需要進入hbase shell：

merge_region

'c8bc666507d9e45523aebaffa88ffdd6','02a9dfdf6ff42ae9f0524a3d8f4c7777'

RowKey 設計：

  • RowKey長度原則

    • rowkey是一個二進位制碼流，可以是任意字串，最大長度64kb，實際應用中一般為10-100bytes， 以byte[]形式儲存，一般設計成定長。
    • 建議越短越好，不要超過16個位元組  設計過長會降低memstore記憶體的利用率和HFile儲存資料的效率。
  • RowKey雜湊原則
    • 建議將rowkey的高位作為雜湊欄位，這樣將提高資料均衡分佈在每個RegionServer，以實現負載均 衡的機率。
  • RowKey唯一原則
    • 必須在設計上保證其唯一性
  • RowKey排序原則
    • HBase的Rowkey是按照ASCII有序設計的，我們在設計Rowkey時要充分利用這點

scan使用的時候注意：setStartRow，setEndRow 限定範圍， 範圍越小，效能越高。