2018-12-13
2018-12-20
本篇文章旨在針對初學者以我本人現階段所掌握的知識就HBase的架構圖中各模塊作一個概念科普。不對文章內容的“絕對、完全正確性”負責。
1、開胃小菜
關於HBase的架構圖，直接抓取網絡上圖片來分析就好了。它大概長成下面的樣子：
圖1 HBase架構圖
從上圖中可以很直觀地看到整個HBase都是基於HDFS之上的。這個HDFS呢，它的全稱是Hadoop distributed file system，Hadoop分布式文件系統。關於在《HBase入門指南》中提到的HBase的概念：HBase是一個用於處理大數據的分布式數據庫軟件。它的分布式特性在這張架構圖中已經很直觀地體現出來了，並且它的分布式能力是由Hadoop來提供並保證的。（其實哦，HBase的分布式能力並不一定非得基於HDFS的，理論上你任意一個分布式軟件都能用來給HBase“基於”用，只不過由於HDFS太流行了，加上大多數的人其實都挺忙的，不喜歡瞎折騰，就拿HDFS來湊合過唄還能換咋的。。。）
上面圖1其實挺零亂挺復雜的，對於這么復雜的一張圖，小白同學表示他剛一進來，什么都不知道，就看到常威在打來福。。。哦哦，不是，小白同學說本來我學HBase的干勁挺足的，但剛開始就看到這張圖，着實很打擊小白同學的自信心啊。既然如此，那我們就來稍微給它簡化一下。圖1中的各種元素其實都是有它們各自的派系的，稍微划分一下派系后后它大概長成下圖2的樣子：
圖2 HBase架構派系划分
上圖2給這個架構圖加了幾個框框，把它們分成了四個派系A, B, C, D。這個框框雖然很不明顯，但是眼睛睜大點還是能看清的，就當鍛煉鍛煉視力了。
A派系呢就像是王自如的Zealer手機測評團隊一樣，是獨立客觀以及第三方的。它就是上帝，A呢就是B, C, D存在的意義。
B派系是Zookeeper，它是用來保證HBase集群的一致性的。
C派系就是HBase集群了。有些同學可能發現了，C派系HBase中好像霸占了架構圖中Zookeeper的一部分啊，這是畫錯了嗎？非也，其實之所以這樣划分，是因為現在的HBase軟件體系中已經集成了有Zookeeper模塊了，在默認的情況下，你不需要下載一個額外的Zookeeper軟件，也能夠正常運行HBase系統，並且擁有一個Zookeeper相關的進程。因此C派系中也占有了一丟丟Zookeeper的內容。但是其實是生產環境中，很少會用HBase自帶的Zookeeper的。
D派系呢，就是任勞任怨的HDFS了。
上面簡單的了解了一下HBase架構圖中的各大派系，相信到這里，各位小白同學能夠稍微對這張HBase的架構圖不那么陌生了。什么？上面的圖還是太惡心？好吧，那我們再進一步的處理一下這張圖片，這次我直接放大招，把HBase架構圖抽象一下，排除一切外在干擾，就不信你還看不懂它們之間的關系。看下圖：
圖3 HBase架構圖抽象版
2、架構圖詳解
繼續繼續，下面要詳細講講圖1 HBase架構中各模塊的含義了，這部分的內容就相當讓人腦闊疼咯。我們以上帝視角，從客戶端Client自上往下講起。
2.1、Client
首先還是要來了解一下概念。Client到底是什么東東？
從廣義的角度來說， Client其實就是你自己，Client是人！上面我們才剛剛講過，B, C, D，也就是Hadoop， HBase以及Zookeeper存在的意義就是要服務於A，也就是Client，也就是人。假如都沒有人去操作這個HBase系統了，那你HBase系統的功能再強大又有什么意義呢？有的同學可能要抬杠了，說人家企業里的HBase系統，都是無人植守，按照程序自動去運行，一樣跑的很嗨啊，哪像你說的那樣，沒有人去操作HBase系統就沒有意義了。好的，這位同學請坐下。這些跑的很嗨的程序還不是由人去寫的。。程序其實就是人類的意志的產物而已，程序怎么跑還不是由人說了算。所以，歸根結底。無論是你坐在電腦前對着hbase shell敲命令行，還是自己寫代碼去操縱HBase，亦或是在地球的另一端通過各種軟件來向HBase下達指令，你就是Client。
那從狹義的角度來說，我們下到代碼層面來說，Client是HBase開放出來給程序員們使用的各種API接口。Client也像是一個承上啟下的角色，對上要接收來自人的意志，對下要將人的意志轉化成一條條HBase程序並逐一執行。
那說了這么多，Client在HBase系統中有什么用呢？其實它只有一個作用。
- 它是整個HBase系統的入口。
在代碼層面來講，它就是各種API接口。有了這些接口，我們就可以實現對數據的CURD，甚至是發送一些管理級的命令。
2.2、Zookeeper
Zookeeper也是Apache軟件基金會中的一個頂級項目。它是給分布式系統提供協同服務的軟件。協同服務是什么鬼？也許會有不少人對這個詞很陌生。下面我們就來解釋一下什么是協同服務。
Zookeeper從字面上翻譯過來就是：動物園管理員。那為什么會起這么個名字呢？原來啊Apache軟件基金會下面關於分布式的軟件有很多，它們基本都會聯系上一種動物，或名字或LOGO。如Hadoop（小象象）,Pig（油膩豬）,Hive（怪蜜蜂）,HBase（酷海豚）等等等等。那么，在分布式應用當中，同步無疑是其最重要的特性，常有的同步包括：
1、配置同步；
2、時間同步；
3、相互感知（集群中各主機的上線下線消息及各種狀態）。
上面提到的這幾個“同步”就是“協同”的白話語言。
而為了 blah,blah,blah... 就需要一個Zookeeper來專門負責這種“同步服務”。
除了“同步服務”以外，Zookeeper還保存着HBase系統中的配置信息。什么配置信息呢？
1、master與slaver機器的信息
地址啊端口啊這些。
HMaster可以通過查詢Zookeeper來了解當前哪些slaver還在正常工作當中。
假如當前master宕機了，Zookeeper還可以通過保存着的backup master的信息來重新推選出一個新的master，起到保證HBase系統高可用性的作用。
2、保存 hbase:meta 表所在的位置
hbase:meta 表在HBase中是非常重要的一張表，它是由HBase系統創建並維護的。這里暫且記住它非常重要就好了。
3、保存HBase系統中所有的表信息
假如客戶端發起一個CRUD請求，首先要知道這張表存不存在吧，又保存在哪吧。通過Zookeeper就可以實現非常快速的響應，因為整個Zookeeper都是駐留在內存中的。
4、其它信息
還有各種雜七雜八但很重要的信息，都由Zookeeper來保存。
因此，Zookeeper在HBase系統中就是用於給運行在不同機器上的HBase程序提供協同服務的。
2.3、HBase
HBase模塊個人理解它就像是一個裝飾器。把原本HDFS(Hadoop distributed file system)的功能用“數據庫的語言”來復述一遍。它在集群中共有兩個進程：1. HMaster； 2. HRegionServer。整個架構圖中HBase部分這么繁雜，概括出來其實也就兩個東東而已。。。
2.3.1、HMaster
首先在這里先簡單了解一下“HBase集群”的概念。HBase集群中有若干台計算機，其中有一台是“主機（Master）”，其余的都是“從機（Slaver）”。一般在生產系統中，還會有一台“備用主機（backup master）”。
這個HMaster進程，就是運行在“主機”上的。准確的說，應該是HMaster在哪一台計算機上運行，哪一台計算機就是“主機”。
HMaster既然作為一個“上位者”，那它肯定是輕易不會去干活的，不然領導的尊嚴何在？類比一下企業當中的master，他們的日常工作就對外搞搞外交，對內簽簽名，再視察一下各部門的工作情況，還會根據企業現階段的發展狀況作一下資源調度等等。那我們的HBase當中也基本一樣，唯一的不同就是HMaster不用去外面搞外交，它只處理自己HBase系統內部的事務。
HMaster的作用主要有以下幾個：
1、分發Region
首先，Region是什么？在HBase中，如果一張表所包含的內容超過設定的上限，即一張表很大的話，會將這張表水平地分成兩半。比如，某張表共有1000行20列數據，HBase嫌這張表太大了，影響我檢索效率。將它分成兩部分，第一部分內容為第1 ~ 499行。第二部分內容為第500 ~ 1000行。那這切分出來的部分，就被稱為Region。在這里，就是有兩個Region。
其次，HBase系統會將這些Region盡量均衡地分發給這些“從機（Slaver）”。讓集群中每台從機都干同樣多同樣重的活。這可以說是HMaster的首要任務。
2、監控HRegionServer
* 負責HRegionServer的故障轉移
HRegionServer會定期地向HMaster發送心跳報告。當HMaster收不到HRegionServer的消息時，就認為該HRegionServer已經失去作用了。這個時候HMaster就得下達指令，將原本在HRegionServer上的數據遷移到其它正常工作的機器上去。到這里你肯定會有個疑問：根據前面講到的判斷HRegionServer故障的方式來看，這個時候HMaster已經不能夠和該HRegionServer通信了，那你是怎么下達指令，讓原本在這台HRegionServer上的數據進行遷移的呢？這個問題，這里暫且不講，我們只要知道，它能夠做到就是了。剛開始接觸，不要一下子灌輸太多概念，很容易亂的。HDFS的好處在這就體現出來了。
* 負責HRegionServer的負載均衡
當HBase系統中某台機器上的某個Region的大小超過上限時，它會被RegionServer切割成兩半，切割后多出來的一個Region又會由HMaster根據集群的情況來做負載均衡，其目的就是盡可能地讓每台從機干同樣多同樣重的活。這里還有一個：RegionServer中由“小合並”“大合並”生成的Region也會需要HMaster來做負載均衡。
那這里又有一個新的疑問：HMaster是如何得知HRegionServer是忙還是閑的呢？ HRegionServer會定期向HMaster發送一份自己的運行報告，類似於企業當中各部門領導定期向老板遞交工作報告一樣。然后HMaster就匯總這些運行報告並分析從而作出決策並最終下達指令。
3、管理元數據
在HBase中有一個由系統創建的表： hbase:meta 。這里我們姑且稱它為“元數據表”。那這個“元數據表”是干什么用的呢？
原來啊，在HBase中，所有的數據都是以“表”的形式來管理的。而當你的表增長到一定程度的時候，它會影響到你CRUD的效率。舉個粟子，假設你的某張表A里有1億條數據，現在你要查詢其中一條數據。又假設你又有一張表B里面有1000條數據，同樣你要查詢其中一條數據，你說A和B哪個檢索速度快？因此，當你的表增長到一定程度時，HMaster就會把這個表切割成幾塊，假設有一張表共有1000行，HMaster把它分割成兩塊T1和T2，T1的數據范圍從第0行到第499行。T2的數據范圍從第500行到第999行。不同的塊根據負載均衡存儲在不同的HRegionServer中。然后你要查詢某一條數據的話，就首先確定你這條數據是坐落在哪一個“塊”當中的，確定好后直接去這個“塊”當中查詢，這樣檢索速度就快很多了。那么，這些不同的“塊”被分別存儲到哪個HRegionServer中呢？這些不同的“塊”又是包含了哪些范圍的數據呢？這些信息就是記載在這個 hbase:meta 也就是“元數據”表中的了。一句大白話總結：元數據表是負責記載你想要查詢的數據是在哪台HRegionServer上保存着的信息的。
那話說回來，HMaster對於“元數據表”的管理方式，就是負責更新這個表中的數據內容的咯，換句話說就是如果HMaster掛掉了，那這個hbase:meta的數據就停止更新了。
2.3.2、HRegionServer
HRegionServer就復雜咯。。。
我們還是再來看看HRegionServer的架構圖吧。
圖4 HRegionServer架構圖
首先呢要明確一個概念：一個HRegionServer就代表着一台計算機。我們這里所講的一切都是基於這個大前提來講的。事實上確實也是，一台計算機上就運行一個HRegionServer進程，我不確定會不會有運行兩個HRegionServer進程的計算機，但是我覺得既然你要玩分布式，一台機器上跑兩個HRegionServer就沒有分布式的意義了。
接着我們來看一下HRegionServer中都有哪些東西。A picture is worth than a thousand words.
圖5 HRegionServer組成
下面來了解了解HRegionServer的各個組成部分的基本概念。。。
1、 HLog
首先，一個HRegionServer中就只有一個HLog。
HLog它是采用一種叫做預寫日志（write-ahead logging，簡稱WAL）的方式來記錄數據的日志文件。數據在這個日志文件里起到一個備份的作用，它是用來作容災的。HLog也是存儲在HDFS上的。
當Client想要寫數據到HBase數據庫中時，數據首先會寫到這個HLog中。當數據在HLog中成功保存以后就會告訴客戶端：我已經成功保存好你要我保存的數據了。隨后進行下一步的保存操作。需要注意的是，數據成功保存進HLog中以后，僅僅完成了HBase數據存儲的三分之一而已。但在這里，不講這么多。
2、HRegion
一個HRegionServer中有0 ~ n個HRegion。HRegion同HRegionServer一樣，在計算機中都只是一段程序而已。一個HRegion代表着一個從“表”中分割出來的“塊”，即HRegion代表着Region。很費解吧！HRegion是一段程序，Region是一小段邏輯表數據。每一個HRegion內部又維護着0 ~ n個Store，結合上圖5來看，這部分非常的繞。一個Store呢就代表着一個列族。什么是列族？在這里先簡單地把它理解成是“好幾個列的集合”。同時，每一個Store內部又維護着一個MemStore和0 ~ n個StoreFile。這個MemStore是一段內存空間。而這個StoreFile就是HFile，是最終存儲數據用的在HDFS之上的真實文件。就是說，假如你往HBase中保存了你心儀小姐姐的照片，那么這個照片最終會被存儲到某一個HFile文件中。
這里我們再來淡淡HRegionServer是如何存儲數據的。前面在HLog部分只講了HBase數據存儲的三分之一。HRegionServer在收到數據存儲的請求以后，首先會將這些要被存儲的數據寫到HLog中。當HLog中寫成功以后，再將這些數據寫到MemStore中。而MemStore由於是內存，你往內存中寫數據那速度就快了，在往內存中也寫成功以后呢，HRegionServer就要向Client返回一個“我已經把你要我保存的數據保存起來了”的信號了。但是實際上HRegionServer在“騙”你。這個時候你如果到HDFS的后台上去看，你根本找不到你要保存的那段數據的文件。換句話說，HBase之所以要管理起大數據來速度這么快，很大一部分功勞在於它是一個很“狡猾的騙子”。HRegionServer啊，只有在MemStore中存儲的數據達到一定的量以后，才會一次性的將這些數據輸出到HFile中。其實這種方式優點還是很明顯的，既以提升“Client的響應”速度，又能減少IO操作，在數據存儲中，減少IO就意味着延長存儲介質的壽命，存儲介質壽命延長了更意味着企業能降低運維成本。厲害了。。。
好了關於HBase的存儲流程，當然沒有這么簡單，但是在這里僅需要簡單地了解這些就夠了，慢慢來嘛，整個HBase系統可是比女人心還要復雜的，一下子讓你接受太多，恐怕你要受不住啊。。。
在知道了HRegionServer的組成以后，就可以了解了解HRegionServer的職責了。
1、托管數據
前面我們已經知道了HMaster它只負責作決策。實際的數據存儲的工作則全部交由HRegionServer來做。即HRegionServer就是用來存儲實際數據的。
2、維護HLog
負責更新或刪除HLog中的內容。HLog是直接按行存儲的，即只要你客戶端發送一次存儲請求過來，我都直接在HLog的末尾按一定格式添加進去，不給你分類。並且在這些數據內容被持久化到HDFS中以后，會刪除掉HLog中對應的信息。
3、大、小合並。
就是minor compaction與major compaction。簡言之，如果HBase系統中小文件太多了，將它合並成一個大一點的文件。
4、監控Region
HRegionServer監控Region的什么東西呢？ 當然是監控它的尺寸了。你想想嘛，HBase就是號稱針對大數據高速檢索的數據庫，你一個Region要是過於龐大那就是一個文件過於龐大，那它還怎么來保證大數據的高速檢索。HRegionServer會定期將自己管轄的Region的尺寸數據生成一個報告發給HMaster。如果HMaster發現某個Region過大了，就要下達指令，讓HRegionServer將這個Region分割成2塊。下達分割指令的是HMaster，指令的執行者是RegionServer。
2.4、Hadoop
Hadoop也是Apache軟件基金會的頂級項目。它是一個分布式系統架構。
它在HBase系統中就負責幫RegionServer以分布式的方式管理各個HFile文件。
再說的通俗一點吧。把整個HBase系統比喻成一家企業。Master是這家企業的老板，Slaver可以比喻成是公司財務。數據比喻成是資金。由老板下達決策，將所有資金划撥到不同用途。財務負責幫老板管錢。那這么多的錢，財務精力有限能力有限，不可能自己管的過來啊。那怎么辦？只能交給銀行來管了。Hadoop，也就是HDFS就起到類似於銀行的角色。
這篇文章已經夠長了，就只聊這么多了。個人認為，如果你是一個初學者的話，就不要一下子灌輸太多的概念，一來很難消化的了這么多內容，二來容易打擊自己的積極性。只了解一個基本的概念，詳細的知識可以在后面的使用過程中慢慢學習。這里尤其千萬要告誡你們的一點就是：初學者不要接觸HBase源代碼。不解釋，信我，沒錯的。
- The end -