1.本文說明

筆者最近一年從事維護Hbase相關工作，總結相關文章用于闡述對于Hbase的部分理解，本文知識點來源于
《HBase原理與實踐》第一章

2.Hbase概述

1.許多大數據系統(tǒng)都將Hbase作為底層數據存儲服務，例如Kylin、OpenTSDB等
2.歷史發(fā)展、數據模型、體系結構、系統(tǒng)特性幾方面展示

• 歷史發(fā)展
  2003 - Google 《GFS:The Google File System》
  2004 - Google 《MapReduce：Simplefied Data Processing On Large Clusters》
  2006 - Google 《BigTable: A Distributed Storage System For Structured Data》
• Hbase使用現(xiàn)狀
  阿里巴巴、小米、華為、網易、京東、滴滴、中國電信、中國人壽等公司都使用Hbase存儲海量數據，服務于各種在線系統(tǒng)以及離線分析系統(tǒng)。
  業(yè)務場景包括訂單系統(tǒng)、消息存儲系統(tǒng)、用戶畫像、搜索推薦、安全風控以及物聯(lián)網時序數據存儲等。
  3.社區(qū)穩(wěn)定版
  https://downloads.apache.org/hbase/stable/

3.Hbase數據模型

3.1 邏輯視圖
以表形式組織，而且和關系型數據庫中的表一致，由行和列構成，因此Hbase容易理解。
table - 一個表包含多行數據
row - 行，一行數據包含一個唯一標識rowkey，多個column以及對應的值，一張表中所有row都按照rowkey的字典序由小到大排序。
column - 列，Hbase中的column有列簇以及列名兩部分組成，兩者中間使用“:”相連。
timestamp，時間戳，每個cell在寫入Hbase的時候都會默認分配一個時間戳作為該cell的版本。
cell，單元格，由五元組(row、column、timestamp、type、value)組成，type是Put/Delete這樣的操作類型，timestamp代表這個cell的版本。
實際以KV存儲，

image.png

3.2 物理視圖
Hbase是一個Map，由鍵值構成，Hbase是一個稀疏的、分布式的、多維排序Map。
需要注意Hbase的限定詞，稀疏的、分布式的、持久性的、多維的以及排序的。
Hbase中Map的Key是一個復合鍵，由rowkey、column family、qualifier、type以及timestamp組成，value即為cell的值。
具體的存儲形式如下：

image.png

• 這個特性比較容易理解，Hbase的Map與普通的Map最大的不同在于，key是一個復合數據結構，由多維元素構成，包括rowkey、column family、qualifier、type以及timestamp。

稀疏：

• 列式存儲，空值不需要任何填充，Hbase列理論上是允許無限擴展的。

排序：

• 構成Hbase的KV在同一個文件中都是有序的，但規(guī)則并不是僅僅按照RowKey排序，而是KV中的Key進行排序，先比較rowkey，rowkey小的排在前面；如果rowkey相同，在比較column，即column family:qulifier，column小的排在前面；如果column還相同，再比較時間戳，即版本信息，timestamp大的排在前面。

分布式

• 很容易理解，構成Hbase的所有Map并不集中在某臺機器上，而是分布在整個集群中。

4.行式存儲、列式存儲、列簇式存儲

• 行式存儲
  行式存儲系統(tǒng)會將一行數據存儲在一起，一行數據寫完之后再接著寫下一行。
  特點：行式存儲在獲取一行數據時是很高效的，但是如果某個查詢只需要讀取表中指定列對應的數據，那么行式存儲會取出一行行數據，再在每一行數據中截取待查找的目標列。
• 列式存儲
  會將所有列存儲在一起，對于查找某些列非常高效，但是列存對于獲取一行的請求就不高效了，需要多次IO讀某個列數據，最終合并得到一行數據。因為同一列的數據通常都具有相同的數據類型，因此列存具有天然的高壓縮性。
• 列簇式存儲
• 在極端情況下，可以是行式存儲或列式存儲，這種架構演變成HTAP(Hybird Transcational and Analytical Processing)系統(tǒng)提供了最核心的基礎。

5.Hbase體系結構

• 典型的Master-Slave模型，系統(tǒng)中有一個管理集群的Master節(jié)點以及大量實際服務用戶讀寫的RegionServer節(jié)點。
• Hbase系統(tǒng)還有一個ZK節(jié)點，協(xié)助Master對集群進行管理。
• Hbase客戶端
  Shell命令行、原生Java API編程接口、Thrift/REST API編程接口以及MR編程接口。
  Hbase客戶端支持所有常見的DML操作以及DDL操作，即數據的增刪改查和表的日常維護等。
  Thrift/REST API主要用于支持非Java的上層業(yè)務需求，MR接口主要用于批量數據導入以及批量數據讀取。
• ZK
  1.實現(xiàn)Hbase高可用
  2.管理系統(tǒng)核心元數據
  3.參與RegionServer宕機恢復（通過心跳可以感知到RS是否宕機，并在宕機后通知Master進行處理）
  4.實現(xiàn)分布式表鎖
• Master
  處理用戶的各種管理請求，包括建表、修改表、權限操作、切分表、合并數據分配以及Compcation等
  管理集群中所有RS，包括RS中的Region負載均和，RS的宕機恢復以及Region遷移。
  清理過期日志以及文件，Master每隔一段時間檢查HDFS中HLOG是否過期、HFile是否已經被刪除、并在過期之后將其刪除。
• RegionServer
  1.響應用戶IO請求
  2.WAL
  HLOG在Hbase中有兩個核心作用：
  其一，用于實現(xiàn)數據的高可靠性，Hbase數據數據隨機寫入時，并非直接寫入HFile數據文件，而是先寫入緩存，在異步刷新落盤。為了防止緩存數據丟失，數據寫入緩存之前需要首先順序寫入HLOG，這樣，即使緩存數據丟失，仍然可以通過HLOG日志恢復；
  其二，用于實現(xiàn)Hbase集群主從復制，通過回放主集群推送過來的HLOG日志實現(xiàn)主從復制。
  3.BLOCKCACHE
  緩存對象是一系列Block塊，一個Block默認64KB，由物理上相鄰的多個KV數據組成。BlockCache同時利用了空間局限性和時間局部性原理，前者表示最近將讀取的KV數據很可能與當前讀取的KV數據在地址上是鄰近的，緩存單位是Block（塊）而不是單個KV就可以實現(xiàn)空間局部性；后者表示一個KV數據正在被訪問，那么近期它還可能再次被訪問。
  當前BlockCache主要有兩種實現(xiàn)，LRUBlockCache和BucketCache，前者實現(xiàn)相對簡單，而后者在GC優(yōu)化方面有明顯的提升。
• Region
  數據表的一個分片，當數據表大小超過一定閾值就會“水平切分”，分裂為兩個Region。Region是集群負載均衡的基本單位，通常一張表的Region會分布在整個集群的多臺RegionServer上，一個RegionServer上會管理多個Region，當然，這些Region一般來自不同的數據表。
  一個Region由一個或者多個Store構成，Store的個數取決于表中列簇的個數，多少個列簇就有多少個Store。建議將相同IO特性的數據設置在同一個列簇中。
  每個Store由一個MemStore和一個或多個HFile組成，MemStore稱為寫緩存，用戶寫入數據時首先會寫到MemStore中，當MemStore寫滿后，系統(tǒng)會異步將數據Flush到HFILE中，當HFILE文件數超過一定閾值后，系統(tǒng)會進行Compact操作，將小文件通過一定策略合并成一個或多個大文件。

6.Hbase特性

• 優(yōu)點
  1.容量巨大
  2.良好的擴展性
  3.稀疏性
  4.高性能
  主要擅長于OLTP場景，數據寫入性能強勁，對于隨機單點讀以及小范圍掃描讀，性能也能保證，對于大范圍的掃描讀可以使用MR提供的API，實現(xiàn)高效的并行掃描。
  5.多版本
• 缺點
  1.不支持復雜運算
  2.沒有實現(xiàn)二級索引
  3.不支持全局跨行事務