HBase的讀寫流程以及優化方法

本篇內容主要講解“HBase的讀寫流程以及優化方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“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

到此，相信大家對“HBase的讀寫流程以及優化方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！