HBase—>基本概念篇

1、架構

Hbase的是主從架構，經過zookeeper來保證高可用

Hbase的存儲機構是LSM

數據—①—>內存—②—>小文件—③—>大文件

①：Hbase採用了WAL預寫日誌，保證寫內存的數據不丟失，載體是Hlog
    以後就把寫的數據寫到內存裏
②：當內存的數據量達到必定的程度後，會將數據寫到磁盤中，載體是HFile，而且採用B+樹的存儲結構
③：在小文件達到必定的數量後，會觸發compact，此時會合並小文件成大文件
  （生產環境下大合併會盡可能避開使用高峯）

2、操做流程

讀數據流程

Client—①—>Zookeeper—②—>HRegionServer1 —③—>HRegionServer2
—④—>MemStore—⑤—>BlockCache—⑥—>StoreFile—⑦—>key-value

①：從Zookeeper讀取meta表位於哪臺HRegionServer上
②：去①獲取的HRegionServer中查詢meta表
  （根據命名空間、表名以及rowkey定位數據所存儲的Region以及Region所處的服務器）
③：根據②獲取的信息訪問目標HRegionServer
④：在目標HRegionServer的目標Region裏的MemStore查詢
⑤：若④沒找到，則在BlockCache中查詢
⑥：所⑤沒找到，則在目標Region裏的StoreFile中查找
⑦：如果⑥找到了，則將數據存儲在BlockCache中並根據版本組織key-val返回

寫數據流程

Client—①—>Zookeeper—②—>HRegionServer1—③—>HRegionServer2
—④—>HLog—⑤—>MemStore—⑥—>StoreFile

①：從Zookeeper讀取meta表位於哪臺HRegionServer上
②：去①獲取的HRegionServer中查詢meta表
  （根據命名空間、表名以及rowkey進行Hash，肯定數據應該存儲的Region，而且返回該Region的服務器信息）
③：去②返回的服務器進行數據寫入
④：將寫入操做先記錄在磁盤HLog中（WAL 存儲在HDFS）
⑤：再將實際的數據寫到目標Region的目標Store裏的MemStore中
⑥：當MemStore知足條件後刷寫磁盤StoreFile（存儲在HDFS）並刪除HLog
⑦：StoreFile在知足必定條件下進行compact

3、機制

1. Flush

緣由：
存儲在MemStore中的數據變多後，不只持有太多的內存資源，並且對數據恢復也很差，所以會將MemStore中的數據刷寫到磁盤文件StoreFile中

flush流程

• prepare階段：遍歷當前Region的全部MemStore，將每個MemStore中的數據集CellSkipListSet作一個快照；再新建一個CellSkipList給後期數據的寫入
  這個階段會加updateLock對寫請求阻塞，該階段比較快
• flush階段：遍歷全部MemStore，將prepare生成的快照轉爲臨時文件，該階段涉及到寫磁盤，比較耗時
• commit階段：遍歷全部MemSore，將flush階段生成的臨時文件轉到指定的ColumnFamily目錄下，而後將其添加到HSore的storefile列表中，最後清空prepare產生的快照

刷寫的條件分爲⑥種，知足任意一種都會觸發
① MemStore級別
Region中任意MemStore大小達到上限
hbase.hregion.memstore.flush.size，默認128MB
觸發：是單個MemStore刷寫仍是該Region中全部的MemStore刷寫

② Region級別
當Region中全部的MemStore佔有資源達到上限

hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默認 2* 128M = 256M

③ Server級別
當Region Server上全部Region資源超太低水位閾值
低水位閾值：低水位百分比 * RegionServer分配的MemStore資源
低水位百分比：hbase.regionserver.global.memstore.size.lower.limit（默認95%）
RegionServer的MemStore資源：hbase.regionserver.global.memstore.size (默認jvm40%)

按照佔用資源數量從大到小依次flush Region
若是寫入速度大於flush速度，致使佔用的資源到達RegionServer分配的MemStore資源，會阻塞Region Server的寫入直到資源佔用小於低水位閾值

④ HLog數量過多
當HLog的數量達到hbase.regionserver.maxlogs 設置的值後，會將最先的HLog對應的Region進行flush，以後刪除該HLog

⑤ 按期Flush
默認週期爲1小時，確保Memstore不會長時間沒有持久化
爲避免全部MemStore同時flush致使的問題，按期的flush操做有20000左右的隨機延時

⑥ 主動觸發
經過命令flush tablename或者flush regionname分別對一個表或者一個Region進行flush

問題：
每一次刷寫文件都是新的一個StoreFile嗎

2. Compact

緣由：
因爲每次MemStore知足條件都會刷寫磁盤文件Store，而且因爲Region不一樣或Region內部的Store不一樣，會刷寫不一樣的StoreFile，所以會產生大量的小文件。

影響查詢效率以及系統性能

① minor compaction

• 將部分較小/相鄰的HFile合併成更大的HFile
• 標記超過TTL、更新、刪除的數據

② major compaction

• 合併一個Store中的全部HFile爲一個HFile
• 清理超過TTL、更新/刪除、以及無效版本號的數據

3. 預分表

表建立的時候，只會默認給它生成一個Region，所以數據可能會所有寫到該Region所處的那個Region Server上，致使負載不均衡

分區的好處

• 增長數據讀寫效率
• 負載均衡
• 方便集羣容災調度Region
• 優化Map數量

分區的原理：每一個Region都有一個startRowKey和endRowKey，若讀寫數據rowKey落在該範圍，則讀寫該Region

4. Region合併

緣由：
當刪除大量的數據以後，可能會致使不少小的Region，此時最好進行合併
合併Region並不能帶來的性能的提高，只是方便管理

4、小結

1. 相同列簇的列會存儲在同一個文件裏面（加速按行讀取操做），在Region的一個StoreFile裏
2. rowkey不建議太長，Hbase的存儲是細化到了 rowkey—>每一個單元格。rowkey太大影響性能
3. HBase按照rowkey進行查找，要查找的字段儘可能放到rowkey裏。rowkey可能會致使數據熱點，rowkey根據字典序排序
4. HBase適合OLAP應用
5. 遺留問題：分佈式組件都是怎麼解決哈希映射的問題呢？