前言

本文致力于從架構原理、集群部署、性能優化與使用技巧等方面，闡述在如何基于HBase構建容納大規模資料、支撐高并發、毫秒回應、穩定高效的OLTP實時系統，

一、架構原理

1.1 基本架構

從上層往下可以看到HBase架構中的角色分配為：

Client——>Zookeeper——>HMaster——>RegionServer——>HDFS

Client

Client是執行查詢、寫入等對HBase表資料進行增刪改查的使用方，可以是使用HBase Client API撰寫的程式，也可以是其他開發好的HBase客戶端應用，

Zookeeper

Zookeeper同HDFS一樣，HBase使用Zookeeper作為集群協調與管理系統，

在HBase中其主要的功能與職責為：

存盤整個集群HMaster與RegionServer的運行狀態
實作HMaster的故障恢復與自動切換
為Client提供元資料表的存盤資訊

HMaster、RegionServer啟動之后，將會在Zookeeper上注冊并創建節點（/hbasae/master 與 /hbase/rs/*），同時 Zookeeper 通過Heartbeat的心跳機制來維護與監控節點狀態，一旦節點丟失心跳，則認為該節點宕機或者下線，將清除該節點在Zookeeper中的注冊資訊，
當Zookeeper中任一RegionServer節點狀態發生變化時，HMaster都會收到通知，并作出相應處理，例如RegionServer宕機，HMaster重新分配Regions至其他RegionServer，以保證集群整體可用性，
當HMaster宕機時（Zookeeper監測到心跳超時），Zookeeper中的 /hbasae/master 節點將會消失，同時Zookeeper通知其他備用HMaster節點，重新創建 /hbasae/master 并轉化為active master，

協調程序示意圖如下：

除了作為集群中的協調者，Zookeeper還為Client提供了 hbase:meta 表的存盤資訊，

客戶端要訪問HBase中的資料，只需要知道Zookeeper集群的連接資訊，訪問步驟如下：

客戶端將從Zookeeper（/hbase/meta-region-server）獲得 hbase:meta 表存盤在哪個RegionServer，快取該位置資訊
查詢該RegionServer上的 hbase:meta 表資料，查找要操作的 rowkey所在的Region存盤在哪個RegionServer中，快取該位置資訊
在具體的RegionServer上，根據rowkey檢索該Region資料

可以看到，客戶端操作資料程序并不需要HMaster的參與，通過Zookeeper間接訪問RegionServer來操作資料，

第一次請求將會產生3次RPC，之后使用相同的rowkey時，客戶端將直接使用快取下來的位置資訊，直接訪問RegionServer，直至快取失效（Region失效、遷移等原因），

通過Zookeeper的讀寫流程如下：

hbase:meta 表存盤了集群中所有Region的位置資訊，
表結構如下：

rowkey規則：${表名},${起始鍵},${region時間戳}.${encode編碼}.

列簇：info

列

state：Region狀態，正常情況下為 OPEN

serverstartcode：RegionServer啟動的13位時間戳

server：所在RegionServer 地址和埠，如cdh85-47:16020

sn：server和serverstartcode組成，如cdh85-47:16020,1549491783878

seqnumDuringOpen：Region在線時長的二進制串

regioninfo：region的詳細資訊，如：ENCODED、NAME、STARTKEY、ENDKEY等

ENCODED：基于${表名},${起始鍵},${region時間戳}生成的32位md5字串，
region資料存盤在hdfs上時使用的唯一編號，可以從meta表中根據該值定位到hdfs中的具體路徑，
rowkey中最后的${encode編碼}就是 ENCODED 的值，其是rowkey組成的一部分，

NAME：與ROWKEY值相同

STARTKEY：該region的起始鍵

ENDKEY：該region的結束鍵

簡單總結Zookeeper在HBase集群中的作用如下：

對于服務端，是實作集群協調與控制的重要依賴，
對于客戶端，是查詢與操作資料必不可少的一部分，

HMaster

HBase整體架構中HMaster的功能與職責如下：
管理RegionServer，監聽其狀態，保證集群負載均衡且高可用，
管理Region，如新Region的分配、RegionServer宕機時該節點Region的分配與遷移
接收客戶端的DDL操作，如創建與洗掉表、列簇等資訊
權限控制

如我們前面所說的，HMaster 通過 Zookeeper 實作對集群中，各個 RegionServer 的監控與管理，在RegionServer 發生故障時，可以發現節點宕機，并轉移 Region 至其他節點，以保證服務的可用性，

但是HBase的故障轉移并不是無感知的，相反故障轉移程序中，可能會直接影響到線上請求的穩定性，造成段時間內的大量延遲，

在分布式系統的 CAP定理中（Consistency一致性、Availability可用性、Partition tolerance磁區容錯性），分布式資料庫基本特性都會實作P，但是不同的資料庫對于A和C各有取舍，

如HBase選擇了C，而通過Zookeeper這種方式來輔助實作A（雖然會有一定缺陷），而Cassandra選擇了A，通過其他輔助措施實作了C，各有優劣，

對于HBase集群來說，HMaster是一個內部管理者，除了DDL操作并不對外（客戶端）開放，因而HMaster的負載是比較低的，

造成HMaster壓力大的情況，可能是集群中存在多個（兩個或者三個以上）HMaster，備用的Master會定期與Active Master通信，以獲取最新的狀態資訊，以保證故障切換時自身的資料狀態是最新的，因而Active Master可能會收到大量來自備用Master的資料請求，

RegionServer

RegionServer在HBase集群中的功能與職責：

根據HMaster的region分配請求，存放和管理Region
接受客戶端的讀寫請求，檢索與寫入資料，產生大量IO
一個RegionServer中存盤并管理者多個Region，是HBase集群中真正存盤資料、接受讀寫請求的地方，是HBase架構中最核心、同時也是最復雜的部分，

RegionServer內部結構圖如下：

BlockCache

BlockCache為RegionServer中的讀快取，一個RegionServer共用一個BlockCache，

RegionServer處理客戶端讀請求的程序：

在BlockCache中查詢是否命中快取，
快取未命中，則定位到存盤該資料的Region，
檢索Region Memstore中，是否有所需要的資料，
Memstore中未查得，則檢索Hfiles，
任一程序查詢成功，則將資料回傳給客戶端，并快取至BlockCache，

BlockCache有兩種實作方式，有不同的應用場景，各有優劣：

On-Heap的LRUBlockCache

優點：直接從Java堆內記憶體獲取，回應速度快，
缺陷：容易受GC影響，回應延遲不穩定，特別是在堆記憶體巨大的情況下，
適用于：寫多讀少型、小記憶體等場景，

Off-Heap的BucketCache

優點：無GC影響，延遲穩定
缺陷：從堆外記憶體獲取資料，性能略差于堆內記憶體
適用于：讀多寫少型、大記憶體等場景

我們將在「性能優化」一節中具體討論如何判斷應該使用哪種記憶體模式，

WAL

全稱 Write Ahead Log ，是 RegionServer 中的預寫日志，

所有寫入資料，默認情況下，都會先寫入WAL中，以保證RegionServer宕機重啟之后，可以通過WAL來恢復資料，一個RegionServer中共用一個WAL，

RegionServer的寫流程如下：

將資料寫入WAL中
根據TableName、Rowkey和ColumnFamily將資料寫入對應的Memstore中
Memstore通過特定演算法將記憶體中的資料刷寫成Storefile寫入磁盤，并標記WAL sequence值
Storefile定期合小檔案

WAL會通過日志滾動的操作，定期對日志檔案進行清理（已寫入HFile中的資料可以清除），對應HDFS上的存盤路徑為 /hbase/WALs/${HRegionServer_Name} ，

Region

一個Table由一個或者多個Region組成，一個Region中可以看成是Table按行切分且有序的資料塊，每個Region都有自身的StartKey、EndKey，

一個Region由一個或者多個Store組成，每個Store存盤該Table對應Region中一個列簇的資料，相同列簇的列，存盤在同一個Store中，

同一個Table的Region，會分布在集群中不同的RegionServer上，以實作讀寫請求的負載均衡，故，一個RegionServer中，將會存盤來自不同Table的N多個Region，

Store、Region與Table的關系可以表述如下：多個Store（列簇）組成Region，多個Region（行資料塊）組成完整的Table，

其中，Store由Memstore（記憶體）、StoreFile（磁盤）兩部分組成，

在RegionServer中，Memstore可以看成指定Table、Region、Store的寫快取（正如BlockCache小節中所述，Memstore還承載了一些讀快取的功能），以RowKey、Column Family、Column、Timestamp進行排序，如下圖所示：

寫請求到RegionServer之后，并沒有立刻寫入磁盤中，而是先寫入記憶體中的Memstore（記憶體中資料丟失問題，可以通過回放WAL解決）以提升寫入性能，

Region中的Memstore，會根據特定演算法，將記憶體中的資料，將會刷寫到磁盤，形成Storefile檔案，因為資料在Memstore中為已排序，順序寫入磁盤性能高、速度快，

在這種 Log-Structured Merge Tree架構模式下，隨機寫入HBase擁有相當高的性能，

Memstore刷磁盤形成的StoreFile，以HFile格式，存盤HBase的KV資料于HDFS之上，

HDFS

HDFS為HBase提供底層存盤系統，通過HDFS的高可用、高可靠等特性，保障了HBase的資料安全、容災與備份，

1.2寫資料與 Memstore Flush

對于客戶端來說，將請求發送到需要寫入的RegionServer中，等待RegionServer寫入WAL、Memstore之后，即回傳寫入成功的ack信號，
對于RegionServer來說，寫入的資料，還需要經過一系列的處理步驟，

首先我們知道Memstore是在記憶體中的，將資料放在記憶體中，可以得到優異的讀寫性能，但是同樣也會帶來麻煩：

記憶體中的資料如何防止斷電丟失
將資料存盤于記憶體中的代價是高昂的，空間總是有限的

對于第一個問題，雖然可以通過WAL機制在重啟的時候，進行資料回放，但是對于第二個問題，則必須將記憶體中的資料持久化到磁盤中，

在不同情況下，RegionServer通過不同級別的刷寫策略，對Memstore中的資料進行持久化，根據觸發刷寫動作的時機，以及影響范圍，可以分為不同的幾個級別：

Memstore級別：Region中任意一個MemStore達到了 hbase.hregion.memstore.flush.size 控制的上限（默認128MB），會觸發Memstore的flush，
Region級別：Region中Memstore大小之和達到了 hbase.hregion.memstore.block.multiplier *， hbase.hregion.memstore.flush.size 控制的上限（默認 2 * 128M = 256M），會觸發Memstore的flush，
RegionServer級別：Region Server中所有Region的Memstore大小總和達到了 hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize 控制的上限（默認0.4，即RegionServer 40%的JVM記憶體），將會按Memstore由大到小進行flush，直至總體Memstore記憶體使用量低于 hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize 控制的下限（默認0.38，即RegionServer 38%的JVM記憶體），
RegionServer中HLog數量達到上限：將會選取最早的 HLog對應的一個或多個Region進行flush（通過引數hbase.regionserver.maxlogs配置），
HBase定期flush：確保Memstore不會長時間沒有持久化，默認周期為1小時，為避免所有的MemStore，在同一時間都進行flush導致的問題，定期的flush操作，有20000左右的隨機延時，
手動執行flush：用戶可以通過shell命令 flush ‘tablename’或者flush ‘region name’，分別對一個表或者一個Region進行flush，

Memstore刷寫時，會阻塞線上的請求回應，由此可以看到，不同級別的刷寫，對線上的請求，會造成不同程度影響的延遲：

對于Memstore與Region級別的刷寫，速度是比較快的，并不會對線上造成太大影響
對于RegionServer級別的刷寫，將會阻塞發送到該RegionServer上的所有請求，直至Memstore刷寫完畢，會產生較大影響

所以在Memstore的刷寫方面，需要盡量避免出現RegionServer級別的刷寫動作，

資料在經過Memstore刷寫到磁盤時，對應的會寫入WAL sequence的相關資訊，已經持久化到磁盤的資料，就沒有必要通過WAL記錄的必要，

RegionServer會根據這個sequence值，對WAL日志進行滾動清理，防止WAL日志數量太多，RegionServer啟動時，加載太多資料資訊，
同樣，在Memstore的刷寫策略中，可以看到，為了防止WAL日志數量太多，達到指定閾值之后，將會選擇WAL記錄中，最早的一個或者多個Region進行刷寫，

1.3讀資料與 Bloom Filter

經過前文的了解，我們現在可以知道HBase中一條資料完整的讀取操作流程中，Client會和Zookeeper、RegionServer等發生多次互動請求，

基于HBase的架構，一條資料可能存在RegionServer中的三個不同位置：

對于剛讀取過的資料，將會被快取到BlockCache中
對于剛寫入的資料，其存在Memstore中
對于之前已經從Memstore刷寫到磁盤的，其存在于HFiles中

RegionServer接收到的一條資料查詢請求，只需要從以上三個地方，檢索到資料即可，

在HBase中的檢索順序依次是：BlockCache -> Memstore -> HFiles，

其中，BlockCache、Memstore都是直接在記憶體中進行高性能的資料檢索，

而HFiles則是真正存盤在HDFS上的資料：

檢索HFiles時會產生真實磁盤的IO操作
Memstore不停刷寫的程序中，將會產生大量的HFile

如何在大量的HFile中快速找到所需要的資料呢？

為了提高檢索HFiles的性能，HBase支持使用 Bloom Fliter 對HFiles進行快讀定位，

Bloom Filter（布隆過濾器）是一種資料結構，常用于大規模資料查詢場景，其能夠快速判斷一個元素一定不在集合中，或者可能在集合中，
Bloom Filter由 一個長度為m的位陣列和 k個哈希函式組成，

其作業原理如下：

原始集合寫入一個元素時，Bloom Filter同時將該元素經過k個哈希函式映射成k個數字，并以這些數字為下標，將 位陣列 中對應下標的元素標記為1
當需要判斷一個元素是否存在于原始集合中，只需要將該元素經過同樣的 k個哈希函式得到k個數字

取 位陣列 中對應下標的元素，如果都為1，則表示元素可能存在
如果存在其中一個元素為0，則該元素不可能存在于原始集合中

因為哈希碰撞問題，不同的元素經過相同的哈希函式之后可能得到相同的值

對于集合外的一個元素，如果經過 k個函式得到的k個數字，對應位陣列中的元素都為1，可能是該元素存在于集合中
也有可能是集合中的其他元素”碰巧“讓這些下標對應的元素都標記為1，所以只能說其可能存在

對于集合中的不同元素，如果經過k個函式得到的k個數字中，任意一個重復

位陣列 中對應下標的元素會被覆寫，此時該下標的元素不能被洗掉（即歸零）
洗掉可能會導致其他多個元素在Bloom Filter表示不「存在」

由此可見，Bloom Filter中：

位陣列的長度m越大，誤差率越小，而存盤代價越大
哈希函式的個數k越多，誤差率越小，而性能越低

HBase中支持使用以下兩種Bloom Filter：

ROW：基于 Rowkey 創建的Bloom Filter
ROWCOL：基于 Rowkey+Column 創建的Bloom Filter

兩者的區別僅僅是：是否使用列資訊作為Bloom Filter的條件，

使用ROWCOL時，可以讓指定列的查詢更快，因為其通過Rowkey與列資訊來過濾不存在資料的HFile，但是相應的，產生的Bloom Filter資料會更加龐大，
而只通過Rowkey進行檢索的查詢，即使指定了ROWCOL也不會有其他效果，因為沒有攜帶列資訊，
通過Bloom Filter（如果有的話）快速定位到當前的Rowkey資料存盤于哪個HFile之后（或者不存在直接回傳），通過HFile攜帶的 Data Block Index 等元資料資訊，可快速定位到具體的資料塊起始位置，讀取并回傳（加載到快取中），

這就是Bloom Filter在HBase檢索資料的應用場景：

高效判斷key是否存在
高效定位key所在的HFile

當然，如果沒有指定創建Bloom Filter，RegionServer將會花費比較多的力氣，一個個檢索HFile，來判斷資料是否存在，

1.4 HFile存盤格式

通過Bloom Filter快速定位到需要檢索的資料，所在的HFile之后的操作，自然是從HFile中讀出資料，并回傳，

據我們所知，HFile是HDFS上的檔案（或大或小都有可能），現在HBase面臨的一個問題，就是如何在HFile中 快速檢索獲得指定資料？

HBase隨機查詢的高性能，很大程度上取決于底層HFile的存盤格式，所以這個問題可以轉化為 HFile的存盤格式，該如何設計，才能滿足HBase 快速檢索 的需求，

生成一個HFile

Memstore記憶體中的資料，在刷寫到磁盤時，將會進行以下操作：

會先現在記憶體中創建 空的Data Block資料塊 包含 預留的Header空間，而后，將Memstore中的KVs一個個順序寫滿該Block（一般默認大小為64KB），
如果指定了壓縮或者加密演算法，Block資料寫滿之后，將會對整個資料區做相應的壓縮或者加密處理，
隨后在預留的Header區，寫入該Block的元資料資訊，如 壓縮前后大小、上一個block的offset、checksum 等，
記憶體中的準備作業完成之后，通過HFile Writer輸出流將資料寫入到HDFS中，形成磁盤中的Data Block，
為輸出的Data Block生成一條索引資料，包括 {startkey、offset、size} 資訊，該索引資料會被暫時記錄在記憶體中的Block Index Chunk中，

至此，已經完成了第一個 Data Block 的寫入作業，Memstore中的 KVs 資料，將會按照這個程序，不斷進行 寫入記憶體 中的Data Block ——> 輸出到HDFS——> 生成索引資料保存到記憶體中的Block Index Chunk 流程，

值得一提的是，如果啟用了Bloom Filter，那么 Bloom Filter Data（位圖資料）與 Bloom元資料（哈希函式與個數等）將會和 KVs 資料一樣被處理：寫入記憶體中的Block ——> 輸出到HDFS Bloom Data Block ——>生成索引資料保存到相對應的記憶體區域中，

由此我們可以知道，HFile寫入程序中，Data Block 和 Bloom Data Block 是交叉存在的，

隨著輸出的Data Block越來越多，記憶體中的索引資料Block Index Chunk也會越來越大，

達到一定大小之后（默認128KB）將會經過類似Data Block的輸出流程，寫入到HDFS中，形成 Leaf Index Block （和Data Block一樣，Leaf Index Block也有對應的Header區，保留該Block的元資料資訊），

同樣的，也會生成一條該 Leaf Index Block 對應的索引記錄，保存在記憶體中的 Root Block Index Chunk，

Root Index ——> Leaf Data Block ——> Data Block 的索引關系，類似 B+樹 的結構，得益于多層索引，HBase可以在不讀取整個檔案的情況下查找資料，

隨著記憶體中最后一個 Data Block、Leaf Index Block 寫入到HDFS，形成 HFile 的 Scanned Block Section，

Root Block Index Chunk 也會從記憶體中寫入HDFS，形成 HFile 的 Load-On-Open Section 的一部分，
至此，一個完整的HFile已經生成，如下圖所示：

檢索HFile

生成HFile之后該如何使用呢？

HFile的索引資料（包括 Bloom Filter索引和資料索引資訊）會在 Region Open 的時候被加載到讀快取中，之后資料檢索經過以下程序：

所有的讀請求，如果讀快取和Memstore中不存在，那么將會檢索HFile索引
通過Bloom Filter索引（如果有設定Bloom Filter的話）檢索Bloom Data以快速定位HFile是否存在所需資料
定位到資料可能存在的HFile之后，讀取該HFile的三層索引資料，檢索資料是否存在
存在，則根據索引中的元資料，找到具體的 Data Block 讀入記憶體，取出所需的KV資料

可以看到，在HFile的資料檢索程序中，一次讀請求，只有真正確認資料存在，且 需要讀取硬碟資料的時候，才會執行硬碟查詢操作，
同時，得益于 分層索引 與 分塊存盤，在Region Open加載索引資料的時候，再也不必和老版本（0.9甚至更早，HFile只有一層資料索引并且統一存盤）一樣加載所有索引資料到記憶體中，導致啟動緩慢甚至卡機等問題，

1.5 HFile Compaction

Bloom Filter解決了如何在大量的HFile中快速定位資料，所在的HFile檔案，雖然有了Bloom Filter的幫助，大大提升了檢索效率，但是對于RegionServer來說，要檢索的HFile數量并沒有減少，

為了再次提高HFile的檢索效率，同時避免大量小檔案的產生，造成性能低下，RegionServer會通過Compaction機制，對HFile進行合并操作，

常見的Compaction觸發方式有：

Memstore Flush檢測條件執行
RegionServer定期檢查執行
用戶手動觸發執行

Minor Compaction

Minor Compaction 只執行簡單的檔案合并操作，選取較小的HFiles，將其中的資料順序寫入新的HFile后，替換老的HFiles，

但是如何在眾多HFiles中，選擇本次Minor Compaction，要合并的檔案卻有不少講究：

首先排除掉檔案大小，大于 hbase.hstore.compaction.max.size 值的HFile
將HFiles按照檔案年齡排序（older to younger），并從older file開始選擇
如果該檔案大小 小于 hbase.hstore.compaction.min ，則加入Minor Compaction中
如果該檔案大小小于后續hbase.hstore.compaction.max 個HFile大小之和 * hbase.hstore.compaction.ratio，則將該檔案加入Minor Compaction中
掃描程序中，如果需要合并的HFile檔案數 達到 hbase.hstore.compaction.max（默認為10） 則開始合并程序
掃描結束后，如果需要合并的HFile的檔案數 大于 hbase.hstore.compaction.min（默認為3）則開始合并程序
通過 hbase.offpeak.start.hour、hbase.offpeak.end.hour 設定高峰、非高峰時期，使 hbase.hstore.compaction.ratio的值在不同時期靈活變化（高峰值1.2、非高峰值5）

可以看到，Minor Compaction不會合并過大的HFile，合并的HFile數量也有嚴格的限制，以避免產生太大的IO操作，Minor Compaction經常在Memstore Flush后觸發，但不會對線上讀寫請求造成太大延遲影響，

Major Compaction

相對于Minor Compaction 只合并選擇的一部分HFile合并、合并時只簡單合并資料檔案的特點，Major Compaction則將會把Store中的所有HFile合并成一個大檔案，將會產生較大的IO操作，

同時將會清理三類無意義資料：被洗掉的資料、TTL過期資料、版本號超過設定版本號的資料，Region Split程序中產生的Reference檔案也會在此時被清理，
Major Compaction定期執行的條件由以下兩個引數控制：

hbase.hregion.majorcompaction：默認7天
hbase.hregion.majorcompaction.jitter：默認為0.2

集群中各個RegionServer將會在 hbase.hregion.majorcompaction +- hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter 的區間浮動進行Major Compaction，以避免過多RegionServer同時進行，造成較大影響，

Major Compaction 執行時機觸發之后，簡單來說，如果當前Store中HFile的最早更新時間，早于某個時間值，就會執行Major Compaction，該時間值為 hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter ，

手動觸發的情況下將會直接執行Compaction，

Compaction的優缺點

HBase通過Compaction機制，使底層HFile檔案數，保持在一個穩定的范圍，減少一次讀請求產生的IO次數、檔案Seek次數，確保HFiles檔案檢索效率，從而實作高效處理線上請求，

如果沒有Compaction機制，隨著Memstore刷寫的資料越來越多，HFile檔案數量將會持續上漲，一次讀請求生產的IO操作、Seek檔案的次數將會越來越多，反饋到線上，就是讀請求延遲越來越大，

然而，在Compaction執行程序中，不可避免的仍然會對線上造成影響，

對于Major Compaction來說，合并程序將會占用大量帶寬、IO資源，此時線上的讀延遲將會增大，
對于Minor Compaction來說，如果Memstore寫入的資料量太多，刷寫越來越頻繁超出了HFile合并的速度，

即使不停地在合并，但是HFile檔案仍然越來越多，讀延遲也會越來越大
HBase通過 hbase.hstore.blockingStoreFiles（默認7） 來控制Store中的HFile數量
超過配置值時，將會堵塞Memstore Flush阻塞flush操作，阻塞超時時間為 hbase.hstore.blockingWaitTime
阻塞Memstore Flush操作將會使Memstore的記憶體占用率越來越高，可能導致完全無法寫入

簡而言之，Compaction機制保證了HBase的讀請求一直保持低延遲狀態，但付出的代價是Compaction執行期間大量的讀延遲毛刺和一定的寫阻塞（寫入量巨大的情況下），

1.6 Region Split

HBase通過 LSM-Tree架構提供了高性能的隨機寫，通過快取、Bloom Filter、HFile與Compaction等機制提供了高性能的隨機讀，

至此，HBase已經具備了作為一個高性能讀寫資料庫的基本條件，如果HBase僅僅到此為止的話，那么其也只是個在架構上和傳統資料庫有所區別的資料庫而已，作為一個高性能讀寫的分布式資料庫來說，其擁有近乎可以無限擴展的特性，

支持HBase進行自動擴展、負載均衡的是Region Split機制，

Split策略與觸發條件

在HBase中，提供了多種Split策略，不同的策略觸發條件各不相同，

如上圖所示，不同版本中使用的默認策略在變化，

ConstantSizeRegionSplitPolicy

固定值策略：閾值默認大小 hbase.hregion.max.filesize

優點：簡單實作

缺陷：考慮片面，小表不切分、大表切分成很多Region，線上使用弊端多

IncreasingToUpperBoundRegionSplitPolicy

非固定閾值：計算公式 min(R^2 * memstore.flush.size, region.split.size)
R為Region所在的Table,在當前RegionServer上Region的個數
最大大小 hbase.hregion.max.filesize

優點：自動適應大小表，對于Region個數多的閾值大，Region個數少的閾值小

缺陷：對于小表來說會產生很多小region

SteppingSplitPolicy:

非固定閾值：如果Region個數為1，則閾值為 memstore.flush.size * 2
否則為 region.split.size

優點：對大小表更加友好，小表不會一直產生小Region

缺點：控制力度比較粗

可以看到，不同的切分策略其實只是在尋找切分Region時的閾值，不同的策略對閾值有不同的定義，

切分點

切分閾值確認完之后，首先要做的是尋找待切分Region的切分點，

HBase對Region的切分點定義如下：

Region中最大的Store中，最大的HFile中心的block中，首個Rowkey，
如果最大的HFile只有一個block，那么不切分（沒有middle key），

得到切分點之后，核心的切分流程分為 prepare - execute - rollback 三個階段，

prepare階段

在記憶體中，初始化兩個子Region（HRegionInfo物件），準備進行切分操作，

execute階段

execute階段執行流程較為復雜，具體實施步驟為：

1	RegionServer在Zookeeper上的 /hbase/region-in-transition 節點中，標記該Region狀態為SPLITTING，
2	HMaster監聽到Zookeeper節點發生變化，在記憶體中，修改此Region狀態為RIT，
3	在該Region的存盤路徑下創建臨時檔案夾 .split
4	父Region close，flush所有資料到磁盤中，停止所有寫入請求，
5	在父Region的 .split檔案夾中，生成兩個子Region檔案夾，并寫入reference檔案 1.reference是一個特殊的檔案，體現在其檔案名與檔案內容上 2.檔案名組成：{父Region} 3.檔案內容：[splitkey]切分點rowkey，[top?]true/false，true為top上半部分，false為bottom下半部分 4.根據reference檔案名，可以快速找到對應的父Region、其中的HFile檔案、HFile切分點，從而確認該子Region的資料范圍 5.資料范圍確認完畢之后，進行正常的資料檢索流程（此時仍然檢索父Region的資料）
6	將子Region的目錄拷貝到HBase根目錄下，形成新的Region
7	父Regin通知修改 hbase:meta 表后下線，不再提供服務 1.此時并沒有洗掉父Region資料，僅在表中標記split列、offline列為true，并記錄兩個子region
8	兩個子Region上線服務
9	通知 hbase:meta 表標記兩個子Region正式提供服務

rollback階段

如果execute階段出現例外，則執行rollback操作，保證Region切分整個程序，是具備事務性、原子性的，要么切分成功、要么回到未切分的狀態，

region切分是一個復雜的程序，涉及到父region切分、子region生成、region下線與上線、zk狀態修改、元資料狀態修改、master記憶體狀態修改等多個子步驟，回滾程式，會根據當前進展到哪個子階段，清理對應的垃圾資料，

為了實作事務性，HBase設計了使用狀態機（SplitTransaction類），來保存切分程序中的每個子步驟狀態，這樣一來，一旦出現例外，系統可以根據當前所處的狀態，決定是否回滾，以及如何回滾，

但是目前實作中，中間狀態是存盤在記憶體中，因此一旦在切分程序中，RegionServer宕機或者關閉，重啟之后，將無法恢復到切分前的狀態，即Region切分處于中間狀態的情況，也就是RIT，

由于Region切分的子階段很多，不同階段，解決RIT的處理方式也不一樣，需要通過hbck工具進行，具體查看，并分析解決方案，

好訊息是，HBase2.0之后提出了，新的分布式事務框架Procedure V2，將會使用HLog存盤事務中間狀態，從而保證事務處理中，宕機重啟后，可以進行回滾或者繼續處理，從而減少RIT問題產生，

父Region清理

從以上程序中我們可以看到，Region的切分程序，并不會父Region的資料到子Region中，只是在子Region中創建了reference檔案，故Region切分程序是很快的，

只有進行Major Compaction時，才會真正（順便）將資料切分到子Region中，將HFile中的kv順序讀出、寫入新的HFile檔案，

RegionServer將會定期檢查 hbase:meta 表中的split和offline為true的Region，對應的子Region，是否存在reference檔案，如果不存在則洗掉父Region資料，

負載均衡

Region切分完畢之后，RegionServer上將會存在更多的Region塊，為了避免RegionServer熱點，使請求負載均衡到集群各個節點上，HMaster將會把一個或者多個子Region移動到其他RegionServer上，

移動程序中，如果當前RegionServer繁忙，HMaster將只會修改Region的元資料資訊，至其他節點，而Region資料，仍然保留在當前節點中，直至下一次Major Compaction時進行資料移動，

至此，我們已經揭開了HBase架構與原理的大部分神秘面紗，在后續做集群規劃、性能優化與實際應用中，為什么這么調整，以及為什么這么操作，都將一一映射到HBase的實作原理上，

如果你希望了解HBase的更多細節，可以參考《HBase權威指南》，

二、集群部署

經過冗長的理論初步了解過HBase架構與作業原理之后，搭建HBase集群是使用HBase的第一個步驟，
需要注意的是，HBase集群一旦部署使用，再想對其作出調整需要付出慘痛代價（線上環境中），所以如何部署HBase集群是使用的第一個關鍵步驟，

2.1 集群物理架構

硬體混合型+軟體混合型集群：

硬體混合型：指的是該集群機器配置參差不齊，混搭結構，
軟體混合型：指的是該集群部署了一套類似CDH全家桶套餐，

如以下的軟體混合型集群狀況：

集群規模：30
部署服務：HBase、Spark、Hive、Impala、Kafka、Zookeeper、Flume、HDFS、Yarn等
硬體情況：記憶體、CPU、磁盤等參差不齊，有高配有低配，混搭結構

這個集群不管是規模、還是服務部署方式相信都是很多都有公司的「標準」配置，

那么這樣的集群有什么問題呢？

如果僅僅HBase是一個非「線上」的系統，或者充當一個歷史冷資料存盤的大資料庫，這樣的集群其實一點問題也沒有，因為對其沒有任何苛刻的性能要求，

但是如果希望HBase作為一個線上能夠承載海量并發、實時回應的系統，這個集群隨著使用時間的增加很快就會崩潰，

從硬體混合型來說，一直以來Hadoop都是以宣稱能夠用低廉、老舊的機器撐起一片天，

這確實是Hadoop的一個大優勢，然而前提是作為離線系統使用，

離線系統的定義，即跑批的系統，如：Spark、Hive、MapReduce等，沒有很強的時間要求，顯著的吞吐量大，延遲高，

因為沒有實時性要求，幾臺拖拉機跑著也沒有問題，只要最后能出結果并且結果正確就OK，

那么在我們現在的場景中，對HBase的定義已經不是一個離線系統，而是一個實時系統，

對于一個硬性要求很高的實時系統來說，如果其中幾臺老機器拖了后腿也會引起線上回應的延遲，

統一高配硬體+軟體混合型集群

既然硬體拖后腿，那么硬體升級自然是水到渠成，
現在我們有全新的高配硬體可以使用，參考如下：

集群規模：30
部署服務：HBase、Spark、Hive、Impala、Kafka、Zookeeper、Flume、HDFS、Yarn等
硬體情況：記憶體、CPU、磁盤統一高配置

這樣的集群可能還會存在什么問題呢？

從 軟體混合型 來說，離線任務最大的特點就是吞吐量特別高，瞬間讀寫的資料量，可以把IO直接撐到10G/s，最主要的影響因素，就是大型離線任務，帶動高IO，將會影響HBase的回應性能，

如果僅止步于此，那么線上的表現僅僅為短暫延遲，真正令人窒息的操作是，如果離線任務再把CPU撐爆，RegionServer節點可能會直接宕機，造成嚴重的生產影響，

存在的另外一種情況是，離線任務大量讀寫磁盤、讀寫HDFS，導致HBase IO連接例外，也會造成RegionServer例外（HBase日志反應HDFS connection timeout，HDFS日志反應IO Exception），造成線上故障，

根據觀測，集群磁盤IO到4G以上、集群網路IO 8G以上、HDFS IO 5G以上任意符合一個條件，線上將會有延遲反應，

因為離線任務運行太過強勢，導致RegionServer宕機，無法解決，那么能采取的策略，只能是重新調整離線任務的執行，使用資源、執行順序等，限制離線計算能力來滿足線上的需求，同時還要限制集群的CPU的使用率，可能出現，某臺機器CPU打滿后，整個機器假死，致服務例外，造成線上故障，

軟、硬體獨立的HBase集群

簡而言之，無論是硬體混合型還是軟體混合型集群，其可能因為各種原因帶來的延遲影響，對于一個高性能要求的HBase來說，都是無法忍受的，
所以在集群規劃初始就應該考慮到種種情況，最好使用獨立的集群部署HBase，

參考如下一組集群規模配置：

集群規模：15+5（RS+ZK）
部署服務：HBase、HDFS（另5臺虛擬Zookeeper）
硬體情況：除虛擬機外，物理機統一高配置

雖然從可用節點上來看，比之前的參考配置少了一半，但是從集群部署模式上看，最大程度保證HBase的穩定性，從根本上，分離了軟硬體對HBase所帶來的影響，將會擁有比之前兩組集群配置 更穩定的回應和更高的性能，

其他硬體推薦

網卡：網卡是容易產生瓶頸的地方，有條件建議使用雙萬兆網卡
磁盤：沒有特殊要求，空間越大越好，轉速越高越好
記憶體：不需要大容量記憶體，建議32-128G（詳見下文）
CPU：CPU核數越多越好，HBase本身壓縮資料、合并HFile等都需要CPU資源，
電源：建議雙電源冗余

另外值得注意的是，Zookeeper節點建議設定5個節點，5個節點能保證Leader快速選舉，并且最多可以允許2個節點宕機的情況下正常使用，

硬體上可以選擇使用虛擬機，因為zk節點本身消耗資源并不大，不需要高配機器，但是5個虛擬節點不能在一個物理機上，防止物理機宕機影響所有zk節點，

2.2 安裝與部署

以CDH集群為例安裝HBase，
使用ansible自動化腳本工具進行安裝操作：

# 獲取安裝腳本，上傳相關安裝軟體包至服務器（JDK、MySQL、CM、CDH等）
yum install -y git
git clone https://github.com/chubbyjiang/cdh-deploy-robot.git
cd cdh-deploy-robot
# 編輯節點主機名
vi hosts
# 修改安裝配置項
vi deploy-robot.cnf
# 執行
sh deploy-robot.sh install_all

安裝腳本，將會執行配置SSH免密登錄、安裝軟體、作業系統優化、Java等開發環境初始化、MySQL安裝、CM服務安裝、作業系統性能測驗等程序，
腳本操作說明見：CDH集群自動化部署工具，
等待cloudera-scm-server行程起來后，在瀏覽器輸入 ip:7180 進入CM管理界面部署HDFS、HBase組件即可，

三、性能優化

HBase集群部署完畢運行起來之后，看起來一切順利，但是所有東西都處于「初始狀態」中，

我們需要根據軟硬體環境，針對性地對HBase進行調優設定，以確保其能夠以最完美的狀態運行，在當前集群環境中，盡可能發揮硬體的優勢，

為了方便后續配置項計算說明，假設我們可用的集群硬體狀況如下：

總記憶體：256G
總硬碟：1.8T * 12 = 21.6T
可分配記憶體：256 * 0.75 = 192G
HBase可用記憶體空間：192 * 0.8 = 153G（20%留給HDFS等其他行程）
可用硬碟空間：21.6T * 0.85 = 18.36T

3.1 Region規劃

對于Region的大小，HBase官方檔案推薦單個在10G-30G之間，單臺RegionServer的數量，控制在20-300之間（當然，這僅僅是參考值），
Region過大過小都會有不良影響：

過大的Region

優點：遷移速度快、減少總RPC請求

缺點：compaction的時候資源消耗非常大、可能會有資料分散不均衡的問題

過小的Region

優點：集群負載平衡、HFile比較少,compaction影響小

缺點：遷移或者balance效率低、頻繁flush導致頻繁的compaction、維護開銷大

規劃Region的大小與數量時可以參考以下演算法：

0. 計算HBase可用磁盤空間（單臺RegionServer）

1. 設定region最大與最小閾值，region的大小在此區間選擇，如10-30G

2. 設定最佳region數（這是一個經驗值），如單臺RegionServer 200個

3. 從region最小值開始，計算 HBase可用磁盤空間 / (region_size * hdfs副本數) = region個數

4. 得到的region個數如果 > 200，則增大region_size（step可設定為5G），
繼續計算直至找到region個數最接近200的region_size大小

5. region大小建議不小于10G

例如：

當前可用磁盤空間為18T，選擇的region大小范圍為10-30G，最佳region個數為300，
那么最接近最佳Region個數300的 region_size 值為30G，

得到以下配置項：

hbase.hregion.max.filesize=30G
單節點最多可存盤的Region個數約為300

3.2 記憶體規劃

我們知道RegionServer中的BlockCache有兩種實作方式：

LRUBlockCache：On-Heap
BucketCache：Off-Heap

這兩種模式的詳細說明可以參考 CDH官方檔案，

為HBase選擇合適的記憶體模式以及根據記憶體模式計算相關配置項是調優中的重要步驟，

首先我們可以根據可用記憶體大小來判斷使用哪種記憶體模式，

先看超小記憶體（假設8G以下）和超大記憶體（假設128G以上）兩種極端情況：

對于超小記憶體來說，即使可以使用BucketCache來利用堆外記憶體，但是使用堆外記憶體的主要目的，是避免GC時不穩定的影響，堆外記憶體的效率是要比堆內記憶體低的，由于記憶體總體較小，即使讀寫快取都在堆內記憶體中，GC時也不會造成太大影響，所以可以直接選擇LRUBlockCache，
對于超大記憶體來說，在超大記憶體上使用LRUBlockCache，將會出現我們所擔憂的情況：GC時，對線上造成很不穩定的延遲影響，這種場景下，應該盡量利用堆外記憶體作為讀快取，減小堆內記憶體的壓力，所以可以直接選擇BucketCache，

在兩邊的極端情況下，我們可以根據記憶體大小，選擇合適的記憶體模式，那么如果記憶體大小，在合理、正常的范圍內該如何選擇呢？

此時我們應該主要關注業務應用的型別：

當業務主要為寫多讀少型應用時，寫快取利用率高，應該使用LRUBlockCache盡量提高堆內寫快取的使用率，
當業務主要為寫少讀多型應用時，讀快取利用率高（通常也意味著需要穩定的低延遲回應），應該使用BucketCache盡量提高堆外讀快取的使用率，
對于不明確或者多種型別混合的業務應用，建議使用BucketCache，保證讀請求的穩定性同時，堆內寫快取效率并不會很低，
當前HBase可使用的記憶體高達153G，故將選擇BucketCache的記憶體模型，來配置HBase，該模式下能夠最大化利用記憶體，減少GC影響，對線上的實時服務較為有利，

得到配置項：
hbase.bucketcache.ioengine=offheap: 使用堆外快取

確認使用的記憶體模式之后，接下來將通過計算確認 JavaHeap、對外讀快取、堆內寫快取、LRU元資料等記憶體空間具體的大小，

記憶體與磁盤比

討論具體配置之前，我們從 HBase集群規劃 引入一個Disk / JavaHeap Ratio的概念，來幫助我們設定記憶體相關的引數，

理論上我們假設 最優情況下硬碟維度下的Region個數和 JavaHeap維度下的Region個數相等，

相應的計算公式為：

硬碟容量維度下Region個數： DiskSize / (RegionSize ＊ ReplicationFactor)
JavaHeap維度下Region個數： JavaHeap * HeapFractionForMemstore / (MemstoreSize / 2 )

其中：

RegionSize：Region大小，配置項：hbase.hregion.max.filesize
ReplicationFactor：HDFS的副本數，配置項：dfs.replication
HeapFractionForMemstore：JavaHeap寫快取大小，即RegionServer記憶體中Memstore的總大小，配置項：hbase.regionserver.global.memstore.lowerLimit
MemstoreSize：Memstore刷寫大小，配置項：hbase.hregion.memstore.flush.size

現在我們已知條件 硬碟維度和JavaHeap維度相等，求 1 bytes的JavaHeap大小需要搭配多大的硬碟大小？
已知：
DiskSize / (RegionSize ＊ ReplicationFactor) = JavaHeap * HeapFractionForMemstore / (MemstoreSize / 2 )
求：DiskSize / JavaHeap

進行簡單的交換運算可得：
DiskSize / JavaHeap = （RegionSize / MemstoreSize） * ReplicationFactor * HeapFractionForMemstore * 2

以HBase的默認配置為例：
RegionSize: 10G
MemstoreSize: 128M
ReplicationFactor: 3
HeapFractionForMemstore: 0.4

計算：
（10G / 128M） * 3 * 0.4 * 2 = 192

即理想狀態下，RegionServer上 1 bytes的Java記憶體大小，需要搭配192bytes的硬碟大小最合適，

套用到當前集群中，HBase可用記憶體為152G，在LRUBlockCache模式下，對應的硬碟空間需要為153G * 192 = 29T，這顯然是比較不合理的，

在BucketCache模式下，當前 JavaHeap、HeapFractionForMemstore 等值還未確定，我們會根據這個計算關系，和已知條件，對可用記憶體進行規劃和調整，以滿足合理的記憶體/磁盤比，

已知條件：
記憶體模式：BucketCache
可用記憶體大小：153G
可用硬碟大小：18T
Region大小：30G
ReplicationFactor：3

未知變數：
JavaHeap
MemstoreSize
HeapFractionForMemstore

記憶體布局

在計算位置變數的具體值之前，我們有必要了解一下當前使用的記憶體模式中對應的記憶體布局，
BucketCache模式下，RegionServer的記憶體劃分如下圖：

簡化版：

寫快取

從架構原理中我們知道，Memstore有4種級別的Flush，需要我們關注的是 Memstore、Region和RegionServer級別的刷寫，

其中Memstore和Region級別的刷寫，并不會對線上造成太大影響，但是需要控制其閾值和刷寫頻次來進一步提高性能，

而RegionServer級別的刷寫，將會阻塞請求，直至刷寫完成，對線上影響巨大，需要盡量避免，

得到以下配置項：

hbase.hregion.memstore.flush.size=256M: 控制的Memstore大小默認值為128M，太過頻繁的刷寫，會導致IO繁忙，重繪佇列阻塞等，設定太高也有壞處，可能會較為頻繁的觸發RegionServer級別的Flush，這里設定為256M，
hbase.hregion.memstore.block.multiplier=3: 控制的Region flush上限默認值為2，意味著一個Region中，最大同時存盤的Memstore大小為2 * MemstoreSize ，如果一個表的列族過多，將頻繁觸發，該值視情況調整，

現在我們設定兩個經驗值變數：

RegionServer總記憶體中，JavaHeap的占比=0.35
JavaHeap最大大小=56G：超出此值表示GC有風險

計算得JavaHeap的大小為 153 * 0.35 = 53.55 ，沒有超出預期的最大JavaHeap，如果超過最大期望值，則使用最大期望值代替，得JavaHeap大小為53G，

現在JavaHeap、MemstoreSize已知，可以得到唯一的位置變數 HeapFractionForMemstore 的值為 0.48 ，
得到以下配置項：

RegionServer JavaHeap堆疊大小: 53G
hbase.regionserver.global.memstore.upperLimit=0.58: 整個RS中Memstore最大比例，比lower大5-15%
hbase.regionserver.global.memstore.lowerLimit=0.48: 整個RS中Memstore最小比例
寫快取大小為 53 * 0.48 = 25.44G

讀快取配置

當前記憶體資訊如下：

A 總可用記憶體：153G

J JavaHeap大小：53G
W 寫快取大小：25.44G
R1 LRU快取大小：？

R2 BucketCache堆外快取大小：153 - 53 = 100G

因為讀快取由堆內的LRU元資料與堆外的資料快取組成，兩部分占比一般為 1:9（經驗值），
而對于總體的堆內記憶體，存在以下限制，如果超出此限制，則應該調低比例：

LRUBlockCache + MemStore < 80% * JVM_HEAP

即 LRUBlockCache + 25.44 < 53 * 0.8
可得R1的最大值為16.96G
總讀快取：R = R1 + R2
R1:R2 = 1:9
R1 = 11G < 16G
R = 111G

配置堆外快取涉及到的相關引數如下：

hbase.bucketcache.size=111 * 1024M: 堆外快取大小，單位為M
hbase.bucketcache.percentage.in.combinedcache=0.9: 堆外讀快取所占比例，剩余為堆內元資料快取大小
hfile.block.cache.size=0.15: 校驗項，+upperLimit需要小于0.8

現在，我們再來計算 Disk / JavaHeap Ratio 的值，檢查JavaHeap記憶體與磁盤的大小是否合理：
RegionSize / MemstoreSize * ReplicationFactor * HeapFractionForMemstore * 2
30 * 1024 / 256 * 3 * 0.48 * 2 = 345.6
53G * 345.6 = 18T <= 18T

至此，已得到HBase中記憶體相關的重要引數：

RegionServer JavaHeap堆疊大小: 53G
hbase.hregion.max.filesize=30G
hbase.bucketcache.ioengine=offheap
hbase.hregion.memstore.flush.size=256M
hbase.hregion.memstore.block.multiplier=3
hbase.regionserver.global.memstore.upperLimit=0.58
hbase.regionserver.global.memstore.lowerLimit=0.48
hbase.bucketcache.size=111 * 1024M
hbase.bucketcache.percentage.in.combinedcache=0.9
hfile.block.cache.size=0.15

3.3 合并與切分

HFile合并

Compaction程序中，比較常見的優化措施是：

Major Compaction
停止自動執行
增大其處理執行緒數

Minor Compaction
增加Memstore Flush大小
增加Region中最大同時存盤的Memstore數量

配置項如下：

# 關閉major compaction，定時在業務低谷執行，每周一次
hbase.hregion.majorcompaction=0
# 提高compaction的處理閾值
hbase.hstore.compactionThreshold=6
# 提高major compaction處理執行緒數
hbase.regionserver.thread.compaction.large=5
# 提高阻塞memstore flush的hfile檔案數閾值
hbase.hstore.blockingStoreFiles=100
hbase.hregion.memstore.flush.size=256M
hbase.hregion.memstore.block.multiplier=3

Major Compaction 腳本

關閉自動compaction之后手動執行腳本的代碼示例：

#!/bin/bash
if [ $# -lt 1 ]
then
    echo "Usage: <table key>"
    exit 1
fi
TMP_FILE=tmp_tables
TABLES_FILE=tables.txt
key=$1
echo "list" | hbase shell > $TMP_FILE
sleep 2
sed '1,6d' $TMP_FILE | tac | sed '1,2d' | tac | grep $key > $TABLES_FILE
sleep 2
for table in $(cat $TABLES_FILE); do
  date=`date "+%Y%m%d %H:%M:%S"`
        echo "major_compact '$table'" | hbase shell
  echo "'$date' major_compact '$table'" >> /tmp/hbase-major-compact.log
        sleep 5
done
rm -rf $TMP_FILE
rm -rf $TABLES_FILE
echo "" >> /tmp/hbase-major-compact.log

Region切分

在架構原理中我們知道，Region多有種切分策略，在Region切分時，將會有短暫時間內的Region下線無服務，Region切分完成之后的Major Compaction中，將會移動父Region的資料到子Region中，HMaster為了集群整體的負載均衡，可能會將子Region分配到其他RegionServer節點，

從以上描述中可以看到，Region的切分行為，其實是會對線上的服務請求，帶來一定影響的，

Region切分設定中，使用默認配置，一般不會有太大問題，但是有沒有 保證資料表負載均衡的情況下，Region不進行切分行為？

有一種解決方案是使用 預磁區 + 固定值切分策略，可以一定程度上，通過預估資料表數量，以及Region個數，從而在一段時間內，抑制Region不產生切分，

假設我們可以合理的預判到一個表的當前總資料量為150G，每日增量為1G，當前Region大小為30G，
那么我們建表的時候，至少要設定 (150 + 1 * 360) / 30 = 17 個磁區，如此一來，一年內（360天）該表的資料增長，都會落到17個Region中，而不再切分，

當然對于一個不斷增長的表，除非時間段設定的非常長，否則總有發生切分的一天，如果無限制的延長時間段，則會在一開始，就產生大量的空Region，這對HBase是極其不友好的，所以時間段是一個需要合理控制的閾值，

在hbase-site.xml中配置Region切分策略為ConstantSizeRegionSplitPolicy：
hbase.regionserver.region.split.policy=org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy

3.4 回應優化

HBase服務端

高并發情況下，如果HBase服務端處理執行緒數不夠，應用層將會收到HBase服務端，拋出的無法創建新執行緒的例外，從而導致應用層執行緒阻塞，
可以釋放調整HBase服務端配置以提升處理性能：

#  Master處理客戶端請求最大執行緒數   
hbase.master.handler.count=256
# RS處理客戶端請求最大執行緒數，如果該值設定過大，則會占用過多的記憶體，導致頻繁的GC，或者出現OutOfMemory
hbase.regionserver.handler.count=256
# 客戶端快取大小，默認為2M  
hbase.client.write.buffer=8M
# scan快取一次獲取資料的條數，太大也會產生OOM
hbase.client.scanner.caching=100

另外，以下兩項中，默認設定下超時太久、重試次數太多，一旦應用層連接不上HBse服務端將會進行近乎無限的重試，長連接無法釋放，新請求不斷進來，從而導致執行緒堆積應用假死等，影響比較嚴重，可以適當減少：
hbase.client.retries.number=3
hbase.rpc.timeout=10000

HDFS

適當增加處理執行緒等設定：

dfs.datanode.handler.count=64
dfs.datanode.max.transfer.threads=12288
dfs.namenode.handler.count=256
dfs.namenode.service.handler.count=256

同時，對于HDFS的存盤設定也可以做以下優化：

# 可以配置多個，擁有多個元資料備份
dfs.name.dir
# 配置多個磁盤與路徑，提高并行讀寫能力
dfs.data.dir
# dn同時處理檔案的上限，默認為256，可以提高到8192
dfs.datanode.max.xcievers

應用層（客戶端）

之前我們說到，HBase為了保證CP，在A的實作上做了一定的妥協，導致HBase出現故障，并轉移的程序中，會有較大的影響，

對于應用服務層來說，保證服務的穩定性是最重要的，為了避免HBase可能產生的問題，應用層應該采用 讀寫分離 的模式，來最大程度保證自身穩定性，

應用層讀寫分離

可靠的應用層應使用 讀寫分離 的模式提高回應效率與可用性：

讀寫應用應該分別屬于不同的服務實體 ，避免牽一發而動全身
對于寫入服務，資料異步寫入redis或者kafka佇列，由下游消費者同步至HBase，回應性能十分優異
需要處理資料，寫入失敗的事務處理與重寫機制
對于讀取服務，如果一個RS掛了，一次讀請求，經過若干重試和超時，可能會持續幾十秒甚至更久，由于和寫入服務分離，可以做到互不影響
最好使用快取層，來緩解RS宕機問題，對于至關重要的資料，先查快取，再查HBase（見下文）

在應用層的代碼中，同樣有需要注意的小TIPS：

如果在Spring中，將HBaseAdmin配置為Bean加載，則需配置為懶加載，避免在啟動時，鏈接HMaster失敗，導致啟動失敗，從而無法進行一些降級操作，
scanner使用后及時關閉，避免浪費客戶端和服務器的記憶體
查詢時指定列簇或者指定要查詢的列限定掃描范圍
Put請求可以關閉WAL，但是優化不大
最后，可以適當調整一下 連接池 設定：

# 組態檔加載為全域共享，可提升tps
setInt(“hbase.hconnection.threads.max”, 512); 
setInt(“hbase.hconnection.threads.core”, 64);

3.5 使用快取層

即使我們經過大量的準備、調優與設定，在真實使用場景中，隨著HBase中承載的資料量越來越大、請求越來越多、并發越來越大，HBase不可避免的會有一些「毛刺」問題，

如果你現在已經通過HBase，解決了大部分的線上資料存盤與訪問問題，但是有一小部分的資料，需要提供最快速的回應、最低的延遲，由于HBase承載的東西太多，總是有延遲比較高的回應，此時需要怎么解決？

其實，對所有資料庫軟體來說，都會存在這樣的場景，于是，類似關系型資料庫中的資料庫拆分等策略，也是可以應用到HBase上的，

或者是將最關鍵、最熱點的資料，使用 獨立的HBase集群 來處理，或者是使用諸如 Redis等更高性能的快取軟體，其核心思想就是，將最關鍵的業務資料獨立存盤，以提供最優質的服務，這個服務統稱為快取層，

3.6 其他配置

hbase-env.sh 的 HBase 客戶端環境高級配置代碼段
配置了G1垃圾回收器和其他相關屬性：

-XX:+UseG1GC 
-XX:InitiatingHeapOccupancyPercent=65 
-XX:-ResizePLAB 
-XX:MaxGCPauseMillis=90  
-XX:+UnlockDiagnosticVMOptions 
-XX:+G1SummarizeConcMark 
-XX:+ParallelRefProcEnabled 
-XX:G1HeapRegionSize=32m 
-XX:G1HeapWastePercent=20 
-XX:ConcGCThreads=4 
-XX:ParallelGCThreads=16  
-XX:MaxTenuringThreshold=1 
-XX:G1MixedGCCountTarget=64 
-XX:+UnlockExperimentalVMOptions 
-XX:G1NewSizePercent=2 
-XX:G1OldCSetRegionThresholdPercent=5

hbase-site.xml 的 RegionServer 高級配置代碼段（安全閥）
手動split region配置

<property>
    <name>hbase.regionserver.wal.codec</name>
    <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
</property>
<property>
    <name>hbase.region.server.rpc.scheduler.factory.class</name>
    <value>org.apache.hadoop.hbase.ipc.PhoenixRpcSchedulerFactory</value>
    <description>Factory to create the Phoenix RPC Scheduler that uses separate queues for index and metadata updates</description>
</property>
<property>
    <name>hbase.rpc.controllerfactory.class</name>
    <value>org.apache.hadoop.hbase.ipc.controller.ServerRpcControllerFactory</value>
    <description>Factory to create the Phoenix RPC Scheduler that uses separate queues for index and metadata updates</description>
</property>
<property>
    <name>hbase.regionserver.thread.compaction.large</name>
    <value>5</value>
</property>
<property>
    <name>hbase.regionserver.region.split.policy</name>
    <value>org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy</value>
</property>

四、使用技巧

4.1 建表規約

Rowkey規范

如無特殊情況，長度應控制在64位元組內，

充分分析業務需求后，確認需要查詢的維度欄位，

get請求，則rowkey散列處理，

scan請求，rowkey前綴維度散列后，后續維度依照查詢順序或者權重拼接（視具體情況決定是否散列處理），
各個欄位都保持相同長度以支持左對齊的部分鍵掃描，
scan形式的資料表中，需要提前統計，單個scan可掃描出的最大數量，

列簇規范

如無特殊情況，一個表中只有一個列簇，統一使用info命名，
如果需要1以上的列簇，則原則上，一次請求的資料，不可跨列簇存盤，多不超過3個列簇，
示例：NAME =>'info'

壓縮

統一使用SNAPPY壓縮，
示例：COMPRESSION => 'SNAPPY'

版本

默認版本數為3，前期存盤空間緊張的情況下，設定為1，
示例：VERSIONS => 1

布隆過濾器

視情情況使用，主要針對get查詢提高性能，
kv示例：BLOOMFILTER => 'ROW'，根據rowkey中的資訊，生成布隆過濾器資料，
kv+col示例：BLOOMFILTER => 'ROWCOL'，根據rowkey+列資訊生成布隆過濾器，針對get+指定列名的查詢，產生的過濾器檔案會比ROW大，

預磁區

預磁區需要通過評估整體表資料量來確認，當前hbase集群region塊大小為30G，

歷史大增量小的資料：給定的預磁區數，足夠支撐該表，永遠（或者相當長的時間內）不split，即更新的所有資料，將進入已存在的region中，以減少split與compaction造成的影響，
歷史小增量大的資料：預磁區個數，需滿足歷史資料等分存盤，并支撐未來一段時間內（一個月以上）的增量資料，

預磁區區間計算：屬性相同的表中，隨機取出部分樣本資料（rowkey維度欄位），將樣本轉換成rowkey之后排序，并以樣本個數/預磁區個數為步長，取預磁區個數個rowkey組成預磁區區間，
預磁區代碼示例：

/**
    * hbase region預磁區工具
    *
    * @param filePath    樣本檔案路徑
    * @param numOfSPlits 預磁區個數
    **/
  def rowkeySplitedArr(filePath: String, numOfSPlits: Int) = {
    val file = Source.fromFile(filePath).getLines()
    val res = file.map {
      line =>
        val arr = line.split("_")
        val card = arr(0)
        val name = arr(1)
        MathUtil.MD5Encrypt32(card) + MathUtil.MD5Encrypt32(card)
    }.toList.sorted
    val count = res.length / numOfSPlits
    var str = ""
    for (i <- 0 until numOfSPlits) {
      str += s"\'${res(i * count)}\',"
    }
    println(str.substring(0, str.length - 1))
  }

4.2 客戶端使用

服務端配置完成之后，如何更好的使用HBase集群，也需要花點心思測驗與調整，
以Spark作為HBase讀寫客戶端為例，

批量查詢

Spark有對應的API，可以批量讀取HBase資料，但是使用程序比較繁瑣，這里安利一個小組件Spark DB Connector，批量讀取HBase的代碼可以這么簡單：

val rdd = sc.fromHBase[(String, String, String)]("mytable")
      .select("col1", "col2")
      .inColumnFamily("columnFamily")
      .withStartRow("startRow")
      .withEndRow("endRow")
done！

實時查詢

以流式計算為例，Spark Streaming中，我們要實時查詢HBase只能通過HBase Client API（沒有隊友提供服務的情況下），
那么HBase Connection每條資料創建一次，肯定是不允許的，效率太低，對服務壓力比較大，并且ZK的連接數，會暴增影響服務，

比較可行的方案是每個批次創建一個鏈接（類似for each Partiton中，每個磁區創建一個鏈接，磁區中資料共享鏈接），但是這種方案也會造成部分連接浪費、效率低下等，

如果可以做到一個Streaming中，所有批次、所有資料，始終復用一個連接池是最理想的狀態，

Spark中提供了Broadcast，這個重要工具可以幫我們實作這個想法，只要將創建的HBase Connection廣播出去，所有節點就都能復用，但是真實運行代碼時，你會發現HBase Connection是不可序列化的物件，無法廣播，，，

其實利用scala的lazy關鍵字可以繞個彎子來實作：

//實體化該物件，并廣播使用
class HBaseSink(zhHost: String, confFile: String) extends Serializable {
  //延遲加載特性
  lazy val connection = {
    val hbaseConf = HBaseConfiguration.create()
    hbaseConf.set(HConstants.ZOOKEEPER_QUORUM, zhHost)
    hbaseConf.addResource(confFile)
    val conn = ConnectionFactory.createConnection(hbaseConf)
    sys.addShutdownHook {
      conn.close()
    }
    conn
  }
}

在Driver程式中，實體化該物件并廣播，在各個節點中取廣播變數的value進行使用，

廣播變數只在具體呼叫value的時候，才會去創建物件，并copy到各個節點，而這個時候被序列化的物件，其實是外層的HBaseSink，當在各個節點上，具體呼叫connection，進行操作的時候，Connection才會被真正創建（在當前節點上），從而繞過了HBase Connection無法序列化的情況（同理也可以推導RedisSink、MySQLSink等），

這樣一來，一個Streaming Job，將會使用同一個資料庫連接池，在Structured Streaming中的for each Write也可以直接應用，

批量寫入

同理安利組件

rdd.toHBase("mytable")
      .insert("col1", "col2")
      .inColumnFamily("columnFamily")
      .save()

這里邊其實對HBase Client的Put介面包裝了一層，但是當線上有大量實時請求，同時線下又有大量資料需要更新時，直接這么寫會對線上的服務造成沖擊，具體表現可能為持續一段時間的短暫延遲，嚴重的甚至可能會把RS節點整掛，

大量寫入的資料帶來具體大GC開銷，整個RS的活動都被阻塞了，當ZK來監測心跳時，發現無回應，就將該節點列入宕機名單，而GC完成后，RS發現自己“被死亡”了，那么就干脆自殺，這就是HBase的“朱麗葉死亡”，

這種場景下，使用bulkload是最安全、快速的，唯一的缺點是帶來的IO比較高，

大批量寫入更新的操作，建議使用bulkload工具來實作，

實時寫入

理同，實時查詢，可以使用創建的Connection做任何操作，

結束語

我們從HBase的架構原理出發，接觸了HBase大部分的核心知識點，
理論基礎決定上層建筑，有了對HBase的總體認知，在后續的集群部署、性能優化，以及實際應用中都能夠比較游刃有余，
知其然而之所以然，保持對技術原理的探索，不僅能學習到，其中許多令人驚嘆的設計與操作，最重要的是，能夠真正在業務應用中充分發揮其應有的性能，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/157715.html

標籤：AI

上一篇：分布式鏈路追蹤技術適?場景和技術核?思想

下一篇：2020-10-04：java中GC Root 物件有哪些？

如何基于HBase構建容納大規模資料、支撐高并發、毫秒回應、穩定高效的OLTP實時系統

前言

一、架構原理

1.1 基本架構

Client

Zookeeper

HMaster

RegionServer

BlockCache

WAL

Region

HDFS

1.2寫資料 與 Memstore Flush

1.3讀資料 與 Bloom Filter

1.4 HFile存盤格式

生成一個HFile

檢索HFile

1.5 HFile Compaction

Minor Compaction

Major Compaction

Compaction的優缺點

1.6 Region Split

Split策略與觸發條件

切分點

二、集群部署

2.1 集群物理架構

硬體混合型+軟體混合型集群：

統一高配硬體+軟體混合型集群

軟、硬體獨立的HBase集群

2.2 安裝與部署

三、性能優化

3.1 Region規劃

3.2 記憶體規劃

記憶體與磁盤比

記憶體布局

寫快取

讀快取配置

3.3 合并與切分

HFile合并

Major Compaction 腳本

Region切分

3.4 回應優化

HBase服務端

HDFS

應用層（客戶端）

應用層讀寫分離

3.5 使用快取層

3.6 其他配置

四、使用技巧

4.1 建表規約

Rowkey規范

列簇規范

壓縮

版本

布隆過濾器

預磁區

4.2 客戶端使用

批量查詢

實時查詢

批量寫入

實時寫入

結束語

1.2寫資料與 Memstore Flush

1.3讀資料與 Bloom Filter