【Hadoop】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.刪除特定列族的所有列 | 刪除操作不會立刻執行，而是給該資料設定墓碑標籤，在空間清理的時候再執行死亡資料和墓碑的清除工作；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
ZooKeeper：協調者
- 保證叢集中有且只有一個HMaster為Active
- 儲存hbase:meta，即所有Region的位置資訊
- 儲存HBase中表格的元資料資訊
- 監控RegionServer狀態，將RS的上下線情況彙報給HMaster
- ZooKeeper叢集本身使用一致性協議(PAXOS協議)保證每個節點狀態的一致性
Region：Region是HBase資料儲存和管理的基本單位
2.3 相關流程
2.3.1 首次讀寫流程
2.3.2 寫流程
2.3.2 讀流程
2.4 相關機制
2.4.1 Compaction機制(壓縮合並)
2.4.1.1 次壓縮
2.4.1.2 主壓縮
2.4.2 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位置資訊的流程
- 從ZooKeeper中讀取-ROOT- Table所在HRegionServer
- 從該HRegionServer中根據請求的TableName，RowKey讀取.META. Table所在HRegionServer
- 從該HRegionServer中讀取.META. Table的內容而獲取此次請求需要訪問的HRegion所在的位置
- 訪問該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 環境搭建
3.1.2 入門程式
3.2 技術難點
待續…
3.3 開發中遇到的問題
待續…
3.4 應用
3.4.1 OpenTSDB開發
待續…
4 宣告
待續部分將會後期不定期更新，敬請期待。
參考文章：
若有侵權，請聯絡我。