HBase的讀寫流程以及優化

HBase的讀寫流程--依賴於HBase的4大組件：分別是客戶端、Zookeeper、HMaster和HRegionServer。

HBase的讀寫都是由客戶端進行發起的。首先是讀的過程：客戶端根據用戶提供的表名、行鍵去客戶端裏的緩存進行查詢，沒有查詢到，就去Zookeeper進行查詢。Zookeeper在HBase中用來存儲ROOT表的地址。HBase中有兩張重要的表，分別是ROOT表和META表，ROOT表記錄META表的region信息，而META表記錄的是用戶表的region信息。簡單來講，META表的行鍵是由Region所屬表的表名、以及該region在表中的開始行鍵和時間戳組成，列族info定義了三個列，分別是regionInfo存儲了region中開始結束行鍵，server列存儲了region所在的服務器地址，serverstartcode存儲了regionServer的狀態。

因爲META表也是一張普通的HBASE表，所以當META表的數據愈來愈多的時候，也會分裂成多個meta region，每一個meta region也會被不一樣的regionServer管理。所以就須要有一張表存儲meta region的信息，這張表就是ROOT表，ROOT表只存儲了一個region信息，那就是meta region。按照這個過程，理論上還須要一張表存儲ROOT表的信息，可是這樣就會產生無窮無盡的表存儲相似的信息，針對於這種狀況，所以HBase的開發人員認爲ROOT表數據量不會很大，所以不會數據分裂，因此就不須要其餘表存儲ROOT表的region信息了。

客戶端經過Zookeeper得到了ROOT表的地址，經過RPC鏈接到ROOT表所在的RegionServer，根據ROOT表查詢META表，而後根據用戶所提供的表名和行鍵，組成一個XXXXXXX（），經過這個行鍵去META表查詢，拿到info列族中的regionInfo和server列的值以後，根據server列的值，客戶端與RegionServer創建鏈接，將regionInfo列的數據提交給RegionServer。

 

RegionServer接收客戶端的查詢請求以後，首先建立RegionScanner對象，經過該對象定位到HRegion，而後HRegin對象建立StoreScanner，經過StoreScanner定位到HStore，HStore對象建立1個MemStoreScanner對象，這個對象負責去MemStore查詢有沒有相關數據，有則返回，沒有就建立多個StoreFileScanner對象，每一個對象不然去不一樣的HFile中查詢數據，若是找到了則返回，若是沒有就返回null。

 

HBase寫的過程：當客戶端進行put操做時，數據會自動保存到HRegion上，在HRegionServer中，找到對應要寫入的HRegion以後，數據會寫入到HLog中並同時寫入到HStore的MemStore內存中，會在內存中按照行鍵對數據進行排序，當內存中的數據達到必定閾值後，會觸發flush操做。Flush操做主要就是把MemStore內存中的數據寫入到StoreFile中，當HDFS中的StoreFile個數達到必定的閾值後，會觸發compact（合併）操做，將HDFS中全部的StoreFile合併成一個新的SotreFile，在合併的時候會按照行鍵進行排序，而且會進行版本合併和數據刪除。當StoreFile經過不斷的合併操做後，StoreFile文件會變得愈來愈大，當這個StoreFile達到必定的閾值後，會觸發Split（切分）操做，同時把當前region拆分紅兩個新的region，原有的region會下線，新的兩個region會被HMaster分配到相應的HRegionServer上，使得原來一個Region的壓力得以分流到兩個Region上，其實，HBase只是增長數據，更新和刪除操做都是compact階段作的，因此，客戶端寫入成功的標誌是HLog和MemStore中都有數據。

先寫HLog，可是若是顯示MemSotre也是沒問題的，由於MemStore的MVCC（多版本併發控制）不會向前滾動，這些變化在更新MVCC以前，Scan是沒法看到的，因此在寫入HLog以前，即便MemStore有數據，客戶端也查詢不到。

 

HBASE的優化

1. 對行鍵、列族、列名稱長度優化，HBase引入block的緣由是block中包含了不少的key/value，每一個key中包含rowkey、列族、列、時間戳，減小rowkey、列族、列的長度就能減小block的數量，不然會增長region server、region、索引、內存、查詢範圍。

2. 當進行批量處理數據時，客戶端會將數據先保存到客戶端的緩存中，HBASE默認是開啓隱式刷寫的，當關閉隱式刷寫時，put的數據也會保存到客戶端的緩存中，直到調用刷寫命令時，纔會保存到HRegion中。

3.查詢優化：

*設置scan緩存。

*查詢時指定列。

*使用完ResultScanner後及時關閉。

*查詢時儘可能使用過濾器或協處理器，減小數據量。

*將查詢頻率較高的數據緩存起來。例如緩存到redis中。

*使用HtableTool查詢。

*使用批量讀取Htable.get(List<Get>)。

4.寫入優化：

*關閉WAL日誌，若是開啓了WAL日誌，能夠修改日誌寫入hdfs的時間。(存在數據丟失的風險優化)

*設置AutoFlush爲false。(存在數據丟失的風險優化)

*Region預分區，兩種方式，hbase自帶的RegionSplitter，和本身實現，通常使用hbase自帶的。

*經過HtableTool寫入。

*使用批量寫入Htable.put(List<Put>)。

 

5.配置方面優化：

*設置RegionServer的處理線程數量，可是須要先進行測試。

*調整BlockChche或者MemStore內存大小大小，若是讀的較多則將BlockChche增大，若是寫的較多則MemStore調大。但二者之和不能超過

 一個RegionServer總內存大小的80%。(StoreFile的flush)

*調整StoreFile合併的數量限制，太少則合併次數頻繁嚴重影響性能，太大會到這查詢變慢。(StoreFile的compart)

*設置單個StoreFile的大小，調整分裂的性能。(StoreFile的spill)

6.行鍵設計：最大長度64KB

*由於hbase會的rowkey按照字節順序由小到大排序，所以須要保持rowkey鬆散性，避免單調遞增，防止出現region熱點。

*由於hbase只對rowkey創建索引，因此要保證行鍵的惟一性。

*由於行鍵是不可變的，因此在設計之初要知足業務需求。

*由於rowkey是冗餘存儲，因此只要知足以上要求，行鍵長度儘可能短。

 

7.列族設計：

*由於hbase底層是以列族爲單位存儲的，一個列族中的數據會被存放在一個磁盤文件中，因此應該將具備相同特性的列放到一個列族中。

*一個表中的列族儘可能不要太多，保持到1-2個最好。

*若是是更新頻繁而且只須要最獲取最新數據能夠設置，單元格的時間版本爲1，默認爲3(VERSION)

*能夠設置單元格的生命週期(TTL)

*隨機讀較多開啓布隆過濾器。

 

 

CAP原理

Consistency強一致性、availability可用性、partition tolerance分區容錯性，在一個大規模的分佈式服務系統中不可能同時存在。

 

C指的是更新操做成功並返回客戶端完成後,分佈式的全部節點在同一時間的數據徹底一致

A指的是讀和寫操做都能成功

P指的是節點宕機不影響服務的運行。

 

HBASE只支持CP