文章由加米穀大數據請添加鏈接描述整理全文比較長乾貨多，請耐心閱讀加米穀
一、爲何使用HBase
(1) HBase的優點：
列可以動態增加，並且列爲空就不存儲數據，節省存儲空間
HBase自動切分數據，使得數據存儲自動具有水平scalability
HBase可以提供高併發讀寫操作的支持
(2) HBase的缺點：
不能支持條件查詢，只支持按照Row key來查詢
HBase並不適合傳統的事物處理程序或關聯分析，不支持複雜查詢，一定程度上限制了它的使用，但是用它做數據存儲的優勢也同樣非常明顯
因爲HBase存儲的是鬆散的數據，所以如果你的應用程序中，數據表每一行的結構是有差別的，那麼可以考慮使用HBase。
因爲HBase的列可以動態增加，並且列爲空就不存儲數據，所以如果你需要經常追加字段，且大部分字段是NULL值的，那可以考慮HBase。
因爲HBase可以根據Rowkey提供高效的查詢，所以如果你的數據(包括元數據、消息、二進制數據等)都有着同一個主鍵，或者你需要通過鍵來訪問和修改數據，使用HBase是一個很好地選擇。
二、如何使用HBase
場景一：賣家操作日誌
賣家操作日誌，顧名思義是用來記錄商家操作的系統，從而可以保證商家可以精確查詢自己的各種操作。京東有幾十萬的商家時時刻刻的進行着各種操作，因此賣家操作日誌的特點是：數據量大、實時性強、增多查少。
▲圖一
▲圖二
做賣家操作日誌初期，將所有的操作日誌存放在ES中，操作日誌的數據量是非常大的，但當時所能申請到的ES資源有限。當把大量的數據存儲到有限的ES集羣中時便導致了性能的下降。在這種情況下，選擇了只在ES集羣中存儲最近三個月的數據，對其提供靈活的查詢，而長期的數據存儲使用HBase來進行。這樣便可以實現對近期操作靈活展現，對長期數據也有精確備份。
場景二：京麥消息日誌的存儲
京麥消息日誌的存儲是屬於京麥筋斗雲系統(用於打造京麥消息生態系統閉環)不可或缺的一部分，其中包含消息的全鏈路追蹤以及消息的統計分析。京麥消息每天都會有幾千萬的消息量，如何對消息進行追蹤和統計便成爲了一個至關重要的問題。
消息追蹤要求實時性、多維度精確查詢，因此選擇將最近一週的消息日誌存儲在ES。統計分析要求有足夠多的數據，因此在將數據存儲在ES中的同時也存儲在HBase中一份。最終再定期將HBase中的數據導入到京東的數據集市中，這樣便可以很方便的對京麥消息進行統計分析。
HBase的數據結構
▲HBase數據的概念視圖
要使用HBase首先要了解HBase的數據結構：
HBase會存儲系列的行記錄，行記錄有三個基本類型的定義：Row Key、Time Stamp、Column Family。
- Row Key
與NoSQL數據庫一樣，Row Key是用來檢索記錄的主鍵。訪問HBase table中的行，只有三種方式：
通過單個Row Key訪問
通過Row Key的range全表掃描
Row Key可以是任意字符串(最大長度是64KB，實際應用中長度一般爲 10 ~ 100bytes)，在HBase內部，Row Key保存爲字節數組
在存儲時，數據按照Row Key的字典序(byte order)排序存儲。設計Key時，要充分排序存儲這個特性，將經常一起讀取的行存儲到一起(位置相關性)。
- Column Family
HBase表中每個列都必須屬於某個列族，列族必須作爲表模式定義的一部分預先給出(有點像關係型數據庫中的列名，定義完一般情況下就不會再去修改)。
列名以列族作爲前綴，每個列族都可以有多個列成員。新的列族成員(也就是列)可以隨後按需，動態加入。
Hbase把同一列族裏面的數據存儲在同一目錄下，由幾個文件保存。
- Time Stamp
在HBase每個cell存儲單元對同一份數據有多個版本，根據唯一的時間戳來區分每個版本之間的差異，不同版本的數據按照時間倒序排序，最新的數據版本排在最前面。
三、簡述HBase的架構原理
- HBase的模塊
(1) Master
HBase Master用於協調多個Region Server，偵測各個Region Server之間的狀態，並平衡Region Server之間的負載。HBase Master還有一個職責就是負責分配Region給Region Server。HBase允許多個Master 節點共存，但是這需要Zookeeper的幫助。不過當多個Master節點共存時，只有一個Master是提供服務的，其他的Master節點處於待命的狀態。當正在工作的Master節點宕機時，其他的Master則會接管 HBase 的集羣。
(2)Region Server
對於一個Region Server而言，其包括了多個Region。Region Server的作用只是管理表格，以及實現讀寫操作。Client 直接連接Region Server，並通信獲取HBase中的數據。對於Region而言，則是真實存放HBase數據的地方，也就說Region是HBase可用性和分佈式的基本單位。如果當一個表格很大，並由多個CF組成時，那麼表的數據將存放在多個Region之間，並且在每個Region中會關聯多個存儲的單元(Store)。
(3)Zookeeper
對於HBase而言，Zookeeper的作用是至關重要的。首先Zookeeper是作爲HBase Master的HA解決方案。也就是說，是Zookeeper保證了至少有一個HBase Master處於運行狀態。並且Zookeeper負責Region和Region Server的註冊。其實Zookeeper發展到目前爲止，已經成爲了分佈式大數據框架中容錯性的標準框架。不光是HBase，幾乎所有的分佈式大數據相關的開源框架，都依賴於Zookeeper實現HA。
- HBase的原理
首先需要知道HBase的集羣是通過Zookeeper來進行機器之前的協調，也就是說HBase Master與Region Server之間的關係是依賴Zookeeper來維護。當一個Client需要訪問HBase集羣時，Client需要先和Zookeeper來通信，然後纔會找到對應的Region Server。每一個 Region Server管理着很多個Region。對於HBase來說，Region是HBase並行化的基本單元。因此，數據也都存儲在Region中。
這裏需要特別注意，每一個Region都只存儲一個Column Family的數據，並且是該CF中的一段(按Row 的區間分成多個Region)。Region所能存儲的數據大小是有上限的，當達到該上限時(Threshold)，Region會進行分裂，數據也會分裂到多個Region中，這樣便可以提高數據的並行化，以及提高數據的容量。
每個Region包含着多個Store對象。每個Store包含一個MemStore，和一個或多個HFile。MemStore便是數據在內存中的實體，並且一般都是有序的。當數據向Region寫入的時候，會先寫入MemStore。當MemStore中的數據需要向底層文件系統傾倒(Dump)時(例如MemStore中的數據體積到達MemStore配置的最大值)，Store便會創建StoreFile，而StoreFile就是對HFile一層封裝。所以MemStore中的數據會最終寫入到HFile中，也就是磁盤IO。由於HBase底層依靠HDFS，因此HFile都存儲在HDFS之中。這便是整個HBase工作的原理簡述。
四、使用HBase時應注意的問題
基於HBase的系統設計與開發中，需要考慮的因素不同於關係型數據庫，HBase模式本身很簡單，但賦予你更多調整的空間，有一些模式寫性能很好，但讀取數據時表現不好，或者正好相反，類似傳統數據庫基於範式的OR建模，在實際項目中考慮HBase設計模式是，需要從以下幾方面內容着手：
這個表應該有多少個列簇
列簇使用什麼數據
每個列簇應有多少個列
列名應該是什麼，儘管列名不必在建表時定義，但是讀寫數據時是需要的
單元應該存放什麼數據
每個單元存儲什麼時間版本
行健結構是什麼，應該包括什麼信息
五、總結
現如今各種數據存儲方案層出不窮，本文結合兩個實戰場景就基於HBase的大數據存儲做了簡單的分析，並對HBase的原理做了簡單的闡述。如何使用好HBase，甚至於如何選擇一個最優的數據存儲方案，還需要根據場景需要具體分析和設計。