HBase是一個分佈式的、面向列的開源數據庫，該技術來源於 Fay Chang 所撰寫的Google論文“Bigtable：一個結構化數據的分佈式存儲系統”。就像Bigtable利用了Google文件系統（File System）所提供的分佈式數據存儲一樣，HBase在Hadoop之上提供了類似於Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同於一般的關係數據庫，它是一個適合於非結構化數據存儲的數據庫。另一個不同的是HBase基於列的而不是基於行的模式
HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集羣。
與FUJITSU Cliq等商用大數據產品不同，HBase是Google Bigtable的開源實現，類似Google Bigtable利用GFS作爲其文件存儲系統，HBase利用Hadoop HDFS作爲其文件存儲系統；Google運行MapReduce來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable利用 Chubby作爲協同服務，HBase利用Zookeeper作爲對應。 [1]
上圖描述Hadoop EcoSystem中的各層系統。其中,HBase位於結構化存儲層，Hadoop HDFS爲HBase提供了高可靠性的底層存儲支持，Hadoop MapReduce爲HBase提供了高性能的計算能力，Zookeeper爲HBase提供了穩定服務和failover機制。
此外，Pig和Hive還爲HBase提供了高層語言支持，使得在HBase上進行數據統計處理變的非常簡單。 Sqoop則爲HBase提供了方便的RDBMS數據導入功能，使得傳統數據庫數據向HBase中遷移變的非常方便。
爲何要選用非關係型數據庫傳統的關係數據庫,使用的時候有如下痛點:
1. 難以應付高併發數據寫入
2. 海量數據的查詢,效率低
3. 數據量達到一定規模後,會遇到瓶頸,難以擴展
4. 表結構修改困難, 難以適應經常變更的業務需求
5. 許可費用,擴展費用高昂
非關係型數據庫分類
1. 鍵值型數據庫代表 : Redis, Flare特點 : 鍵值數據庫將數據存儲爲鍵值對集合，其中鍵作爲唯一標識符。鍵和值都可以是從簡單對象到複雜複合對象的任何內容。鍵值數據庫是高度可分區的，並且允許以其他類型的數據庫無法實現的規模進行水平擴展。
2. 文檔型數據庫代表 : MongoDB,CouchDB特點 : 在文檔數據庫中，文檔是處理信息的基本單位。一文檔可以很長、很複雜、可以無結構，與字處理文檔類似。一個文檔相當於關係數據庫中的一條記錄。
3. 列存儲數據庫代表 : HBase,Cassandra特點 : 以列相關存儲架構進行數據存儲的數據庫, 適合大批量數據的處理
4. 圖數據庫代表 : InfoGrid, Neo4j特點 : 最近越來越火的非關係型數據庫,應用圖形理論存儲實體之間的關係信息。
HBase八大應用場景 對象存儲：
我們知道不少的頭條類、新聞類的的新聞、網頁、圖片存儲在HBase之中，一些病毒公司的病毒庫也是存儲在HBase之中
時序數據：HBase之上有OpenTSDB模塊，可以滿足時序類場景的需求
推薦畫像：特別是用戶的畫像，是一個比較大的稀疏矩陣，螞蟻的風控就是構建在HBase之上
時空數據：主要是軌跡、氣象網格之類，滴滴打車的軌跡數據主要存在HBase之中，另外在技術所有大一點的數據量的車聯網企業，數據都是存在HBase之中
CubeDB OLAP：Kylin一個cube分析工具，底層的數據就是存儲在HBase之中，不少客戶自己基於離線計算構建cube存儲在hbase之中，滿足在線報表查詢的需求
消息/訂單：在電信領域、銀行領域，不少的訂單查詢底層的存儲，另外不少通信、消息同步的應用構建在HBase之上
Feeds流：典型的應用就是xx朋友圈類似的應用
NewSQL：之上有Phoenix的插件，可以滿足二級索引、SQL的需求，對接傳統數據需要SQL非事務的需求
HBase特性海量存儲：
單表可以存儲百億級別的量級，不用擔心讀取的性能下降；
面向列：數據在表中是按某列的數據聚集存儲，數據即索引，只訪問查詢涉及的列時，可以降低系統的I/O；
稀疏性：傳統行式存儲的數據存在大量的空值的列，需要佔用存儲空間，造成存儲空間的浪費，而HBase爲空的列並不佔用空間，因此表可以設計的很稀疏；
擴展性：HBase底層基於HDFS,支持快速擴展，可以隨時添加或者減少節點數；
高可靠：基於Zookeeper的協調服務，能夠保證服務的高可用。HBase使用WAL和replication機制，前者保證數據寫入是不會因爲集羣異常而導致寫入數據的丟失，後者保證集羣出現嚴重的問題時，數據不會發生丟失和損壞；
高性能：底層的LSM數據結構，使得HBase具備非常高的寫入性能。RowKey有序排列，主鍵索引和緩存機制使得HBase具備一定的隨機讀寫性能。
HBase數據模型
Table(表)類似於傳統數據庫中的表的概念，用於組織存放數據在HBase中。
Row KeyHBase中的數據是以行的形式進行存儲，每一行數據都會被一個唯一行健(Row Key)進行標識。Row Key在存儲的過程中是按照字典的順序排序的。其只能存儲64k的字節數據。
Column Family (列簇) & qualifier(列)HBase表中的每個列都歸屬於某個列簇，列簇在我們定義表的時候指定。列名以列簇作爲前綴，每個列簇都可以有多個列成員（column），新的列可以隨後按需，動態加入；權限控制，存儲以及調優都是在列簇層面進行的。
Cell(單元格)Cell是由行，列簇和列的座標交叉決定的，其是有版本號的，每個Cell的內容是未解析的字節數組。由{row key， column( =<family> +<qualifier>)， version}唯一確定Cell。Cell中的數據是沒有類型的，全部是字節碼的形式存儲。
Timestamp(時間戳)在HBase中每個Cell存儲單元對同一份數據有多個版本，根據唯一的時間戳來區分每個版本之間的差異，不同版本的數據按照時間倒序排序，最新的數據版本排在最前面。
HBase物理存儲
HRegion：
HBase表中的數據按照行鍵的字典順序排序，HBase表中的數據會按照行的方向切分爲多個HRegion。最開始只有一個HRegion，但是隨着數據量的不斷增加，HRegion會產生分裂，這個過程不停的進行。一個表可能對應一個或者多個HRegion。HRegion是HBase表分佈式存儲和負載均衡的基本單元，一個表的多個HRegion可能分佈在多臺HRegionServer上。HRegion和Region是同一個意思，只是叫法不同。
Store ：
HRegion是分佈式存儲的基本單元，但不是存儲的基本單元。其內部結構爲，一個HRegion由多個Store來組成。有幾個Store取決於建表的時候設置的列簇的數量，一個列簇對應一個Store。之所以這麼設計，是因爲一個列簇中的數據往往數據很類似，方便進行壓縮，節省存儲空間。
MemStore ：
表的一個列簇對應一個Store，Store的數量由表的列簇的數量來決定。一個Store由一個MemStore和零個或者多個StoreFile組成。MemStore作爲內存緩存區，數據的寫操作會先寫到MemStore中，當MemStore中的數據增長到一定閥值後，RegionServer會將其中的數據flush到StoreFile中，每次寫入行成一個單獨的StoreFile。
StoreFile ：
當StoreFile數量增長到一定閥值後，系統會進行合併（minor compaction和major compaction）,合併過程會進行版本的合併和刪除工作，形成更大的StoreFile。
HFile HFile：
和StoreFile是同一個東西，只不過是站在HDFS的角度稱這個文件時HFile,在HBase的角度叫做StoreFile。
HLog
(WAL log) WAL(Write ahead log)，類似MySQL中的Binlog，用來做災難恢復用的，HLog記錄數據的所有變更，一旦數據修改，就可以從HLog中進行恢復。 每個HRegionServer維護一個HLog。HLog文件就是一個普通的Hadoop Sequence File，Sequence File的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬馨馨，除了Table和Region名字外，同事還包括Sequence number和timestamp，timestamp是寫入時間，sequence number的起始值是0。HLog Sequence File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue。
HBase讀流程
1.Client先訪問Zookeeper，從meta表讀取Region的位置，然後讀取meta表中的數據。meta中又存儲了用戶表的Region信息；
2.根據namespace，表名和RowKey在meta表中找到對應的Region信息；
3.找到這個Region對應的RegionServer；
4.查找對應的Region；
5.先從BlockCache找數據，如果沒有，再到MemStore裏面讀；
6.MemStore如果沒有，再到StoreFile上讀（爲了讀取的效率）;
7.如果是從StoreFile裏面讀取的數據，不是直接返回給客戶端，而是先寫入BlockCache裏，再返回給客戶端。
HBase寫流程
1.客戶端向ZK發送請求，獲取meta表所在的RegionServer；
2.客戶端通過RegionServer獲取到meta表的數據；
3.然後客戶端向集羣中的RegionServer發送寫入數據的請求；
4.RegionServer收到寫數據的請求後，將數據寫到HLog中，這一步是爲了數據的持久化和恢復;
5.RegionServer將數據寫入內存(MemStore)；
6.然後通知客戶端數據寫入成功。
HBase Region Flush
MemStore中的數據Flush到HDFS上的觸發條件有哪些呢？HBase會在如下幾種情況下觸發flush操作，需要注意的是MemStore的最小flush單元是HRegion而不是單個MemStore。可想而知，如果一個HRegion中MemStore過多，每次flush的開銷必然會很大，因此建議進行表設計的時候儘量減少ColumnFamily的個數。下面設置的參數可以移步官網，在HBase Default Configuration這個小節裏查找☞☞☞
MemStore級別限制：當Region中任意一個MemStore的大小達到了上限(hbase.hregion.memstore.flush.size，默認128MB),會觸發MemStore刷新；
Region級別限制：當Region中所有MemStore的大小總和達到了上限(hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默認 4* 128M = 512M)，會觸發MemStore刷新;
RegionServer 級別限制：當一個RegionServer中所有MemStore的大小總和達到了上限(hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默認40%的JVM內存使用量)，會觸發部分MemStore刷新。Flush順序是按照MemStore由大道小執行，先Flush MemStore最大的Region，再執行次大的，直至總體MemStore內存使用量低於閥值(hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize，默認 38%的JVM內存使用量)；
當一個RegionServer中HLog數量達到上限(可以通過參數hbase.regionserver.maxlogs配置)時，系統會選取最早的一個HLog對應的一個或者多個Region進行flush；
HBase定期刷新MemStore:默認週期爲1小時，確保MemStore不會長時間沒有持久化。爲避免所有的MemStore在同一時間都進行flush導致有問題，定期的flush操作有20000左右的隨機延遲；
手動執行flush：用戶可以通過shell命令flush 'tablename' 或者 flush 'region name'分別對一個表或者一個Region進行flush。
HBase文件合併
MemStore每次Flush會創建新的HFile,而過多的HFile會引起讀的性能問題，那麼如果解決這個問題呢？HBase採用Compaction機制來解決這個問題，在HBase中Compaction分爲兩種：Minor Compaction和Major Compaction。
Minor Compaction Minor Compaction是指選取一些小的，相鄰的StoreFile將它們合併成一個更大的StoreFile，在這個過程中不會處理已經Deleted和Expired的Cell。一次Minor Compaction的結果是更少並且更大的StoreFile。 Major Compaction Major Compaction是指將所有的StoreFile合併成一個StoreFile，在這個過程中，標記爲Deleted的Cell會被刪除，而那些已經TTL(time-to-live)的Cell會被丟棄。一次Major Compaction的結果是一個HStore只有一個StoreFile存在。Major Compaction可以手動或自動觸發，然而由於它會引起很多的I/O操作而引起性能問題，因而它一般會被安排在比較閒的時間進行。
HBase Region 的分裂
剛開始的時候每個表只有一個Region，當Region變的特別大的時候，它會被分割成兩個Region。分隔的Region各自持有原Region一部分數據，當然分裂會報告給HMaster。然後有時候，HMaster會將新分裂的Region移動到其它的RegionServer上面。
