HBase01

1. HBase基本介紹

a. 介紹

Hbase是一個nosql的列式存儲的數據庫。實際來源於Google發表的論文bigtable。構建在hdfs基礎之上。

1. 提供高可用，高性能，列儲存，可伸縮，實時讀寫nosql的數據庫系統。
2. 按照key-value的形式進行數據的存儲：rowkey(行鍵)，經過行鍵完成數據的檢索。
3. Hbase僅支持簡單的事務（行級操做），不支持複雜的操做（不能join等操做）。
4. Hbase的數據類型單一：byte[]
5. 和hadoop同樣，Hbase依靠橫向拓展，增長服務器，提升計算能力。

b. Hbase的特色

1. 大：數據量大
2. 面向列：數據按照列式的方式進行儲存。
3. 稀疏：habase中null的數據不會佔用存儲空間

2. Hbase和hadoop的關係

a. hdfs

1. 爲分佈式存儲提供文件系統
2. 針對存儲大尺寸的文件進行優化，不須要對HDFS上的文件進行隨機讀寫
3. 直接使用文件
4. 數據模型不靈活
5. 使用文件系統和處理框架
6. 優化一次寫入，屢次讀取的方式

b. Hbase

1. 提供列式存儲
2. 能夠對數據進行隨機讀取按照key-value形式操做數據
3. 支持mr，依賴hdfs
4. 優化屢次讀或者寫

總結：緊耦合關係，Hbase依賴於hdfs

3. RDBMS和Hbase對比

Hbase：

• 結構：

1. 1. 數據庫以region的形式存在
   2. 支持hdfs
   3. 使用WAL存儲日誌（寫前日誌）
   4. 參考系統的zookeeper（耦合）
   5. 使用行鍵（rowkey）
   6. 支持分片
   7. 使用行 列 列族（column family） 單元格

4. Hbase的簡要特徵

• 海量存儲：適合存儲PB級別的數據
• 列式存儲：數據按照列存儲，再進一步，按照列族形式存儲
• 極易拓展：
  • RegionServer：針對reginserver管理的拓展
  • 針對數據存儲的拓展

高併發：hbase的IO操做不會下降

稀疏：對於null的數據不進行儲存

5. Hbase的總體架構

HMaster：

1. 監控RegionServer
2. 處理RegionServer的故障轉移
3. 處理元數據的變動
4. 處理region的分配或移除
5. 在空閒時間進行數據的負載均衡

RegionServer：

1. 負責存儲HBase的實際數據
2. 處理分配給它的Region 
3. 刷新緩存到HDFS 
4. 維護HLog 
5. 執行壓縮
6. 負責處理Region分片

相關組件：

1. WAL：用於數據恢復，當Hbase讀寫數據的時候，不是直接寫進磁盤，他會在內存中保留一點時間，數據在內存中可能會丟失，爲了解決這個問題，會先卸載write-ahead-logfile中，而後在寫入內存，出現故障時，能夠經過日誌恢復
2. HFile：hbase數據的存儲文件，實際的存儲文件
3. Store：Hifile存在store中，一個store對應一個column對應一個column family（列族）
4. memestore：緩存存儲，默認128M
5. region：一張表的部分或者所有數據

6. Hbase的安裝

https://blog.csdn.net/oschina_41140683/article/details/82752115

7. Hbase底層原理

client：包含訪問hbase的接口，client維護着一些cache來加快對hbase的訪問，好比region的位置信息、

zookeeper：

1. 保證任什麼時候候，集羣中只有一個master。
2. 存儲全部的Region的尋址入口
3. 實時監控Region Server的狀態，將Region Server的上線和下線通知給Master

Master：

1. 爲Region Server分配Region
2. 負責Region server的負載均衡
3. 發現失效的Region Server並從新分配其上面的region到正常上的Region Server
4. Hdfs上面的垃圾回收
5. 處理schema更新請求

Region Server：

Region server負責維護Master分配給它的region，處理對這些region的io請求

Region server負責切分在運行過程當中變得過大的region。

總結：能夠看到client訪問hbase上數據的過程並不須要master參與（尋址訪問zookeeper和region server，數據讀寫訪問region server），master僅僅維護着table和region的元數據信息，負載很低。

a. Hbase的表數據模型

1. 1. row key：行鍵，一行的主鍵，惟一值，最大長度64，建議10-100個字節，按照字典進行排序。設計時，要考慮排序存儲這個特性，將常常一塊兒讀取的行存儲到一塊兒。
   2. column family（列族）：列族是表的schema的一部分，必須在使用表以前定義，列名都是以列族做爲前綴courses：math，courses：history都屬於這個列族。訪問控制，磁盤和內存的使用統計都在列族的層面上進行的。列族越多，在取一行數據時，所參與的io，搜尋的文件就越多。通常三個左右的列族。
   3. qualifier：列，一個列族下面的字段。
   4. version：數據的版本。每條數據有多個版本號，默認是系統時間戳，類型Long
   5. timestamp：版本經過時間戳來索引，時間戳，在數據寫入時自動賦值，類型是64位整形。
   6. Cell：由{row key, column( =<family> + <label>), version} 惟一肯定的單元。cell中的數據是沒有類型的，所有是字節碼形式存貯。

b. 總體結構

 

1. table中的全部行都按照row key的字典排序
2. table在行的方向上分割爲多個Hregion
3. region按大小分割（默認是10g）,每個表一開始只有一個region，隨着數據不斷插入表，region不斷增大，當增大到必定的閥值的時候，hregion就會等分爲兩個新的Hregion，當table中國的行不斷增多的時候，就會有多個Hregion。
4. Hregion是Hbase中分佈式存儲和負載均衡的最小單元，最小單元表示，不一樣的Hregion能夠分佈到不一樣的Region Server上面。一個Region不會拆分到多個Server上的。
5. HRegion、雖然是負載均衡的最小單元，但並非物理存儲的最小單元。Hregion由一個或多個Store組成，每一個store保存着一個column family。每一個store又由一個memStore和0至多個StoreFile組成。

 c. Store File和HFile：Store File以HFile格式保存在HDFS上

 

1. 1. Data Block 段–保存表中的數據，這部分能夠被壓縮
   2. Meta Block 段 (可選的)–保存用戶自定義的kv對，能夠被壓縮。
   3. File Info 段–Hfile的元信息，不被壓縮，用戶也能夠在這一部分添加本身的元信息。
   4. Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。
   5. Meta Block Index段 (可選的)–Meta Block的索引。
   6. Trailer–這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先 讀取Trailer，Trailer保存了每一個段的起始位置(段的Magic Number用來作安全check)，而後，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不須要掃描整個HFile，而只需從內存中找到key所在的block，經過一次磁盤io將整個 block讀取到內存中，再找到須要的key。DataBlock Index採用LRU機制淘汰。
   7. HFile的Data Block，Meta Block一般採用壓縮方式存儲，壓縮以後能夠大大減小網絡IO和磁盤IO，隨之而來的開銷固然是須要花費cpu進行壓縮和解壓縮。
   8. 目標Hfile的壓縮支持兩種方式：Gzip，Lzo。

d. MemStore和Storefile

 　　一個region由多個store組成，每一個store包含一個列族的全部數據。store包括位於內存memestore和位於磁盤的storefile。寫操做寫入memstore，當memestore達到必定閾值的時候，Hregion server啓動flush寫入storefile，當storefile大小超過必定閾值後，會把當前的region分割成兩個，並分割成兩個，並由Hmaster分配給相應的region服務器，實現負載均衡。客戶端檢索數據時，會如今memestore中尋找，找不到再去storefile。

e. HLog

　　每一個Region Server維護一個Hlog,而不是每一個Region一個。這樣不一樣region(來自不一樣table)的日誌會混在一塊兒，這樣作的目的是不斷追加單個文件相對於同時寫多個文件而言，能夠減小磁盤尋址次數，所以能夠提升對table的寫性能。帶來的麻煩是，若是一臺region server下線，爲了恢復其上的region，須要將region server上的log進行拆分，而後分發到其它region server上進行恢復。

HLog文件就是一個普通的Hadoop Sequence File：

1. HLog Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是」寫入時間」，sequence number的起始值爲0，或者是最近一次存入文件系統中sequence number。
2. HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue，可參見上文描述。

f. 讀請求過程

1. Client先訪問zookeeper，找到meta表，並獲取meta數據
2. 肯定當前要寫入數據的HRegion和HRegionServer
3. Client向該HReginServer發起寫入請求，而後HRegionServer收到請求並響應
4. Client先把數據寫到HLOG再將數據寫到MemStore
5. 若是HLog和Metastore都寫入成功，則這條數據寫入成功
6. 若是Memstore達到閾值，會flush到StoreFile中
7. 當StoreFile愈來愈多，會觸發Compact合併操做，把過多的StoreFile合成一個StoreFile
8. 當StoreFile愈來愈大，Region也會愈來愈大，達到閾值時，會觸發split操做，將Region一分爲二。

• 細節描述：

1. hbase使用MemStore和StoreFile存儲對錶的更新。
2. 數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到必定閾值時，就會建立一個新的MemStore，並 且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個StoreFile。於此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻以前的變動已經持久化了。
3. 當系統出現意外時，可能致使內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint以後的數據。
4. StoreFile是隻讀的，一旦建立後就不能夠再修改。所以Hbase的更新實際上是不斷追加的操做。當一個Store中的StoreFile達到必定的閾值後，就會進行一次合併(minor_compact, major_compact),將對同一個key的修改合併到一塊兒，造成一個大的StoreFile，當StoreFile的大小達到必定閾值後，又會對 StoreFile進行split，等分爲兩個StoreFile。
5. 因爲對錶的更新是不斷追加的，compact時，須要訪問Store中所有的 StoreFile和MemStore，將他們按row key進行合併，因爲StoreFile和MemStore都是通過排序的，而且StoreFile帶有內存中索引，合併的過程仍是比較快。

g. Region管理

1. region分配：任什麼時候刻，一個region只能分配給一個region server。master會記錄當前有哪些可用的region server，以及當前的region分配給了哪些region server，哪些region尚未分配，當須要分配region的時候，而且有一個region server上面有可用的空間時，master就會給這個region server 發送一個裝載請求把region分配給regin server。regin server收到請求後，對此region進行服務。
2. Region Server上線：master使用zookeeper跟蹤region server狀態，當某個region server啓動時，會在zookeeper上的server建立znode的表明本身，因爲master訂閱了server目錄上的變動消息，當server目錄下文件新增或者刪除時候，master就能收到zookeeper的實時通知。
3. Region Server下線：當Region server下線時候，和zookeeper的會話會斷開，zookeeper而自動釋放表明這臺server的文件上的獨佔鎖，master就能夠肯定：region server下線了，region server 掛了。不管哪一種狀況，region server沒法爲他的region服務了，master會刪除server目錄下表明這臺region server的znode數據，並將這臺region server的region分配給其餘活着的region server。

h. Master工做機制

1. master上線

• 從zookeeper上獲取惟一一個表明active master的鎖，用來阻止其它master成爲master。
• 掃描zookeeper上的server父節點，得到當前可用的region server列表。
• 和每一個region server通訊，得到當前已分配的region和region server的對應關係。
• 掃描.META.region的集合，計算獲得當前還未分配的region，將他們放入待分配region列表。

2. master下線

• 因爲master只維護表和region的元數據，而不參與表數據IO的過程，master下線僅致使全部元數據的修改被凍結(沒法建立刪除表，沒法修改表的schema，沒法進行region的負載均衡，沒法處理region 上下線，沒法進行region的合併，惟一例外的是region的split能夠正常進行，由於只有region server參與)，表的數據讀寫還能夠正常進行。所以master下線短期內對整個hbase集羣沒有影響。

3. 從上線過程能夠看到，master保存的信息全是能夠冗餘信息（均可以從系統其它地方收集到或者計算出來）

4. 所以，通常hbase集羣中老是有一個master在提供服務，還有一個以上的‘master’在等待時機搶佔它的位置。