1、概念
HBase是一個分布式的NoSQL數據庫，其特點高可靠、高性能、面向列、可伸縮。
- 適合存儲大表數據 ，並且可實時讀寫大表數據。大表：表的規模可以達到數十億行以及數百萬列
- 表結構稀疏。稀疏：對於為空的列，並不占用存儲空間
- 數據底層存儲於Hadoop HDFS分布式文件系統。
- 利用ZooKeeper作為協同服務。
2、特點
HBase適合具有如下需求的應用：
- 海量數據 (TB、PB) 。
- 不需要完全擁有傳統關系型數據庫所具備的ACID特性。
- 高吞吐量。
- 需要在海量數據中實現高效的隨機讀取。
- 需要很好的性能伸縮能力。
- 能夠同時處理結構化和非結構化的數據。
ACID原則是數據庫事務正常執行的四個特性，分別指原子性、一致性、獨立性及持久性。
- 事務的原子性(Atomicity)：指一個事務要么全部執行,要么不執行。也就是說一個事務不可能只執行了一半就停止了。比如你從取款機取錢,這個事務可以分成兩個步驟：1划卡，2出錢，不可能划了卡，而錢卻沒出來.這兩步必須同時完成，要么就不完成。
- 事務的一致性(Consistency)：指事務的運行並不改變數據庫中數據的一致性.例如,完整性約束了a+b=10,一個事務改變了a,那么b也應該隨之改變。
- 獨立性(Isolation）：事務的獨立性也有稱作隔離性,是指兩個以上的事務不會出現交錯執行的狀態.因為這樣可能會導致數據不一致。
- 持久性(Durability）：事務的持久性是指事務執行成功以后,該事務所對數據庫所作的更改便是持久的保存在數據庫之中，不會無緣無故的回滾。
3、各組件
ZooKeeper為HBase集群中各進程提供分布式協作服務。各RegionServer將自己的信息注冊到Zookeeper中，主用Master據此感知各個RegionServer的健康狀態。
Client使用HBase的RPC機制與Master、RegionServer進行通信。Client與Master進行管理類通信，與RegionServer進行數據操作類通信。
RegionServer負責提供表數據讀寫等服務，是HBase的數據處理和計算單元。RegionServer一般與HDFS集群的DataNode部署在一起，實現數據的存儲功能。
HMaster，在HA模式下，包含主用Master和備用Master。
- 主用Master：負責HBase中RegionServer的管理，包括表的增刪改查；RegionServer的負載均衡，Region分布調整；Region分裂以及分裂后的Region分配；RegionServer失效后的Region遷移等。
- 備用Master：當主用Master故障時，備用Master將取代主用Master對外提供服務。故障恢復后，原主用Master降為備用。
HDFS為HBase提供高可靠的文件存儲服務，HBase的數據全部存儲在HDFS中。
Store：一個Region由一個或多個Store組成，每個Store對應圖中的一個Column Family。
MemStore：一個Store包含一個MemStore，MemStore緩存客戶端向Region插入的數據。
StoreFile：MemStore的數據flush到HDFS后成為StoreFile。
Hfile：HFile定義了StoreFile在文件系統中的存儲格式，它是當前HBase系統中StoreFile的具體實現。
Hlog：HLog日志保證了當RegionServer故障的情況下用戶寫入的數據不丟失，RegionServer的多個Region共享一個相同的Hlog。
4、Hbase存儲形式
HBase的底層數據以KeyValue的形式存在，KeyValue具有特定的格式。
- KeyValue中擁有時間戳、類型等關鍵信息。
- Key部分被用來快速的檢索一條數據記錄，Value部分用來存儲實際的用戶數據信息。
- 同一個Key值可以關聯多個Value，每一個KeyValue都擁有一個Qualifier標識。
- 支持動態增加列，容易適應數據類型和結構的變化。以塊為單元操作數據，列間、表間並無關聯關系。
- 即使是Key值相同，Qualifier也相同的多個KeyValue，也可能有多個版本，此時使用時間戳來區分，這就是同一條數據記錄的多版本。
- KeyValue型數據庫數據分區方式---按Key值連續范圍分區。
- 數據按照RowKey的范圍 (按RowKey的字典順序)，划分為一個個的子區間。每一個子區間都是一個分布式存儲的基本單元。
5、HBase緩存機制
HBase提供2種類型的緩存結構：MemStore和BlockCache。
MemStore：HBase數據先寫入HLog 之中，並同時寫入MemStore，待滿足一定條件后將MemStore中數據刷到磁盤，能提升HBase的寫性能和讀性能。
BlockCache：HBase會將一次文件查找的Block塊緩存到Cache中，以便后續同一請求或者相鄰數據查找請求，可以直接從內存中獲取，避免IO操作。
其中MemStore是寫緩存，BlockCache是讀緩存。
一個HRegionServer只有一個BlockCache，在HRegionServer啟動的時候完成BlockCache的初始化，常用的BlockCache包括LruBlockCache，以及 CombinedBlockCache（LruBlockCache + BucketCache）。
- LRUBlockCache 是HBase默認的BlockCache實現方案。實際上就是一個ConcurrentHashMap管理BlockKey到Block的映射關系，緩存Block只需要將BlockKey和對應的Block放入該HashMap中，查詢緩存就根據BlockKey從HashMap中獲取即可。
- LRUBlockCache 分層策略：Block的數據存儲在JVM 堆中，由JVM進行管理。它在邏輯上分為三個區：Single-Access、Multi-Access、In-Memory，分別占整個BlockCache的25%、50%、25%。一次隨機讀中，一個Block塊從HDFS中加載出來之后首先放入Single-Access區，后續如果有多次請求訪問到這塊數據的話，就會將這塊數據移到Multi-Access s區。而In-Memory區表示數據可以常駐內存，一般用來存放訪問頻繁、數據量小的數據，比如元數據，用戶也可以在建表的時候通過設置列族屬性IN-MEMORY= true將此列族放入In-Memory區。因此設置數據屬性InMemory= true需要非常謹慎，確保此列族數據量很小且訪問頻繁，否則有可能會將hbase.meta元數據擠出內存，嚴重影響所有業務性能。無論哪個區，系統都會采用嚴格的Least-Recently-Used算法，當BlockCache總量達到一定閾值之后就會啟動淘汰機制，最少使用的Block會被置換出來，為新加載的Block預留空間。
- LRU淘汰算法實現：系統在每次cache block時將BlockKey和Block放入HashMap后都會檢查BlockCache總量是否達到閾值，如果達到閾值，就會喚醒淘汰線程對Map中的Block進行淘汰。系統設置三個MinMaxPriorityQueue隊列，分別對應上述三個分層，每個隊列中的元素按照最近最少被使用排列，系統會優先poll出最近最少使用的元素，將其對應的內存釋放。
- CombinedBlockCache：是一個LRUBlockCache和BucketCache的混合體。LRUBlockCache中主要存儲Index Block和Bloom Block，而將Data Block存儲在BucketCache中。故一次隨機讀需要先在LRUBlockCache中查到對應的Index Block，然后再到BucketCache查找對應數據塊。BucketCache有三種工作模式：heap、offheap、file。heap模式表示這些Bucket是從JVM Heap中申請，offheap模式使用DirectByteBuffer技術實現堆外內存存儲管理，而file模式使用類似SSD的高速緩存文件存儲數據塊。無論在哪一種工作模式，BucketCache都會申請許多帶有固定大小標簽的Bucket,一種Bucket只是一種指定的BlockSize的數據塊，初始化的時候申請14個不同大小的Bucket，而且即使在某一種Bucket空間不足的情況下，系統也會從其他Bucket空間借用內存使用，不會出現內存使用率低下的情況。
- BucketCache內存組織形式：HBase啟動時，會在內存申請大量bucket，每一個bucket默認大小是2MB,每一個Bucket都有一個offsetBase屬性和size標簽，其中offsetBase表示這個bucket在實際物理空間的offset, 故可以根據offsetBase的屬性，和block在該bucket的offset確定block實際物理存儲地址；size標簽表示這個bucket可以存放的block塊的大小，比如size 標簽是9k, 那么他只能存儲8k的block，如果size標簽是129k，那么bucket只能存儲128k的block；HBase使用BucketAllocator對bucket進行管理, HBase會根據size進行分組，相同size的標簽由同一個BucketSizeInfo來管理，如64k的block的由size 標簽是65k的BucketSizeInfo來管理, 如128k的block的由size 標簽是129k的BucketSizeInfo來管理；默認標簽有(4+1)K、(8+1)K、(16+1)K … (48+1)K、(56+1)K、(64+1)K、(96+1)K … (512+1)K,且系統會先從小到大遍歷一次所有size標簽，為每種size標簽分配一個bucket，最后剩余的bucket都分配最大的size標簽，默認分配 (512+1)K；bucket size標簽，可以動態調整。比如64K的block數目比較多，65K的bucket被用完了以后，其他size標簽的完全空閑的bucket可以轉換成為65K的bucket，但是至少保留一個該size的bucket。
6、Hbase檢測一個元素是不是集合中的一個成員
BloomFilter用來優化一些隨機讀取的場景，即Get場景。它可以被用來快速的判斷一條數據在一個大的數據集合中是否存在。Bloom filter 是由 Howard Bloom 在 1970 年提出的二進制向量數據結構，它具有很好的空間和時間效率，被用來檢測一個元素是不是集合中的一個成員。
- BloomFilter在判斷一個數據是否存在時，擁有一定的誤判率。誤判率：在萬分之一以下由哈希函數個數k、位數組大小m、數據量n共同確定。但對於“該條數據不存在”的判斷結果是可信的。
- HBase的BloomFilter的相關數據，被保存在HFile中。
- Bloom Filter的數據存在StoreFile的meta中，一旦寫入無法更新，因為StoreFile是不可變的。
- Bloomfilter是一個列族（cf）級別的配置屬性，如果你在表中設置了Bloomfilter，那么HBase會在生成StoreFile時包含一份bloomfilter結構的數據，稱其為MetaBlock；MetaBlock與DataBlock（真實的KeyValue數據）一起由LRUBlockCache維護。所以，開啟bloomfilter會有一定的存儲及內存cache開銷。
- Bloom Filter用k個hash function將它hash得到bloom filter中k個bit位，將這k個bit位置1。若這k bits全為1，則此元素在集合中。
7、HBase性能優化
表設計
- Region：區域。預先創建多個Region，當數據寫入HBase時，會按照RowKey對應Region分區情況，在集群內做數據的負載均衡。創建HBase表的時候會自動創建一個region分區，直到這個region足夠大了才進行切分，當導入數據的時候，所有的HBase客戶端都向這一個region寫數據。
- RowKey：行鍵。滿足實際業務需求情況下，長度越小越好，考慮散列性（連續的Row Key易導致負載不均衡）。散列存儲可采用取反或Hash來實現。可以是任意字符串，最大長度64KB，實際應用中一般為10~100bytes，存為byte[]字節數組，一般設計成定長的。RowKey是按照字典序存儲，因此，設計RowKey時，要充分利用這個排序特點，將經常一起讀取的數據存儲到一塊，將最近可能會被訪問的數據放在一塊。 取反：將指連續的id等，倒排作為HBase RowKey設計。如 10000,10001,10002 --> 00001,10001,20001 Hash：連續的id可根據集群節點數由Hash計算出結果，再將hash值放到id前面拼接成RowKey。如 id --> 0-id1 , 3-id2
- Column Family：列簇 。一張表里不要定義太多的列簇，因為某個列簇在flush的時候，它鄰近的列簇也會因關聯效應被觸發flush，最終導致系統產生更多的I/O。
- Max Version：最大版本數量。如果只需要保存最新版本的數據，那么可以設置最大版本數為1。
- Time To Live：數據存活時間（秒）。例如只需要存儲最近兩天的數據，那么可以設置存活時間為2 * 24 * 60 * 60。
寫表操作
Table參數
Write Buffer：實際寫入數據量的多少來設置Table客戶端的寫buffer大小。
WAL Flag：對於相對不太重要的數據，（謹慎使用）放棄寫WAL日志，從而提高數據寫入的性能。
批量寫：通過調用Table實例的put(List)批量寫入多行記錄，只需一次網絡I/O開銷，可以明顯的提升寫性能。