1. HBase簡介

1.1 什么是HBase

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

HBASE的目標是存儲并處理大型的數據，更具體來說是僅需使用普通的硬件配置，就能夠處理由成千上萬的行和列所組成的大型數據。

HBASE是Google Bigtable的開源實現，但是也有很多不同之處。比如：Google Bigtable使用GFS作為其文件存儲系統，HBASE利用Hadoop HDFS作為其文件存儲系統；Google運行MAPREDUCE來處理Bigtable中的海量數據，HBASE同樣利用Hadoop MapReduce來處理HBASE中的海量數據；Google Bigtable利用Chubby作為協同服務，HBASE利用Zookeeper作為協同服務。

1.2 與傳統數據庫的對比

1、傳統數據庫遇到的問題：
　　1）數據量很大的時候無法存儲；
　　2）沒有很好的備份機制；
　　3）數據達到一定數量開始緩慢，很大的話基本無法支撐；

2、HBASE優勢：
　　1）線性擴展，隨著數據量增多可以通過節點擴展進行支撐；
　　2）數據存儲在hdfs上，備份機制健全；
　　3）通過zookeeper協調查找數據，訪問速度快。

1.3 HBase集群中的角色

一個或者多個主節點，Hmaster；
多個從節點，HregionServer；
HBase依賴項，zookeeper；

2. HBase數據模型

image

2.1 HBase的存儲機制

HBase是一個面向列的數據庫，在表中它由行排序。表模式定義只能列族，也就是鍵值對。一個表有多個列族以及每一個列族可以有任意數量的列。后續列的值連續存儲在磁盤上。表中的每個單元格值都具有時間戳。總之，在一個HBase：

表是行的集合。
行是列族的集合。
列族是列的集合。
列是鍵值對的集合。

這里的列式存儲或者說面向列，其實說的是列族存儲，HBase是根據列族來存儲數據的。列族下面可以有非常多的列，列族在創建表的時候就必須指定。

HBase 和 RDBMS的比較

image

RDBMS的表：

image

HBase的表：

image

2.2 Row Key 行鍵

與nosql數據庫一樣，row key是用來表示唯一一行記錄的主鍵，HBase的數據時按照RowKey的字典順序進行全局排序的，所有的查詢都只能依賴于這一個排序維度。訪問HBASE table中的行，只有三種方式：

通過單個row key訪問；
通過row key的range（正則）
全表掃描

Row key 行鍵（Row key）可以是任意字符串(最大長度是64KB，實際應用中長度一般為10-1000bytes)，在HBASE內部，row key保存為字節數組。存儲時，數據按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。(位置相關性)

2.3 Columns Family 列族

列簇：HBASE表中的每個列，都歸屬于某個列族。列族是表的schema的一部分(而列不是)，必須在使用表之前定義。列名都以列族作為前綴。例如courses：history，courses：math 都屬于courses這個列族。

2.4 Cell

由{row key，columnFamily，version} 唯一確定的單元。cell中的數據是沒有類型的，全部是字節碼形式存儲。

2.5 Time Stamp 時間戳

HBASE中通過rowkey和columns確定的為一個存儲單元稱為cell。每個cell都保存著同一份數據的多個版本。版本通過時間戳來索引。時間戳的類型是64位整型。時間戳可以由HBASE(在數據寫入時自動)賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也可以由客戶顯示賦值。如果應用程序要避免數據版本沖突，就必須自己生成具有唯一性的時間戳。每個cell中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。

為了避免數據存在過多版本造成的管理(包括存儲和索引)負擔，HBASE提供了兩種數據版本回收方式。一是保存數據的最后n個版本，而是保存最近一段時間內的版本(比如最近7天)。用戶可以針對每個列族進行設置。

3. HBase原理

HBase系統架構體系圖

image

組成部件說明：

Client：

使用HBase RPC機制與HMaster和HRegionServer進行通信
　　Client與HMaster進行管理類操作
　　Client與HRegionServer進行數據讀寫類操作

Zookeeper：

Zookeeper Quorum存儲-ROOT-表地址、HMaster地址
　　HRegionServer把自己以Ephemeral方式注冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康狀況
　　Zookeeper避免HMaster單點問題

Zookeeper的主要作用：客戶端首先聯系ZooKeeper子集群（quorum）（一個由ZooKeeper節點組成的單獨集群）查找行健。上述過程是通過ZooKeeper獲取含有-ROOT-的region服務器名（主機名）來完成的。通過含有-ROOT-的region服務器可以查詢到含有.META.表中對應的region服務器名，其中包含請求的行健信息。這兩處的主要內容都被緩存下來了，并且都只查詢一次。最終，通過查詢.META服務器來獲取客戶端查詢的行健數據所在region的服務器名。一旦知道了數據的實際位置，即region的位置，HBase會緩存這次查詢的信息，同時直接聯系管理實際數據的HRegionServer。所以，之后客戶端可以通過緩存信息很好地定位所需的數據位置，而不用再次查找.META.表。

HMaster：

HMaster沒有單點問題，HBase可以啟動多個HMaster，通過Zookeeper的Master Election機制保證總有一個Master在運行
　　主要負責Table和Region的管理工作：

管理用戶對表的增刪改查操作
管理HRegionServer的負載均衡，調整Region分布
Region Split后，負責新Region的分布
在HRegionServer停機后，負責失效HRegionServer上Region遷移

HRegionServer：

HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫

image

HRegionServer管理一系列HRegion對象；
　　每個HRegion對應Table中一個Region，HRegion由多個HStore組成；
　　每個HStore對應Table中一個Column Family的存儲；
　　Column Family就是一個集中的存儲單元，故將具有相同IO特性的Column放在一個Column Family會更高效。

可以看到，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被分配給哪個RegionServer是完全動態的，所以需要機制來定位Region具體在哪個region server。

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

通過zookeeper里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一個region。
通過-ROOT-表查找.META.表的第一個表中相應的region的位置。.META.表中的每一個region在-ROOT-表中都是一行記錄。
通過.META.表找到所要的用戶表region的位置。用戶表中的每個region在.META表中都是一行記錄。

這個查找過程就像一個3層分布式B+樹(見下圖)，-ROOT-表是B+樹的-ROOT-節點。.META. region是-ROOT-節點(-ROOT-region)的葉子，用戶表的region是.META.region的葉子。

image

注意：

-ROOT-表永遠不會被分隔為多個region，保證了最多需要三次跳轉，就能定位到任意的region。client會將查詢的位置信息緩存起來，緩存不會主動失效，因此如果client上的緩存全部失效，則需要進行6次網絡來回，才能定位到正確的region，其中三次用來發現緩存失效，另外三次用來獲取位置信息。

table和region的關系：

table默認最初只有一個region，隨著記錄數的不斷增加而變大，起初的region會逐漸分裂成多個region，一個region有【startKey, endKey】表示，不同的region會被master分配給相應的regionserver管理。region是hbase分布式存儲和負載均衡的最小單元，不同的region分不到不同的regionServer。region雖然是分布式存儲的最小單元，但并不是存儲的最小單元。region是由一個或者多個store組成的，每個store就是一個column family。每個store又由memStore和1至多個store file 組成(memstore到一個閥值會刷新，寫入到storefile，有hlog來保證數據的安全性，一個regionServer有且只有一個hlog)

HStore：

HBase存儲的核心。由MemStore和StoreFile組成。MemStore是Stored Memory Buffer。
HLog：

引入HLog原因：在分布式系統環境中，無法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種情況。

工作機制：
　　每個HRegionServer中都會有一個HLog對象，HLog是一個實現Write Ahead Log的類，每次用戶操作寫入MemStore的同時，也會寫一份數據到HLog文件，HLog文件定期會滾動出新，并刪除舊的文件(已持久化到StoreFile中的數據)。當HRegionServer意外終止后，HMaster會通過Zookeeper感知，HMaster首先處理遺留的HLog文件，將不同region的log數據拆分，分別放到相應region目錄下，然后再將失效的region重新分配，領取到這些region的HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然后flush到StoreFiles，完成數據恢復。

3.1 HBase的存儲格式

HBase中的所有數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種：

HFile，HBase中Key-Value數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile。
HLog File，HBase中WAL(Write Ahead Log)的存儲格式，物理上是Hadoop的Sequence File

HFile

image

解析：

HFile文件不定長，長度固定的塊只有兩個：Trailer和FileInfo

Trailer中指針指向其他數據塊的起始點

File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點

Data Block是HBase I/O的基本單元，為了提高效率，HRegionServer中有基于LRU的Block Cache機制

每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利于順序Scan，小號Block利于隨機查詢

每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞

HFile里面的每個KeyValue對就是一個簡單的byte數組。這個byte數組里面包含了很多項，并且有固定的結構。

image

KeyLength和ValueLength：兩個固定的長度，分別代表Key和Value的長度

Key部分：Row Length是固定長度的數值，表示RowKey的長度，Row 就是RowKey

Column Family Length是固定長度的數值，表示Family的長度

接著就是Column Family，再接著是Qualifier，然后是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）

Value部分沒有這么復雜的結構，就是純粹的二進制數據

HLog File

image

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

HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue

3.2 寫流程

image

1) Client通過Zookeeper的調度，向RegionServer發出寫數據請求，在Region中寫數據；

2) 數據被寫入Region的MemStore，知道MemStore達到預設閥值(即MemStore滿)；

3) MemStore中的數據被Flush成一個StoreFile；

4) 隨著StoreFile文件的不斷增多，當其數量增長到一定閥值后，觸發Compact合并操作，將多個StoreFile合并成一個StoreFile，同時進行版本合并和數據刪除；

5) StoreFiles通過不斷的Compact合并操作，逐步形成越來越大的StoreFile；

6) 單個StoreFile大小超過一定閥值后，觸發Split操作，把當前Region Split成2個新的Region。父Region會下線，新Split出的2個子Region會被HMaster分配到相應的RegionServer上，使得原先1個Region的壓力得以分流到2個Region上。

可以看出HBase只有增添數據，所有的更新和刪除操作都是在后續的Compact歷程中舉行的，使得用戶的寫操作只要進入內存就可以立刻返回，實現了HBase I/O的高性能。

3.3 讀流程

1) Client訪問Zookeeper，查找-ROOT-表，獲取.META.表信息；

2) 從.META.表查找，獲取存放目標數據的Region信息，從而找到對應的RegionServer；

3) 通過RegionServer獲取需要查找的數據；

4) RegionServer的內存分為MemStore和BlockCache兩部分，MemStore主要用于寫數據，BlockCache主要用于讀數據。讀請求先到MemStore中查數據，查不到就到BlockCache中查，再查不到就會到StoreFile上讀，并把讀的結果放入BlockCache。

尋址過程：client—>Zookeeper—>ROOT表—>.META. 表—>RegionServer—>Region—>client

4. HBASE命令

4.1 命令的進退

1、hbase提供了一個shell的終端給用戶交互

hbase shell

image

2、如果退出執行quit命令

image

4.2 命令

名稱	命令表達式
查看 hbase 狀態	status
創建表	create '表名','列族名 1','列族名 2','列族名 N'
查看所有表	list
描述表	describe '表名'
判斷表存在	exists '表名'
判斷是否禁用啟用表	is_enabled '表名' is_disabled '表名'
添加記錄	put '表名','rowkey','列族：列'，'值'
查看記錄 rowkey 下的所有數據	get '表名','rowkey'
查看所有記錄	scan '表名'
查看表中的記錄總數	count '表名'
獲取某個列族	get '表名','rowkey','列族：列'
獲取某個列族的某個列	get '表名','rowkey','列族：列'
刪除記錄	delete '表名','行名','列族：列'
刪除整行	deleteall '表名','rowkey'
刪除一張表	先要屏蔽該表，才能對該表進行刪除第一步 disable '表名'，第二步 drop '表名'
清空表	truncate '表名'
查看某個表某個列中所有數據	scan '表名',{COLUMNS=>'列族名：列名'}
更新記錄	就是重新一遍，進行覆蓋，hbase 沒有修改，都是追加