hbase數據原理及基本架構

第一：hbase介紹

hbase是一個構建在hdfs上的分佈式列存儲系統；

hbase是apache hadoop生態系統中的重要一員，主要用於海量結構化數據存儲

從邏輯上講，hbase將數據按照表、行和列進行存儲

hbase表特色：

　　1.大：一個表能夠有數十億行，上百萬列；

　　2.無模式：每行都有一個可排序的主鍵和任意多的列，列能夠根據須要動態的增長，同一張表中不一樣的行能夠有大相徑庭的列；

　　3.面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；

　　4.稀疏：對於空（null）的列，並不佔用存儲空間，表能夠設計的很是稀疏；

　　5.數據多版本：每一個單元中的數據能夠有多個版本，默認狀況下版本號自動分配，是單元格插入時的時間戳；

　　6.數據類型單一：hbase中的數據都是字符串，沒有類型

hbase與hdfs的對比：

　　1.二者都具備良好的容錯性和擴展性，均可以擴展到成百上千個節點。

　　2.hdfs適合批處理場景,不支持數據隨機查找，不適合增量數據處理，不支持數據更新。

行存儲與列存儲：

　　傳統行式數據庫：

　　　　1.數據是按行存儲的

　　　　2.沒有索引的查詢使用大量I/O

　　　　3.創建索引和物化視圖須要花費大量時間和資源

　　　　4.面向查詢的需求，數據庫必須被大量膨脹才能知足性能要求

　　列式數據庫:

　　　　1.數據是按列存儲-每一列單獨存放

　　　　2.數據便是索引

　　　　3.指訪問查詢涉及的列-大量下降系統I/O

　　　　4.每一列由一個線索來處理-查詢的併發處理

　　　　5.數據類型一致，數據特徵類似-高效壓縮

第二：hbase數據模型

hbase是基於Google BigTable模型開發的，典型的key/value系統

 

hbase數據模型術語：

Table（表）

一個hbase包含多個行，是在schema聲明的時候定義的

Row（行）

行鍵是不可分割的字節數組。行是按字典排序由低到高存儲在表中的。一個空的數組是用來標識表空間的起始或者結尾。

Row Key 

　　1）Byte array

　　2）表中每條記錄的「主鍵」

　　3）方便快速查找  

Column Family

　　1）擁有一個名稱（string）

　　2）包含一個或者多個相關的列，是一些列的集合

　　3）一個列簇全部列成員具備相同的前綴

Column 

　　1）屬於某一個column family

　　2）包含在某一列中

Cell（value）

　　1）A {row, column, version} 元組就是一個HBase中的一個 cell。

　　2）Cell的內容是不可分割的字節數組。

　　3）能夠爲空

Timestamp（時間戳）

 version number（版本號）

　　1）每一個rowkey惟一

　　2）默認值-----》 系統時間戳

　　3）類型爲Long 

　　4）無需遞增插入

 數據模型操做

1. 全部操做均是基於rowkey的；

2. 支持CRUD（Create、Read、Update和Delete）和 Scan；

3. 單行操做 Put Get Scan

　多行操做 Scan MultiPut

4. 沒有內置join操做，可以使用MapReduce解決

第三：hbase物理模型

每一個column family存儲在HDFS上的一個單獨文件中；

Key和Version number在每一個column family中均有一份

空值不被保存

eg:

 info Column Family:

 

roles Column Family

數據物理存儲：

1.Table中全部的行都按照row key的字典序列排列；

2.Table在行的方向上被分割爲多個Region；

 

3.Region按照大小分割的，每一個表開始只有一個region，隨着數據的增多，region不斷的增大，當增大到一個閥值的時候，region就會等分紅兩個新的region，以後會有愈來愈多的region；

4.Region是Hbase中分佈式存儲和負載均衡的最小單元，不一樣的region分佈在不一樣RegionServer上；

5.Region雖然是分佈式存儲的最小單元，但並非存儲的最小單元。

　　1）Region是由一個或者多個Store組成，每一個store保存一個columns family；

　　2）每一個Store又由一個memStore和0或多個StoreFile組成

　　3）memStore存儲在內存中，StoreFile存儲在HDFS上。

第四：hbase基礎架構

Hbase架構：

在分佈式的生產環境中，HBase 須要運行在 HDFS 之上，以 HDFS 做爲其基礎的存儲設施。在 HBase 的集羣中主要由 Master 和 Region Server 組成，以及 Zookeeper

Hbase相關的組件：

Clinet：

　　包含訪問Hbase的接口，並維護cache來加快對Hbase的訪問。

zookeeper:

　　保證任什麼時候候，集羣中只有一個master

　　存儲全部Region的尋址入口

　　實時監控Region Server的上線或者下線信息，並實時通知給Master

　　存儲HBase的schema和table元數據

　　zookeeper做用：

　　　　HBase依賴zk；

　　　　默認狀況下Hbase管理zk實例，eg：啓動或者中止zk

　　　　Master與RegionServers啓動時會向zk註冊

　　　　Zookeeper的引入使得Master不在是單點故障

Master:

　　爲Region Server分配region

　　負責Region Server的負載均衡

　　發現失效的Region Server並從新分配他上面的region

　　管理用戶對table的增刪改查操做

Region Server:

　　維護region，處理對這些region的IO請求

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

 -ROOT-表與-META-表：

-ROOT-表：

　　包含-META-表所在的region列表，該表只會有一個Region；

　　zookeeper中記錄了-ROOT-表的位置

-META-表：

　　包含全部的用戶空間region列表，以及RegionServer的服務器地址

詳解：

1.HBase的全部Region元數據被存儲在.META.表中，隨着Region的增多，.META.表中的數據也會增大，並分裂成多個新的Region。爲了定位.META.表中各個Region的位置，把.META.表中全部Region的元數據保存在-ROOT-表中，最後由Zookeeper記錄-ROOT-表的位置信息。全部客戶端訪問用戶數據前，須要首先訪問Zookeeper得到-ROOT-的位置，而後訪問-ROOT-表得到.META.表的位置，最後根據.META.表中的信息肯定用戶數據存放的位置，如上圖所示。

2.-ROOT-表永遠不會被分割，它只有一個Region，這樣能夠保證最多隻須要三次跳轉就能夠定位任意一個Region。爲了加快訪問速度，.META.表的全部Region所有保存在內存中。客戶端會將查詢過的位置信息緩存起來，且緩存不會主動失效。若是客戶端根據緩存信息還訪問不到數據，則詢問相關.META.表的Region服務器，試圖獲取數據的位置，若是仍是失敗，則詢問-ROOT-表相關的.META.表在哪裏。最後，若是前面的信息所有失效，則經過ZooKeeper從新定位Region的信息。因此若是客戶端上的緩存所有是失效，則須要進行6次網絡來回，才能定位到正確的Region。

高可用

Write-Ahead-Log（WAL）保障數據高可用

理解高可用首先：必須理解下HLog的做用，HBase中的Hlog機制是WAL的一種實現，而WAL是事務機制中常見的一致性的實現方式。每一個RegionServer中都會有一個HLog的實例，RegionServer會將更新操做（put，delete等），先記錄到WAL（也就是HLog中），而後再將其寫入到Store的MemStore，最終Memstore達到必定的閥值後，在寫入到HFile中，這樣就保證了HBase的寫的可靠性，若沒有WAL，當RegionServer掛掉的時候，MemStore尚未寫到HFile的數據，或者說StoreFile沒有保存的時候，數據會丟失。（說到這裏或許有人會問，假如HFile自己丟失了怎麼辦，這是由HDFS來保證的。在HDFS中的數據默認會有3份）

HFile是由不少個數據塊（Block）組成，而且有一個固定的結尾塊，其中的數據塊是由一個Header和多個Key-Value的鍵值對組成，在結尾的數據塊中包含了數據相關的索引信息，系統也是經過結尾的索引信息找到HFile中的數據。

上圖是RegionServer數據存儲關係圖。上文提到，HBase使用MemStore和StoreFile存儲對錶的更新。數據在更新時首先寫入HLog和MemStore。MemStore中的數據是排序的，當MemStore累計到必定閾值時，就會建立一個新的MemStore，而且將老的MemStore添加到Flush隊列，由單獨的線程Flush到磁盤上，成爲一個StoreFile。與此同時，系統會在Zookeeper中記錄一個CheckPoint，表示這個時刻以前的數據變動已經持久化了。當系統出現意外時，可能致使MemStore中的數據丟失，此時使用HLog來恢復CheckPoint以後的數據。
StoreFile是隻讀的，一旦建立後就不能夠再修改。所以Hbase的更新實際上是不斷追加的操做。當一個Store中的StoreFile達到必定閾值後，就會進行一次合併操做,將對同一個key的修改合併到一塊兒，造成一個大的StoreFile。當StoreFile的大小達到必定閾值後，又會對 StoreFile進行切分操做，等分爲兩個StoreFile。

詳解

組件的高可用

Master容錯：Zookeeper從新選擇一個新的Master

　　無Master過程當中，數據讀取任然照常進行

　　無Master過程當中，region切分、負載均衡等沒法進行

RegionServer容錯：

　　定時向Zookeeper彙報心跳，若是一旦一段時間內未出現心跳，Master將該RegionServer上的Region從新分配到其餘的RegionServer上；

　　失效的服務器上「預寫」日誌由主服務器進行分割並派送給新的RegionServer上

zookeeper容錯：zookeeper是一個可靠的服務

　　通常是3到5個zookeeper實例

讀寫流程

　　寫操做：

　　　　1）client經過zookeeper的調度，向regionserver發出寫數據的請求，在Region中寫數據

　　　　2）數據首先記錄在HLog中，而後再將其寫入到Store的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/0的高性能。

　　讀操做：

　　　　1）client訪問zk，查找-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