HBase 簡介

Hbase 介紹

HBase ——Hadoop Database，是一個高可靠、高性能、面向列、可伸縮的分佈式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集羣。

HBase是Google Bigtable的開源實現，相似Google Bigtable利用GFS做爲其文件存儲系統，HBase 利用Hadoop HDFS做爲其文件存儲系統；Google運行MapReduce來處理Bigtable中的海量數據，HBase一樣利用Hadoop MapReduce來處理HBase中的海量數據；Google BigTable利用Chubby做爲協同服務，HBase使用的是Zookeeper做爲對應。

 

HBase位於結構化存儲層，HDFS爲HBase提供了高可靠性的底層存儲支持，MapReduce爲HBase提供了高性能的計算能力，Zookeeper爲HBase提供了穩定服務和failover機制。

 

此外，Pig和Hive爲Hbase提供了高層語言支持，使得在HBase上進行數據統計處理變得簡單。
Sqoop則爲HBase提供了方便的RDBMS數據導入功能。

 

HBase官網： http://hbase.apache.org/

HBase特色

• 強一致性讀寫：HBase 不是「eventually consistent（最終一致性）」數據存儲。這讓它很適合高速計數聚合類任務；
• 自動分片(Automatic sharding)： HBase 表經過 region 分佈在集羣中。數據增加時，region 會自動分割並從新分佈；
• RegionServer 自動故障轉移；
• Hadoop/HDFS 集成：HBase 支持開箱即用地支持 HDFS 做爲它的分佈式文件系統；
• MapReduce： HBase 經過 MapReduce 支持大併發處理；
• Java 客戶端 API：HBase 支持易於使用的 Java API 進行編程訪問；
• Thrift/REST API：HBase 也支持 Thrift 和 REST 做爲非 Java 前端的訪問；
• Block Cache 和 Bloom Filter：對於大容量查詢優化， HBase 支持 Block Cache 和 Bloom Filter；
• 運維管理：HBase 支持 JMX 提供內置網頁用於運維。

 

HBase應用場景

• 足夠多數據，上億或上千億行數據
• 不依賴RDBMS的特性，如列類型、第二索引、事務、高級查詢等
• 有足夠的硬件，少於5節點Hadoop時，基本體現不出優點

優缺點

優勢

• 列的能夠動態增長，而且列爲空就不存儲數據，節省存儲空間
• Hbase 自動切分數據，使得數據存儲自動具備水平擴展
• Hbase 能夠提供高併發讀寫操做的支持
• 與 Hadoop MapReduce 相結合有利於數據分析
• 容錯性
• 版權免費
• 很是靈活的模式設計（或者說沒有固定模式的限制）
• 能夠跟 Hive 集成，使用類 SQL 查詢
• 自動故障轉移
• 客戶端接口易於使用
• 行級別原子性，即，PUT 操做必定是徹底成功或者徹底失敗

 

缺點

 

• 不能支持條件查詢，只支持按照 row key 來查詢
• 容易產生單點故障（在只使用一個 HMaster 的時候）
• 不支持事務
• JOIN 不是數據庫層支持的，而須要用 MapReduce
• 只能在逐漸上索引和排序
• 沒有內置的身份和權限認證

 

HBase 訪問接口

• Native Java API
• HBase Shell
• Thrift Gateway
• REST Gateway：支持REST網格的HTTP API訪問HBase
• Pig：Pig Latin流式編程語言來操做HBase中的數據。
• Hive：0.7.0版本的Hive加入HBase

HBase 數據模型

• Row Key: 行鍵，Table的主鍵，Table中的記錄按照Row Key排序
• Timestamp: 時間戳，每次數據操做對應的時間戳，能夠看做是數據的version number
• Column Family：列簇，Table在水平方向有一個或者多個Column Family組成，一個Column Family中能夠由任意多個Column組成，即Column Family支持動態擴展，無需預先定義Column的數量以及類型，全部Column均以二進制格式存儲，用戶須要自行進行類型轉換。

Table & Region

當Table隨着記錄數不斷增長而變大後，會逐漸分裂成多份splits，成爲regions，一個region由[startkey,endkey)表示，不一樣region會被Master分配給相應的RegionServer進行管理。

HBase中有兩張特殊的Table， -ROOT- 和 .META.
- .META. ：記錄了用戶表的Region信息，.META.能夠有多個region
- -ROOT-：記錄了.META.表的Region信息，-ROOT-只有一個region
- Zookeeper中記錄了-ROOT-表的location
Client訪問用戶數據以前須要先訪問zookeeper，而後訪問-ROOT-表，接着訪問.META.表，最後才能找到用戶數據的位置去訪問，中間須要屢次網絡操做，不過client端會作cache緩存。

MapReduce on HBase

HBase：存儲結構

摘要： 從HBase的架構圖上能夠看出，HBase中的存儲包括HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，本篇文章統一介紹他們的做用即存儲結構。

 

從HBase的架構圖上能夠看出，HBase中的存儲包括HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，本篇文章統一介紹他們的做用即存儲結構。

 

如下是網絡上流傳的HBase存儲架構圖:

 

 

HBase中的每張表都經過行鍵按照必定的範圍被分割成多個子表（HRegion），默認一個HRegion超過256M就要被分割成兩個，這個過程由HRegionServer管理，而HRegion的分配由HMaster管理。

 

HMaster的做用：

 

• 爲Region server分配region
• 負責Region server的負載均衡
• 發現失效的Region server並從新分配其上的region
• HDFS上的垃圾文件回收
• 處理schema更新請求

 

HRegionServer做用：

 

• 維護master分配給他的region，處理對這些region的io請求
• 負責切分正在運行過程當中變的過大的region

 

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

 

HRegionServer存取一個子表時，會建立一個HRegion對象，而後對錶的每一個列族建立一個Store實例，每一個Store都會有一個MemStore和0個或多個StoreFile與之對應，每一個StoreFile都會對應一個HFile， HFile就是實際的存儲文件。所以，一個HRegion有多少個列族就有多少個Store。

 

一個HRegionServer會有多個HRegion和一個HLog。

HRegion

 

table在行的方向上分隔爲多個Region。Region是HBase中分佈式存儲和負載均衡的最小單元，即不一樣的region能夠分別在不一樣的Region Server上，但同一個Region是不會拆分到多個server上。

Region按大小分隔，每一個表一行是隻有一個region。隨着數據不斷插入表，region不斷增大，當region的某個列族達到一個閾值（默認256M）時就會分紅兩個新的region。

每一個region由如下信息標識：

• <表名,startRowkey,建立時間>
• 由目錄表(-ROOT-和.META.)可值該region的endRowkey

 

HRegion定位：

 

Region被分配給哪一個Region Server是徹底動態的，因此須要機制來定位Region具體在哪一個region server。

 

HBase使用三層結構來定位region：

 

• 一、 經過zk裏的文件/hbase/rs獲得-ROOT-表的位置。-ROOT-表只有一個region。
• 二、經過-ROOT-表查找.META.表的第一個表中相應的region的位置。其實-ROOT-表是.META.表的第一個region；.META.表中的每個region在-ROOT-表中都是一行記錄。
• 三、經過.META.表找到所要的用戶表region的位置。用戶表中的每一個region在.META.表中都是一行記錄。

 

 

-ROOT-表永遠不會被分隔爲多個region，保證了最多須要三次跳轉，就能定位到任意的region。client會講查詢的位置信息保存緩存起來，緩存不會主動失效，所以若是client上的緩存所有失效，則須要進行6次網絡來回，才能定位到正確的region，其中蠶絲用來發現緩存失效，另外三次用來獲取位置信息。

 

Store

每個region有一個或多個store組成，至少是一個store，hbase會把一塊兒訪問的數據放在一個store裏面，即爲每一個ColumnFamily建一個store，若是有幾個ColumnFamily，也就有幾個Store。一個Store由一個memStore和0或者多個StoreFile組成。

 

HBase以store的大小來判斷是否須要切分region。

MemStore

memStore 是放在內存裏的。保存修改的數據即keyValues。當memStore的大小達到一個閥值（默認64MB）時，memStore會被flush到文件，即生成一個快照。目前hbase 會有一個線程來負責memStore的flush操做。

 

StoreFile

memStore內存中的數據寫到文件後就是StoreFile，StoreFile底層是以HFile的格式保存。

 

HFile

HBase中KeyValue數據的存儲格式，是hadoop的二進制格式文件。

 

首先HFile文件是不定長的，長度固定的只有其中的兩塊：Trailer和FileInfo。Trailer中又指針指向其餘數據塊的起始點，FileInfo記錄了文件的一些meta信息。

 

Data Block是hbase io的基本單元，爲了提升效率，HRegionServer中又基於LRU的block cache機制。每一個Data塊的大小能夠在建立一個Table的時候經過參數指定（默認塊大小64KB），大號的Block有利於順序Scan，小號的Block利於隨機查詢。每一個Data塊除了開頭的Magic之外就是一個個KeyValue對拼接而成，Magic內容就是一些隨機數字，目的是煩着數據損壞，結構以下。

 

 

HFile結構圖以下：

 

 

Data Block段用來保存表中的數據，這部分能夠被壓縮。

 

Meta Block段（可選的）用來保存用戶自定義的kv段，能夠被壓縮。

 

FileInfo段用來保存HFile的元信息，本能被壓縮，用戶也能夠在這一部分添加本身的元信息。

 

Data Block Index段（可選的）用來保存Meta Blcok的索引。

 

Trailer這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer保存了每一個段的起始位置(段的Magic Number用來作安全check)，而後，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不須要掃描整個HFile，而只需從內存中找到key所在的block，經過一次磁盤io將整個 block讀取到內存中，再找到須要的key。DataBlock Index採用LRU機制淘汰。

 

HFile的Data Block，Meta Block一般採用壓縮方式存儲，壓縮以後能夠大大減小網絡IO和磁盤IO，隨之而來的開銷固然是須要花費cpu進行壓縮和解壓縮。目標HFile的壓縮支持兩種方式：gzip、lzo。

 

 

另外，針對目前針對現有HFile的兩個主要缺陷：

 

• a) 暫用過多內存
• b) 啓動加載時間緩慢

 

提出了HFile Version2設計：https://issues.apache.org/jira/secure/attachment/12478329/hfile_format_v2_design_draft_0.1.pdf

 

HLog

 

其實HLog文件就是一個普通的Hadoop Sequence File， Sequence File的value是key時HLogKey對象，其中記錄了寫入數據的歸屬信息，除了table和region名字外，還同時包括sequence number和timestamp，timestamp是寫入時間，equence number的起始值爲0，或者是最近一次存入文件系統中的equence number。

 

Sequence File的value是HBase的KeyValue對象，即對應HFile中的KeyValue。

 

 

HLog(WAL log)：WAL意爲write ahead log，用來作災難恢復使用，HLog記錄數據的全部變動，一旦region server 宕機，就能夠從log中進行恢復。

 

LogFlusher

前面提到，數據以KeyValue形式到達HRegionServer，將寫入WAL，以後，寫入一個SequenceFile。看過去沒問題，可是由於數據流在寫入文件系統時，常常會緩存以提升性能。這樣，有些本覺得在日誌文件中的數據實際在內存中。這裏，咱們提供了一個LogFlusher的類。它調用HLog.optionalSync(),後者根據hbase.regionserver.optionallogflushinterval (默認是10秒)，按期調用Hlog.sync()。另外，HLog.doWrite()也會根據 hbase.regionserver.flushlogentries (默認100秒)按期調用Hlog.sync()。Sync() 自己調用HLog.Writer.sync()，它由SequenceFileLogWriter實現。

LogRoller

Log的大小經過$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默認是一個小時。因此每60分鐘，會打開一個新的log文件。長此以往，會有一大堆的文件須要維護。首先，LogRoller調用HLog.rollWriter()，定時滾動日誌，以後，利用HLog.cleanOldLogs()能夠清除舊的日誌。它首先取得存儲文件中的最大的sequence number，以後檢查是否存在一個log全部的條目的「sequence number」均低於這個值，若是存在，將刪除這個log。

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