HBase框架學習之路

1 背景知識

1.1 解決問題

解決HDFS不支持單條記錄的快速查找和更新的問題。

1.2 適用狀況

• 存在億萬條記錄的數據庫，只有千萬或者百萬條記錄使用RDBMS更加合適
• 確保你的應用不須要使用RDBMS的高級特性（第二索引，事務機制，高級查詢語言等）
• 足夠的硬件配置，即節點數，HDFS在少於5個節點時並不會表現得很好，HBase也存在相同狀況。

2 設計理念

2.1 概述

2.1.1 簡介

• 使用Java語言開發的NoSQL類型的分佈式數據庫
• 不支持RDBMS的一些高級特性，如事務機制，第二索引，高級查詢語言等
• 支持線性和模塊化擴展，能夠經過在商用機器上增長RegionServer來線性提升性能

2.1.2 HBase特性：

• 強讀寫一致性：適合高速計數聚合操做
• 自動切分數據：分佈式存儲數據，隨着數據增加進行自動切片
• RegionServer自動失效備援
• 與HDFS集成
• 支持MapReduce執行大規模並行操做
• 提供Java Client API
• 提供Thrift/REST API
• 針對大容量查詢優化的塊緩存和Bloom Fliter
• 可視化管理界面

2.1.3 劣勢

• WAL的從新執行速度緩慢
• 故障恢復緩慢且複雜
• 主壓縮會引發 I/O風暴（大量的I/O操做）

2.2 設計架構

2.2.1 基礎概念

概念	中文	解釋	備註	舉例
Table	表	由多行組成	...
Row	行	由一個Key和一個或者多列組成
Column	列	由列族和列限定符組成	列族：列限定符 ；行與行之間的列能夠相差不少
Column Family	列族	物理上存儲多個列；爲提升性能設計的；	表格建立時須要置頂	content
Column Qualifier	列限定符	列族中數據的索引	表格建立時不須要指定，能夠在任什麼時候候添加	content:html
Cell	單元	由行、列族、列限定符、值和表明版本的時間戳組成
TimeStamp	時間戳	用來表示數據的版本	可使用系統時間也能夠本身指定

2.2.1.2 例子本例子取自官方文檔

Row Key	Time Stamp	ColumnFamily contents	ColumnFamily anchor	ColumnFamily people
"com.cnn.www"	t9		anchor:cnnsi.com = "CNN"
"com.cnn.www"	t8		anchor:my.look.ca = "CNN.com"
"com.cnn.www"	t6	contents:html = "…​
"com.cnn.www"	t5	contents:html = "…​"
"com.cnn.www"	t3	contents:html = "…​
com.example.www	t5	contents:html: "..."		people:author: "John Doe"

說明：

1. 表格格式不是惟一和最精確的表達方式，還能夠用Json格式來表達
2. 表格中的空白單元不會佔用物理存儲空間，只是概念上存在

2.2.1.3 操做

操做	API	注意點	與版本的關係
Get	Table.get	返回指定行的屬性；Scan的第一行	若沒有指定版本，則返回版本值最大（但可能不是最新的）的數據；能夠經過設置MaxVersion的值修改返回的數據條數
Scan	Table.scan	返回知足條件的多行	同上
Put	Table.put	Key存在則更新Key不在則插入;經過 Table.put (寫緩存) 或者Table.batch (沒有寫緩存)	默認使用系統時間;只要key、column和version相同就能夠實現覆蓋；插入時能夠指定版本
Delete	Table.delete	1.刪除指定列；2.刪除列的全部版本；3.刪除特定列族的全部列	1. 刪除操做不會馬上執行，而是給該數據設置墓碑標籤，在空間清理的時候再執行死亡數據和墓碑的清除工做；2.經過在 hbase-site.xml.中hbase.hstore.time.to.purge.deletes屬性來設置TTL（生存時間）

說明：

1. 版本數的最大值和最小值是能夠指定的，而且會影響操做
2. 版本（時間戳）是用來管控數據的存活時間的，最好不要手動設置

2.2.1.4 侷限

1）Delete操做會影響Put操做：緣由在於Delete操做並非馬上執行，而是給死亡數據設置墓碑標籤，那麼若是當你執行了一個Delete版本低於等於T的操做，然後有插入Put了一個版本爲T的數據，此時新Put的數據也會被打上標籤，那麼會在系統的下一次清理工做中將打上標籤的數據所有清理掉，執行查詢時則會獲取不到新Put的數據，若是你不手動設置版本的話，版本採用系統默認時間，則不會出現這種狀況。

2）清理工做會影響查詢：建立三個版本爲t1,t2,t3的單元，而且設置最大版本數爲2.因此當咱們查詢全部版本時，只會返回t2和t3。可是當你刪除版本t2和t3的時候，版本t1會從新出現。顯然，一旦重要精簡工做運行以後，這樣的行爲就不會再出現。

查看更多關於數據模型的信息

2.2.2 架構

2.2.2.1 架構特色

1）主從架構
2）有三個組件：

組件名稱	組件主要功能
HMaster	負責Region的分配和DDL操做（建立，刪除表）
HRegionServer	RegionServer負責數據的讀寫;和客戶端通信
ZooKeeper	維持集羣的活動狀態

3）底層儲存是HDFS

2.2.2.2 組件

hbase:meta：全部region的信息

1）結構：

Key

• 格式：([table],[region start key],[region id])

Values

• info:regioninfo (序列化HRegionInfo實例)
• info:server (包含此Region的RegionServer的server:端口)
• info:serverstartcode (包含此Region的RegionServer的啓動時間)

2）存儲位置：ZooKeeper中

HMaster：控制者

• 分配Region：啓動時分配，失效RegionServer上Region的再分配，Region切分時分配
• 監控集羣中的全部RegionServer，實現其負載均衡
• DDL:Data Definition Language(表格的建立、刪除和更新-列族的更新）
• 管理namespace和table的元數據
• 權限管理（ACL）
• HDFS上的垃圾文件回收

HRegionServer：HBase實際讀寫者

• 響應client的讀寫請求，進行I/O操做（直接繞過HMaster）
• 與HDFS交互，管理table數據
• 當Region的大小到達閥值時切分Region

本小節可參考Region Server詳解

ZooKeeper：協調者

• 保證集羣中有且只有一個HMaster爲Active
• 存儲hbase:meta，即全部Region的位置信息
• 存儲HBase中表格的元數據信息
• 監控RegionServer狀態，將RS的上下線狀況彙報給HMaster
• ZooKeeper集羣自己使用一致性協議(PAXOS協議)保證每一個節點狀態的一致性

Region：Region是HBase數據存儲和管理的基本單位

本小節可參考Region詳解

2.3 相關流程

2.3.1 首次讀寫流程

本小節可參考Region Server詳解中的首次讀寫流程

2.3.2 寫流程

本小節可參考Region Server詳解中的寫流程

2.3.2 讀流程

本小節可參考Region Server詳解中的讀流程

2.4 相關機制

2.4.1 Compaction機制(壓縮合並)

2.4.1.1 次壓縮

本小節可參考Region Server詳解中的次壓縮部分

2.4.1.2 主壓縮

本小節可參考Region Server詳解中的主壓縮部分

2.4.2 WAL Replay機制

本小節可參考Region Server詳解中的WAL Replay

2.5 版本更新內容

2.5.1 .META表 =>hbase:meta

2.5.1.1 -ROOT-和.META

在0.96.x以前是存在-ROOT-和.META兩個表格來維持region的元數據

1）結構：

Key

• .META. region key (.META.,,1)

Values

• info:regioninfo (hbase:meta的序列化實例)
• info:server (存儲 hbase:meta的RegionServer的server:port)
• info:serverstartcode (存儲 hbase:meta的RegionServer的啓動時間)

2）讀取region位置信息的流程

1. 從ZooKeeper中讀取-ROOT- Table所在HRegionServer
2. 從該HRegionServer中根據請求的TableName，RowKey讀取.META. Table所在HRegionServer
3. 從該HRegionServer中讀取.META. Table的內容而獲取這次請求須要訪問的HRegion所在的位置
4. 訪問該HRegionSever獲取請求的數據

2.5.1.2 hbase:meta

本小節可參考2.2.2.2 組件中的hbase:meta和2.3 相關流程中的首次讀寫流程進行比較

2.5.1.3 升級的目的

1）0.96.x版本以前是參考Goole的BigTable設計的，從讀取數據請求發起到真正讀取到數據要通過4個步驟，Google設計BigTable的目的在於它的數據量巨大，多層的schema結構可以存儲更多的Region，可是隨着而來的就是訪問性能的降低。
2）通常公司的數據量沒有Google那麼大，因此去掉-ROOT-表，留下.META(hbase:meta)表，提升Region的大小，不只能夠知足存儲需求，並且訪問性能獲得提升。

2.5.2 HLog =>WAL

• 0.94.x 以前HBase中的WAL實現稱爲HLog，存儲在/hbase/.logs/目錄下
• 0.94.x以後改名爲WAL，存儲在/hbase/WALs/目錄下

2.6 跟其餘框架的聯繫

待續...

2.7 性能調優

待續...

2.8 高級特性

待續...

3 項目實戰

3.1 入門指南

3.1.1 環境搭建

本小節可參考HBase部署入門指南

3.1.2 入門程序

本小節可參考HBase Shell 練習、HBase Java API 練習、使用MapReduce操做HBase

3.2 技術難點

待續...

3.3 開發中遇到的問題

待續...

3.4 應用

3.4.1 OpenTSDB開發

待續...

4 聲明

待續部分將會後期不按期更新，敬請期待。

參考文章：

Apache HBase ™ Reference Guide
An In-Depth Look at the HBase Architecture

如有侵權，請聯繫我。