文章目錄
HBase物理架構：
HMaster：
HMaster的主要作用：–負責table和region管理工作
-
分發Region–區每一個Region會有設定大小，當超過設定的上限，我們需要多個Region,
其次，HBase系統會將這些Region儘量均衡地分發給這些“從機（Slaver）”，讓集羣中每臺從機都幹同樣多同樣重的活。這可以說是HMaster的首要任務。
-
監控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就彙總這些運行報告並分析從而作出決策並最終下達指令。
-
管理元數據在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的數據就停止更新了。
HRegionServer：
1.HLog ----簡直和NN的editlog還有mysql的log文件一毛一樣
一個HRegionServer中就只有一個HLog
HLog它是採用一種叫做預寫日誌（write-ahead logging，簡稱WAL）的方式來記錄數據的日誌文件。數據在這個日誌文件裏起到一個備份的作用，它是用來作容災的。HLog也是存儲在HDFS上的。
當Client想要寫數據到HBase數據庫中時，數據首先會寫到這個HLog中。當數據在HLog中成功保存以後就會告訴客戶端：我已經成功保存好你要我保存的數據了。隨後進行下一步的保存操作。需要注意的是，數據成功保存進HLog中以後，僅僅完成了HBase數據存儲的三分之一而已。但在這裏，不講這麼多。
2.HRegion
一個HRegionServer中有0 ~ n個HRegion。
Region概念：
- Region是HBase數據存儲和管理的基本單位。
- 一個表中可以包含一個或多個Region。
- 每個Region只能被一個RS（RegionServer）提供服務，RS可以同時服務多個Region，來自不同RS上的Region組合成表格的整體邏輯視圖。
Region組成：
- HRegion： 一個Region可以包含多個
Store； - Store： 每個Store包含一個
Memstore和若干個StoreFile； - StoreFile： 表數據真實存儲的地方，
HFile是表數據在HDFS上的文件格式。
如何找到Region定位流程：
B+樹定位，通過ZooKeeper 來查找 -ROOT-，然後是.META.，然後找到Table裏的Region
。HRegionServer在收到數據存儲的請求以後，首先會將這些要被存儲的數據寫到HLog中。當HLog中寫成功以後，。其實這種方式優點還是很明顯的，既以提升“Client的響應”速度，又能減少IO操作，在數據存儲中，減少IO就意味着延長存儲介質的壽命，存儲介質壽命延長了更意味着企業能降低運維成本。厲害了。。。
3.Store–一個Store代表一個列簇
每一個HRegion內部又維護着0 ~ n個Store
4.StoreFile
Store內部又維護着一個MemStore和0 ~ n個HFile，最終存儲數據用的在HDFS之上的真實文件
這個MemStore是一段內存空間。而這個StoreFile就是HFile，再將這些數據寫到MemStore中。而MemStore由於是內存，你往內存中寫數據那速度就快了，在往內存中也寫成功以後呢，HRegionServer就要向Client返回一個“我已經把你要我保存的數據保存起來了”的信號了。但是實際上HRegionServer在“騙”你。這個時候你如果到HDFS的後臺上去看，你根本找不到你要保存的那段數據的文件。換句話說，HBase之所以要管理起大數據來速度這麼快，很大一部分功勞在於它是一個很“狡猾的騙子”。HRegionServer啊，只有在MemStore中存儲的數據達到一定的量以後，纔會一次性的將這些數據輸出到HFile中。
5.blockcache
- 讀緩存，數據被讀取之後仍然緩存在內存中
- 有LruBlockCache（效率較高，GC壓力大）和BucketCache（效率較低，沒有GC壓力）兩種BlockCache，默認爲LruBlockCache
- 每個RegionServer中只有一個BlockCache實例
HBase物理架構工作流程：
一：讀操作：
第一步： client通過zookeeper的調度，通過讀取zk的-root表，確定meta表的region位置，再通過讀取meta表，讀取用戶表的region位置信息。
第二步： 根據namespace、表名和rowkey在meta表中找到對應的region信息後，通過region位置信息找到相應的RegionServer，通過RegionServer找到相應的數據存放的Region，並讀取數據。
第三步： Regionserver的內存分爲MemStore和BlockCache兩部分，MemStore主要用於寫數據，BlockCache主要用於讀數據。讀請求先到MemStore中查數據，查不到就到BlockCache中查，再查不到就會到StoreFile上讀，並把讀的結果放入BlockCache。
二：寫操作
第一步： client通過zookeeper的調度，通過讀取zk的-root表，確定meta表的region位置，再通過讀取meta表，讀取用戶表的region位置信息。
第二步： 根據namespace、表名和rowkey在meta表中找到對應的region信息後，通過region位置信息找到相應的RegionServer，並將對應的數據發送到該Regionserver檢查操作，看Region是不是隻讀狀態，BlockMemorySize大小限制等。
第三步： 數據先寫入hlog，然後寫入memstore，知道memstore 到達一定的閾值，memstore到達閾值後，會創建一個新的memstore，並將老的添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個storeFile。
PS:當得到了需要訪問的Regionserver之後，Client，會向對應的Regionserver發起寫請求，
數據寫入流程，依次將數據寫入MemoryStore 和HLog，在寫入MemoryStore 和HLog的過程時，需要獲取相關的鎖，而且寫入MemoryStore 和HLog是原子性的，要麼都成功，要麼都失敗。
與此同時，zookeeper會記錄一個checkpoint點，表示這個時間之前的數據已經持久化了，到系統故障導致memstore丟失的時候，可以通過hlog進行數據的恢復。
第四步： 隨着storeFile的不斷增多，當其數量達到一定的閾值之後，會觸發Compact操作，將多個StoreFile合併成一個，對同一個key的修改合併到一起，同時對版本進行合併刪除。
通過不斷合併，當StoreFile到達一定大小的時候，會觸發Split操作，把當前Region的文件，分成兩個文件，放到相應的Region，此時父Region會下線。這樣使得原先1個Region的壓力得以分流到2個Region上。
細節擴展：
一：爲什麼Client只需要知道Zookeeper地址就可以了呢？
HMaster啓動的時候，會把Meta信息表加載到zookeeper。
Meta信息表存儲了HBase所有的表，所有的Region的詳細的信息，比如Region開始的key，結束的key，所在Regionserver的地址。Meta信息表就相當於一個目錄，通過它，可以快速定位到數據的實際位置，所以讀寫數據，只需要跟Zookeeper對應的Regionserver進行交互就可以了。HMaster只需要存儲Region和表的元數據信息，協調各個Regionserver，所以他的負載就小了很多。
二：HBase三大模塊如何一起協作的。(HMaster,RegionServer,Zookeeper)
通過三個問題解釋
1.當HBase啓動的時候發生了什麼？
HMaster啓動的時候會連接zookeeper，將自己註冊到Zookeeper，首先將自己註冊到Backup Master上，因爲可能會有很多的節點搶佔Master，最終的Active Master要看他們搶佔鎖的速度。
將會把自己從Backup Master刪除，成爲Active Master之後，纔會去實例化一些類，比如Master Filesytem，table state manager。
當一個節點成爲Active Master之後，他就會等待Regionserver彙報。
首先Regionserver註冊Zookeeper，之後向HMaster彙報。HMaster現在手裏就有一份關於Regionserver狀態的清單，對各個Regionserver（包括失效的）的數據進行整理，
最後HMaster整理出了一張Meta表，這張表中記錄了，所有表相關的Region，還有各個Regionserver到底負責哪些數據等等。然後將這張表，交給Zookeeper。
之後的讀寫請求，都只需要經過Zookeeper就行了。
Backup Master 會定期同步 Active Master信息，保證信息是最新的。
2.如果Regionserver失效了，會發生什麼？
如果某一個Regionserver掛了，HMaster會把該Regionserver刪除，之後將Regionserver存儲的數據，分配給其他的Regionserver，將更新之後meta表，交給Zookeeper。
所以當某一個Regionserver失效了，並不會對系統穩定性產生任何影響。
3.當HMaster失效後會發生什麼？
如果Active 的HMaster出現故障,處於Backup狀態的其他HMaster節點會推選出一個轉爲Active狀態。當之前出現故障的HMaster從故障中恢復，他也只能成爲Backup HMaster，等待當前Active HMaster失效了，他纔有機會重新成爲Active HMaster。
對於HA高可用集羣，當Active狀態的HMaster失效，會有處於Backup 的HMaster可以頂上去，集羣可以繼續正常運行。
如果沒有配置HA，那麼對於客戶端的新建表，修改表結構等需求，因爲新建表，修改表結構，需要HMaster來執行，會涉及meta表更新。那麼 會拋出一個HMaster 不可用的異常，但是不會影響客戶端正常的讀寫數據請求。
三：爲什麼需要合併Region?
那爲什麼需要合併Region呢？這個需要從Region的Split來說。當一個Region被不斷的寫數據，達到Region的Split的閥值時（由屬性hbase.hregion.max.filesize來決定，默認是10GB），該Region就會被Split成2個新的Region。隨着業務數據量的不斷增加，Region不斷的執行Split，那麼Region的個數也會越來越多。
一個業務表的Region越多，在進行讀寫操作時，或是對該表執行Compaction操作時，此時集羣的壓力是很大的。這裏筆者做過一個線上統計，在一個業務表的Region個數達到9000+時，每次對該表進行Compaction操作時，集羣的負載便會加重。而間接的也會影響應用程序的讀寫，一個表的Region過大，勢必整個集羣的Region個數也會增加，負載均衡後，每個RegionServer承擔的Region個數也會增加。
因此，這種情況是很有必要的進行Region合併的。比如，當前Region進行Split的閥值設置爲30GB，那麼我們可以對小於等於10GB的Region進行一次合併，減少每個業務表的Region，從而降低整個集羣的Region，減緩每個RegionServer上的Region壓力。