HBase是一個高性能、面向列、可伸縮的開源分布式NoSQL數據庫，是Google Bigtable的開源實現。?

HBase的思想和應用和傳統的RDBMS，NoSQL等有比較大的區別，這篇文章從HBase的架構和關鍵的Rowkey設計入手，快速學習相關應用。

?

一、 HBase設計特性

HBase概述

HBase是一個構建在HDFS上的分布式列存儲系統，將數據按照表、行和列進行存儲，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用服務器，來增加計算和存儲能力。

HBase與HDFS區別

HDFS是Hadoop Distribute File System 的簡稱，也就是Hadoop的一個分布式文件系統。

實際應用中，Spark以及 Hadoop 的 MapReduce，可以理解為一種計算框架。

而 HDFS 可以認為是為計算框架服務的存儲層。HBase 是一種列式的分布式數據庫，類似于 Hive，HBase 底層依賴 HDFS 來作為其物理存儲。

?

二、 HBase數據模型

HBase是基于Google BigTable模型開發的，典型的key/value系統。

Hbase邏輯視圖

• RowKey：是Byte array，是表中每條記錄的“主鍵”，方便快速查找，Rowkey的設計非常重要。
• Column Family：列族，擁有一個名稱(string)，包含一個或者多個相關列
• Column：屬于某一個columnfamily，familyName:columnName，每條記錄可動態添加
• Value：Byte array

Hbase支持的操作

所有操作均是基于rowkey的；?

支持CRUD（ Create、 Read、 Update和Delete）和Scan；?

• 單行操作 Put Get Scan?

• 多行操作 Scan MultiPut?

沒有內置join操作，可使用MapReduce解決。

?

三、 HBase物理結構

Region雖然是分布式存儲的最小單元，但并不是存儲的最小單元。Region由一個或者多個Store組成，每個store保存一個columns family，每個Strore又由一個memStore和0至多個StoreFile組成，StoreFile包含HFile；memStore存儲在內存中，StoreFile存儲在HDFS上。

Region的存儲策略

• Table中所有行都按照row key的字典序排列；
• Table在行的方向上分割為多個Region；
• Region按大小分割的，每個表開始只有一個region，隨著數據增多，region不斷增大，當增大到一個閥值的時候，region就會等分會兩個新的region，之后會有越來越多的region；
• Region是Hbase中分布式存儲和負載均衡的最小單元，不同Region分布到不同RegionServer上。

HFile的結構

HFile是HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile。

除了HFile，HBase還有HLog File。

HLog File是HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence File。

?

四、 HBase設計與架構

整體架構

HBase采用Master/Slave架構搭建集群，整體架構包括HMaster節點、HRegionServer節點、ZooKeeper集群，底層的數據存儲于HDFS中，涉及到HDFS的NameNode、DataNode等。

HMaster解析

HMaster是HBase主/從集群架構中的中央節點，通常一個HBase集群存在多個HMaster節點,其中一個為Active Master，其余為Backup Master。HMaster管理HRegionServer，實現其負載均衡，負責管理和分配HRegion，比如在HRegion split時分配新的HRegion。

?

• 發現失效的Region server并重新分配其上的region
• 實現DDL操作（Data Definition Language，namespace和table的增刪改，column familiy的增刪改等）
• 管理namespace和table的元數據（實際存儲在HDFS上）
• 處理schema更新請求

?

HRegionServer解析

HRegionServer存放和管理本地HRegion，讀寫HDFS，管理Table中的數據。 Client直接通過HRegionServer讀寫數據（從HMaster中獲取元數據，找到RowKey所在的HRegion/HRegionServer后）。

• 維護master分配給他的region，處理對這些region的io請求
• 負責切分正在運行過程中變的過大的region

ZooKeeper集群

ZooKeeper是協調系統，用于存放整個HBase集群的元數據以及集群的狀態信息。 實現HMaster主從節點的failover。

HBase Client通過RPC方式和HMaster、HRegionServer通信，一個HRegionServer可以存放1000個HRegion。 底層Table數據存儲于HDFS中，而HRegion所處理的數據盡量和數據所在的DataNode在一起，實現數據的本地化，在HRegion移動(如因Split)時，需要等下一次Compact才能繼續回到本地化。

?

五、 HBase最佳實踐

?

HBase適合的場景

• 大數據量存儲，大數據量高并發操作
• 讀寫訪問均是非常簡單的操作

?

Rowkey如何設計

（1）針對查詢優化

除了全表掃描以外，HBase的查詢實現只支持兩種方式：

• get：指定rowkey獲取唯一一條記錄
• scan：按指定的條件獲得一批記錄，通過rowKey的range匹配一個范圍，然后通過多種filter在范圍內篩選

如果我們想提升查詢效率，必須在rowKey的設計上下功夫。

HBase的rowKey是基于字典排序的，具體來說是基于key的ASCII碼來排序，一般的rowkey是通過業務上的多個因素相互組合，一步步確定查找范圍。

比如時間肯定是我們應該加到rowKey里的一個查詢因子，一個開始時間跟一個截止時間就形成了一個時間段范圍，就能固定一個結果集范圍。

（2）合適的長度

rowkey是一個二進制碼流，可以是任意字符串，最大長度64kb，實際應用中一般為10-100bytes，以byte[]形式保存，一般設計成定長。

• 數據的持久化文件HFile中是按照KeyValue存儲的，如果Rowkey過長比如100個字節，在上億級別的海量數據下，會造成存儲空間的浪費
• MemStore將緩存部分數據到內存，如果Rowkey字段過長內存的有效利用率會降低，系統將無法緩存更多的數據，這會降低檢索效率
• 目前操作系統是都是64位系統，內存8字節對齊，可以控制在16個字節或者32字節等

（3）更好的散列設計

如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列字段，由程序隨機生成，低位放時間字段，這樣將提高數據均衡分布在每個RegionServer，以實現負載均衡的幾率。如果沒有散列字段，字段前綴部分直接是時間信息，大量數據數據都會集中在一個RegionServer上，造成熱點問題，降低查詢效率。

?

Region分區優化

（1）避免熱點Region

HBase中的行是按照rowkey的字典順序排序的，這種設計將相關的行以及會被一起讀取的行存取在臨近位置，便于scan。

HBase中，表會被劃分為n個Region，托管在RegionServer中，StartKey與EndKey表示這個Region維護的rowKey范圍。

默認的策略是當一個Region過大時，進行一次分裂(region-split)操作，后續的rowkey會被分配到新的Region。

明顯這種策略很容易出現熱點Region，大量訪問會使熱點region所在的單個機器響應緩慢，引起性能下降甚至region不可用，

同時會影響同一個RegionServer上的其他region，由于主機無法服務其他region的請求。

在設計Region時應該設計良好的數據訪問模式以使集群被充分，均衡的利用。

（2）預分區設計

解決熱點Region問題的一個策略就是通過對rowkey進行Hash進行預分區。

這里又設計到rowkey的設計問題，設計rowkey時盡量把前綴部分打散，可以使用隨機數等， 只要region所管理的start-end keys范圍比較隨機，那么就可以解決寫熱點問題。

更進一步，可以預估系統的容量，規劃可能的Region數量，通過一個路由算法進行負載均衡。

?

?

總結

以上是生活随笔為你收集整理的HBase应用快速学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。