Hbase架構及工作原理、資料及物理模型、Hbase優化
一、HBase 簡介
1.HBase 概述
HBase 是一個構建在HDFS之上的，分散式的、面向列的開源資料庫
HBase 是 Google BigTable的開源實現，它主要用於儲存海量資料
個人理解：
分散式：採用分而治之的思想，比如說我們要將10個G的資料全部寫入到HBase，對於這樣的一個任務我們可以通過10個節點來處理（並行處理），這樣可以大大的提高執行效率。
面向列：一個表中是有很多行很多列，面向列的儲存就是將多個列儲存在一塊，HBase裡是通過列族來組織的，實際開發中我們查詢可能只會查詢某幾個列，面向列儲存後，會減少磁碟和網路IO的開銷從而提高效率。面向列是無模式的，即列可以根據實際情況任意新增。
2.HBase 的特點
(1).大：一個表可以有上百萬、上百億行列（列多時，插入變慢）
(2).面向列：資料構成是列族，列族中包含N個列
(3).稀疏：在HBase中列的值為null時，是不佔儲存空間的，而關係型資料庫佔用
(4).資料型別單一：HBase 中的資料型別只有一種String
(5).無模式：每行資料對應的列可以不相同，建立表時不需要指定列，插入資料時列可以任意新增
(6).資料多版本：列中的資料可以有多個版本，查詢時可以通過指定版本號獲取（版本號不同，獲取到的資料不同）
3.HBase 與 HDFS 區別
| HDFS/MR | HBASE | |
| 寫模式 | 只能追加 | 可以隨機進行讀寫 |
| 讀模式 | 可以對整個檔案資料夾進行掃描 | 隨機或指定範圍讀取 |
| SQL(Hive) | 效能較好 | 較HDFS/MR差 |
| 結構化儲存 | 各種檔案(tvs、avro）或自定義 | 列族 |
| 最大資料 | 海量資料(和伺服器多少相關) | 海量資料(和伺服器多少相關) |
4.HBase 與 RDBMS對比
| RDBMS(關係型資料庫) |
HBASE | |
| 資料佈局 | 面向行 | 面向列 |
| 事務 | 可以基於多行應用事務 | 只支援單行 |
| 查詢語言 | SQL | API(get/put) |
| 安全 | 有授權安全機制 | 高版本中有 |
| 索引 | 指定一個或多個列加上索引 | 只能基於rowkey |
| 資料最大儲存大小 | TBS | PB |
| 讀寫資料吞吐量 | 每秒1000個查詢 | 每秒上百萬個查詢 |
傳統資料庫遇到的問題：
1）資料量很大的時候無法儲存
2）沒有很好的備份機制
3）資料達到一定數量開始緩慢，很大的話基本無法支撐
HBASE優勢：
1）線性擴充套件，隨著資料量增多可以通過節點擴充套件進行支撐
2）資料儲存在hdfs上，備份機制健全
3）通過zookeeper協調查詢資料，訪問速度塊。
二、HBase 架構及工作原理
1.HBase 架構
HBase 仍然採用Master/Slave架構，它隸屬於Hadoop生態系統。HBase將邏輯上的表劃分成多個數據塊即HRegion，儲存在HRegionServer中。
HMaster負責管理所有的HRegionServer，它本身並不儲存任何資料，而只是儲存資料到HRegionServer的對映關係（元資料）。叢集中的所有節點通過Zookeeper進行協調，並處理HBase執行期間可能遇到的各種問題。HBase 架構圖如下
各個元件的作用如下
Client
Client 數量為一個或多個，HBase Client 使用 HBase 的 RPC 機制與HMaster和HRegionServer進行通訊。
(1).對於管理類操作Client與HMaster進行RPC通訊
(2).對於資料讀寫操作Client與HRegionServer進行RPC通訊
Zookeeper
(1).保證叢集中只有一個正在執行的HMaster，如果HMaster掛了，通過Zookeeper的選舉機制保證叢集中總有一個HMaster執行，避免單點問題
(2).通過將叢集各節點狀態資訊註冊到Zookeeper中，使得HMaster可隨時感知各個HRegionServer的健康狀態
HMaster
(1).為HRegionServer分配Region，調整Region的分佈，管理HRegionServer的負載均衡
(2).HMaster中記錄了Region在哪臺Hregion server上，它管理所有的HRegionServer並告訴HRegionServer維護那些Region
(3).在HRegion Server宕機後，將失效HRegion Server 上的Regions遷移到其它的HRegionServer
HRegionServer
(1).維護Region，處理並響應這些Region的IO請求及響應
(2).HRegionServer管理了很多Table的分割槽，即Region，負責對超過閥值的Region進行切分(split)
HRegion
當表的大小超過預設值的時候，HRegion會自動按行對rowkey對應的資料進行拆分
HLog
HLog 是一個實現了WAL（Write Ahead Log）的預寫日誌類，其內部是一個簡單的順序日誌。每個HRegionServer上都有一個HLog，類似於mysql中的binlog。該日誌只會追加內容，用於記錄操作日誌，能用來做災難恢復（資料回滾到初始狀態）。
HStore
它是HBase的儲存核心，儲存的最小單元，由MemStore或0至多個StoreFile組成。
MemStore是記憶體緩衝區，使用者寫入的資料首先會放入MemStore，當MemStore滿了以後會Flush成一個StoreFile（底層實現是HFile，是HBase儲存資料的檔案組織形式），當StoreFile的檔案數量增長到一定閾值後，會觸發Compact合併操作，將多個StoreFiles合併成一個StoreFile，合併過程中會進行版本合併和資料刪除操作。
因此，可以看出HBase其實只有增加資料，所有的更新和刪除操作都是在後續的Compact過程中進行的，這樣使得使用者的寫操作只要進入記憶體就可以立即返回，保證了HBaseI/O的高效能。
資料flush過程如下：
(1).當memstore資料達到閾值（預設是64M），將資料刷到硬碟，將記憶體中的資料刪除，同時刪除Hlog中的歷史資料。
(2).並將資料儲存到hdfs中。
(3).在hlog中做標記點。
資料Compact合併過程如下：
(1).當資料塊達到4塊，hmaster將資料塊載入到本地，進行合併
(2).當合並的資料超過256M，進行拆分，將拆分後的region分配給不同的hregionserver管理
(3).當hregionser宕機後，將hregionserver上的hlog拆分，然後分配給不同的hregionserver載入，修改.META.（HBase 的內建表，儲存HBase 內部的系統資訊——Region的分佈情況以及每個Region的詳細資訊）
(4).注意：hlog會同步到hdfs
HBase 容錯
(1).HMaster 容錯
通過Zookeeper實現，如果HMaster掛掉，通過Zookeeper的選舉機制重新選擇一個新的HMaster
(2).HRegionServer容錯
RegionServer會定時向Zookeeper傳送心跳，如果一段時間內未出現心跳，Master將該RegionServer上的Region重新分配到其他RegionServer上。
(3).Zookeeper容錯
zookeeper是為其它分散式框架提供分散式協調服務的，本身並不是單點，一般都是奇數個zk組成的叢集，如果某一個掛掉後，zk會通過選舉機制重新選擇一個leader。
2.HBase 工作原理
寫資料流程：
(1).client向hregionserver傳送寫請求。
(2).Regionserver找到目標Region。
(3).Region會檢查資料是否與Schema一致。
(4).若客戶端沒有指定時間戳，預設取當前時間。
(5).hregionserver將資料寫到hlog（write ahead log）。為了資料的持久化和恢復。
(7).hregionserver將資料寫到記憶體memstore（判斷Memstore是否需要Flush為Storefile檔案）
(8).響應客戶端Client請求
讀資料流程：
(1).Client訪問ZK，查詢-ROOT-表，獲取.META.表資訊
(2).從.META.表查詢，獲取存放目標資料的HRegion資訊，從而找到對應的HRegionServer
(3).通過HRegionServer獲取需要查詢的資料
(4).Region會先從Memstore中查詢，命中則返回（先查Memstore的好處是在記憶體中，查詢快）。
(5).若Memstore沒有，則掃描StoreFile（這個過程可能會掃描很多StoreFIle），資料從記憶體和硬碟合併後快取到記憶體中的資料塊中最後響應給客戶端
讀取資料時zookeeper如何定位到Region，返回給Client資料？
-ROOT-和.META.是HBase內建的兩張表，儲存了HBase內部的一些系統資訊，.META.儲存Region的元資料（Region的分佈情況以及每個Region的詳細資訊），隨著HRegion的增多，.META.表中的資料也會增大，並拆分成多個新的HRegion。為了定位.META.表中各個HRegion的位置，把.META.表中所有HRegion的元資料儲存在-ROOT-表中。
所有客戶端訪問使用者資料前，需要首先訪問Zookeeper獲得-ROOT-的位置，然後訪問-ROOT-表獲得.META.表的位置，最後根據.META.表中的資訊確定使用者資料存放的位置，查詢到使用者資料，最後放回給Client，流程圖如下
三、HBase 資料模型及物理模型
1.資料模型
HBase 資料模型圖如下
HBase 核心術語介紹
一、Row Key（行健）
與nosql資料庫們一樣,row key是用來檢索記錄的主鍵。訪問HBASE table中的行，只有三種方式：
1.通過單個row key訪問
2.通過row key的range（正則）
3.全表掃描
row key行鍵 (Row key)可以是任意字串(最大長度 是 64KB，實際應用中長度一般為 10-100bytes)，在HBASE內部，row key儲存為位元組陣列。儲存時，資料按照row key的字典序(byte order)排序儲存。設計key時，要充分排序儲存這個特性，將經常一起讀取的行儲存放到一起。(位置相關性)
二、Columns Family（列族）
列簇 ：HBASE表中的每個列，都歸屬於某個列族（表中的每個列都儲存到某一個檔案中，即一個列族對應一個檔案）。列族是表的schema的一部 分(而列不是)，必須在使用表之前定義。列名都以列族作為字首。例如 courses:history，courses:math都屬於courses 這個列族。
三、Cell（列）
由{row key, columnFamily, version} 唯一確定的單元。cell中 的資料是沒有型別的，全部是位元組碼形式儲存。
關鍵字：無型別、位元組碼
四、Time Stamp（時間戳）
hbase 中 每儲存一條資料，它會預設為生成一個時間戳，也可以自己設定。每個 cell中，不同版本的資料按照時間倒序排序，即最新的資料排在最前面
2.物理模型
對於HBase 的物理模型我們分別從Table的分割、Region的拆分、Region的分佈，Region的構成四個部分介紹，下圖為HBase的物理模型圖
一、Table的分割
Table 中的所有行都按照 rowkey 的字典序排列，Table 在行的方向上分割為多個Region，一個Region在同一時刻只能被同一個RegionServer管理，RegionServer可以管理多個Region（一對多）
二、Region的拆分
Region是按大小分割的，新建立的表只有一個region（資料為空），隨著資料增多，region不斷增大，當增大到一個閥值時，region就會拆分為兩個新的region，之後會有越來越多的region。
那麼region為什麼要進行拆分吶？隨著資料越來越多，region越來越多，那麼對region的管理就比較麻煩，在我們的大資料環境下，經常會面臨大量的資料處理，拆分region是為了並行處理，提高效率。
三、Region 的分佈
Region 是 HBase 中分散式儲存和負載均衡的最小單元，不同的Region分佈到不同的RegionServer上，如下圖Table1、Table2中均有多個Region，這些Region分佈在不同的RegionServer中
四、Region的構成
Region雖然是分散式分散式儲存的最小單元，但並不是儲存的最小單元，Store是儲存的最小單元
Region由一個或者多個Store組成，每個Store會儲存一個Column Family；每個Store又由一個MemStore或0至多個StoreFile組成；MemStore儲存在記憶體中，StoreFile儲存在HDFS中，下圖為Region的構成，當我們向HBase插入資料時，會先存放到memStore（記憶體）中，然後再從記憶體中存放到磁碟檔案StoreFile中，磁碟檔案滿了之後再存放到HDFS中
四、HBase 優化
參考部落格：Hbase架構及工作原理、資料及物理模型、Hbase優化
推薦部落格：
1、Hbase架構及工作原理、資料及物理模型、Hbase優化
2、Hbase常用優化、Hbae效能優化、Hbase優化經驗總結