Apache HBase的現狀和發展

一、ＨBase是什么

HBase(Hadoop Database)，是一個基于Google BigTable論文設計的高可靠性、高性能、可伸縮的分布式存儲系統。

它有以下特征：

1.HBase仍然是采用行存儲的，采用松散表的結構來獲得動態列的功能；

2.原生海量數據分布式存儲。在單個數據庫中可以存檔GB甚至上pb。在一行中也可以存儲上百萬列。任何大小的數據量都適合采用HBase；

3.不僅支持隨機查詢，還支持范圍查詢；

4.高吞吐，低延遲。一個集群可以有上千萬個dps，平均的延遲可以做到一毫秒之內；

5.在線NOSQL數據庫；

6.多版本，增量導入，多維刪除。

$\"\"$

1.1 HBase的四大基因

1.1.1自動分區

最開始的時候，我們的數據庫是單機的數據庫。慢慢的我們發現單機的數據庫無法承受數據和訪問的爆發式增長。因此就出現了分庫分表的方案。將數據庫和表拆分到多個服務器上，然后利用中間件作為一個路由。這里就會遇到一個問題，隨著數據的增加，中間件就會成為一個瓶頸。如果請求量爆發式增長的時候，要加載新的進去，整個物理的變化需要進行搬遷之后才能夠進行使用。

而在HBase中，使用的是自動分區功能。當訪問量和請求量增加的時候它可以自動的進行數據分片，以應對數據和請求的爆發式增長。

$\"\"$

1.1.2 LSM-Tree

LSM(Log Structured Merge)Tree，它的一個重要的功能就是隨機寫變成順序寫。

現在LSM模型是大數據庫的標配。它主要包括如下幾個特點：

1）寫吞吐量高；

2）不受hdd隨機寫瓶頸和ssd隨機寫入放大干擾；

3）超強數據導入能力。

$\"\"$

1.1.3 存儲計算分離

HBase本身不會存任何數據。數據都是存儲在底層的HDFS中。存儲計算分離有以下好處：負載均衡更高效、資源擴容更節省、存儲優化更便捷。

$\"\"$

1.1.4　ＨBase生態

HBase有一個非常強大的朋友圈。具體見下：

$\"\"$

1.2 場景

HBase是幾乎可以滿足所有的大數據場景需求。比如說對象存儲，比如說推薦系統。比如說用來存儲訂單，用來存儲聊天記錄。高性能推送的朋友圈應用的場景。針對一些其他的場景，我們可以利用HBase加上組件能力來實現這些場景的應用。比如說HBase加Linux，來實現NEWSQL的數據庫。比如說HBase加上geomesa來實現時空數據的存儲，滴滴就是采用這種方案來存儲他們的軌跡數據。在物聯網場景，可以采用HBase加openjsdb來存儲海量的時序數據。

$\"\"$

1.3使用HBase的商業公司

基本上每一個大型的公司都在使用HBase。

$\"\"$

1.4 HBase特性總結

HBase，為大數據而生，有LSM樹：離線導入效率巨高、實時寫入吞吐大、增量導入隔離性強；伸縮性強；TTL：數據時效性，系統自動處理、時效性的個性化設置；多版本：數據的第三維度、高效刪除方式；動態列：數據發散的利器；協處理器：數據校正、高效適應個性化；異構介質多副本存儲：海量與實時的性價比滿足；Erasure Code：因大而生。

$\"\"$

二、ＨBase社區的發展

2.1　HBase的起源

HBase于2006年誕生于Powerset,一家從事自然語言處理和搜索的創業公司(后被微軟收購)

HBase的實現基于Google發布的BigTable論文，用來解決 Hadoop中隨機讀寫效率低下的問題。HBase最初的開發人員是MichaelStack和JimKellerman。2007年4月，HBase做為一個模塊提交到Hadoop的代碼庫中，代碼量~8000行，2010年5月HBase成為Apache的頂級項目，同年，Facebook把HBase使用在其消息平臺中。

2.2　HBase項目現狀

目前HBase的代碼已經超過100萬行，HBase仍然是最活躍的Apache項目之一，擁有76個Committer，42位PMC，共有328位Contributor，其中14位 Committer/PMC 來自中國。

$\"\"$

2.3　HBase目前版本

ＨBase目前版本眾多。見下圖：

$\"\"$

三、ＨBase2.0

3.1 HBase2.0版本發布歷史

HBase2.0的發布是一部血淚史，因為在四年前已經有這個版本了，由于一些因素，造成了沒有人管理。最后花了一年多的時間才穩定他的版本發布出來，他的Release Manger多次更換，才把他發布出來。由此，我們吸取了這次教訓，我們以后會做好版本控制，把控好發布的節奏。

$\"\"$

3.2 新功能

3.2.1 Region Replica

Region Replica這個功能在1.2版本中已經存在，但是為什么叫做新功能呢？是因為之后修改了很多bug，在1.4版本才穩定下來，然后1.4和2.0是同時發布的。在CAP理論中,HBase一直是一個CP系統，遵循強一致的讀寫語義，所以Server宕機后需要一定的恢復時間，如果宕機了，客戶端可以從另外的副本中去讀取數據，Region Replica為數據分片Region準備了多個副本,host在不同的RegionServer上，同時，客戶端也可以做到，對多個副本同時發請求，然后做到選擇最快速的那個副本，提供高可用讀，宕機0影響，規避抖動，毛刺，降低P999延遲；缺點是需要額外耗費CPU/Memory資源，但不會占用額外空間。

$\"\"$

3.2.2 讀寫鏈路Off-heap

第二個新功能是全鏈路Off-heap，意思就是讀寫鏈路數據端到端Off-heap，減少java GC帶來的停頓，進一步降低P999延遲，提高吞吐。這個功能我們從兩方面來實現的：寫鏈路Off-heap，我們使用在RPC層使用Netty的Off-heap ByteBuffer，使用支持Off-heap的Protobuf。同時使用Off-heap的Chunk 來存儲Memstore中的KeyValue。

在讀鏈路Off-heap方面，使用Off-heap的Bucket Cache，HBase自己管理內存的，我們從Bucket Cache讀取數據的時候，先要從Protobuf做一次拷貝，因為可能讀取的時候，發生內存不夠了，再次分配的情況。在讀取對Bucket Cache進行引用計數，保證讀取的時候，內存不會被回收掉，讀取時不再需要先拷貝到heap，對Bucket Cache進行了一系列性能優化。

$\"\"$

后面這是HBase官方放著阿里巴巴在雙十一對HBase優化之后的對比圖，可以看到優化之后他的請求的曲線更加平穩，吞吐量增長了30%，這個案例大家可以去HBase的官方去看一下。

$\"\"$

3.2.3 In Memory Compaction

在HBase2.0中另外一個重磅的功能就是In Memory Compaction，以前我們知道HBase中使用的數據結構是java中原生的跳表，但是跳表依然是一個松散的結構，這樣的話，雖然內存不斷的在增大，但是刷到之后，會造成通過In memory的flush不會到hdfs上，反而回轉到更加緊湊的CellArrayMap這個結構，同時多個CellArrayMap會在內存中做compaction，使內存的使用更加緊湊。然后通過In memory的flush和compaction,在內存中可以存儲更多的數據，因此可以提高讀性能，同時減少磁盤IO，減輕compaction小文件造成的寫放大。這個功能社區也有介紹。

$\"\"$

3.2.4 小對象存儲MOB

之前我們建議在HBase上不要存很大的KV值，但是MOB(Moderate Object Storage) 功能使HBase能高效地存儲那些100k~10M 中等大小的對象。這使得用戶可以把文檔、圖片對象保存到HBase系統中，用戶寫入的小對象flush成一個獨立文件，原有的KV中的value只存這個對象的引用路徑，對于存儲對象文件,更少地進行compaction來減少寫入放大效應。

$\"\"$

3.2.5 Assignment MangerV2

這是一個非常重要的模塊，HBase中的狀態流轉，建表刪表，都需要在Assignment MangerV2上進行，之前舊AM系統參與角色多,狀態更新混亂，效率低，無事務保證，容易出現RIT問題。所以AM V2使用ProcedureV2來保證 Table/Region狀態轉換在master重啟后仍然能恢復執行，然后去除了Zookeeper做為中間角色，Master/RegionServer直接交互，Region assign/unassgin速度大大提升。

$\"\"$