《分布式數據庫HBase的架構設計詳解》要點：
本文介紹了分布式數據庫HBase的架構設計詳解，希望對您有用。如果有疑問，可以聯系我們。

講師介紹：陳鴻威

云財經大數據CTO

• 曾任百度高級工程師,現主持設計開發云財經股市情報和大數據中心；
• 擁有豐富的在線電商、證券實時系統、金融海量數據在線計算的實戰經驗；致力于各類分布式和大數據開源項目研究.

主題簡介：

1、傳統數據庫回顧

2、分布式基礎理論

3、HBase特征

4、HBase底層架構

5、HBase設計要點

傳統數據庫回顧

近些年來,各種互聯網+的公司如雨后春筍般出現,做一個在線平臺或者做一個APP基本成為這些公司的標配.Web系統的流行,數據收集越來越容易,促使各類數據庫系統應用得越來越廣泛.

我們在平時的技術討論或者實際應用中經常會提到傳統數據庫.提到傳統數據庫,很多人會很容易聯想到Oracle、MySQL、SQL Server等帶有很明顯關系型數據庫特征的數據庫系統.在我看來,傳統數據庫并不等于這些數據庫,而是看你怎么用的.一般來說,傳統數據庫包括以下三個鮮明的特點：

1、事務的保障：ACID

ACID一言以蔽之就是原子性、一致性、隔離性、持久化事務,它是四個單詞的縮寫：

• Atomicity 原子性 事務中所有操作要么全部完成,要么全失敗.
• Consistency 一致性 在事務開始時或者結束時,數據庫應該處于同一狀態.
• Isolation 隔離性 事務將假定只有它自己在操作數據庫,彼此不知曉.
• Durablity 一旦事務完成,就不能返回.

要做到ACID,從編程的角度來說,數據庫系統一定會用到鎖.

一般對事務要求比較高的主要是交易場景,銀行系統、大型在線電商交易系統用得比較多.對于絕大多數創業公司而言,事務是一個偏理論的概念.實際上在,在線系統中,事務是一個很有用的東西,我們舉個栗子：

用戶A在平臺購買增值服務的場景,會有很多種處理方式.

一般的程序員會如下處理：

1. 在財務表中增加一條用戶A的扣費記錄.(扣費)
2. 在用戶增值服務表中增加一條用戶A的增值服務記錄.(開通服務)

用戶至上的程序員會如下處理：

1. 在用戶增值服務表中增加一條用戶A的增值服務記錄.(開通服務)
2. 在財務表中增加一條用戶A的扣費記錄.(扣費)

三年以上工作經驗的程序員會如下處理：

1. 在財務表中增加一條用戶A的扣費記錄.(扣費)
2. 判斷財務表中是否扣費成功,不成功通知系統交易失敗.
3. 在用戶增值服務表中增加一條用戶A的增值服務記錄.(開通服務)
4. 判斷用戶增值服務表中是否增加成功,不成功刪除財務表中的扣費并且通知系統交易失敗.

那么用上事務之后,你只要提交給數據庫一般程序員操作,數據庫就會給你三年以上工作經驗的程序員的操作結果,在主從架構讀寫分離的數據庫結構中效果還會更好.

2、豐富的數據類型和SQL的操作方式

傳統的數據庫系統可以存很多種類型的數據,主要包括：

1. 數字家族、整數和小數.整數又可以分為32位的,64位的…
2. 字符串類型.字符串又分為固定長度的和可變長度的…
3. 時間家族.日期、時間…
4. 二進制流…

這么多類型,確實很豐富.我們所看到的,都可以是字符,就算二進制流,也可以通過Base64轉碼用字符串表示.當然,在講字符串的時候,我們是把編程語言進化到了一個很高級的程度,開發的友好性大于存儲成本.

對于傳統數據庫系統的常用操作,我們一般會說CURD.即對表的增刪改查,基本都用SQL語句來實現.SQL語句的結構主要分為以下幾大部分：

1. 操作,select、insert、update、delete.
2. 表對象.
3. 字段范圍(*/f1/f2…).
4. Where條件.
5. Order排序(desc/asc).
6. 查詢范圍限制(top/limit).

……

SQL語句是為使用者友好而設計的,無論何種數據庫引擎,SQL最后都被映射成為IO和內存操作.

3、嚴格的數據模型：行式存儲

在傳統數據庫系統中,一般來說在第一次寫入數據之前,都需要創建庫和創建表,而每一個表都有確定的表頭,確定列數,每一列的名字以及確定的數據類型.在新數據的寫入或者數據的修改的時候,數據庫系統會根據創建好的表結構嚴格校驗數據的合法性,對表結構的調整一般都需要很大的修改代價.

在存儲單元里,同一行的數據會分布在相鄰的存儲單元里.

列式存儲相對于行式存儲而言,其同一列的數據會分布在相鄰的存儲單元里.

題外話：除了行存儲和列存儲,常見還有文檔模型,典型的代表就是MongoDB.如果用傳統的行的角度來看,不同的行列數可以不一樣,列的名字和數據類型也可以不一樣,列里面可以是另一個嵌套的行.

互聯網的需求

在互聯網化的大環境下,很多系統都很容易在短時間內系統收集上億的數據,并且這些數據經過加工,還要為幾十萬、幾百萬甚至更多用戶提供訪問.從平臺角度來說,一般就是從小到大,從簡單到復雜的過程.主要來說,具有一下三方面特點：

• 對數據高并發讀寫的要求

數據庫讀寫壓力巨大,硬盤IO無法承受.一般處理方法是主從架構,讀寫分離,分庫、分表,緩解寫壓力,增強讀庫的可擴展性.

• 對海量數據的存儲和訪問

存儲記錄數量有限,SQL查詢效率極低的情況下.通過分庫、分表,緩解數據增長壓力.

• 伸縮性,可用性,可靠性方面的需求

橫向擴展艱難,無法通過快速增加服務器節點實現,系統升級和維護造成服務不可用.通過主從架構,增強讀庫的擴展性,利用MMM架構處理寫的瓶頸.

 

傳統數據庫的瓶頸

分庫分表缺點：

1. 受業務規則影響,需求變動導致分庫分表的維護復雜.
2. 系統數據訪問層代碼需要修改.

主從架構缺點：

1. Slave實時性的保障,對于實時性很高的場合可能需要做一些處理(在第一個購買增值服務的例子中,添加扣費記錄之后,在讀寫分離的場景下,立馬去從庫查詢扣費記錄不一定能查到).
2. 高可用性問題,Master就是那個致命點,容易產生單點故障.

MMM缺點：

本身擴展性差,一次只能一個Master可以寫入,只能解決有限數據量下的可用性.

分布式基礎理論

1、CAP

分布式領域CAP理論

• Consistency 一致性：數據一致更新,所有數據變動都是同步的.
• Availability(可用性)：好的響應性能.
• Partition tolerance：分區容忍性.

2、Base

• Basically Available：基本可用 支持分區失敗.
• Soft state 軟狀態：狀態可以有一段時間不同步,異步.
• Eventually consistent：最終一致性 ,最終數據是一致的就可以了,而不是時時一致.

3、NoSQL運動兩個核心理論

• Google的BigTable

BigTable提出了一種很有趣的數據模型,它將各列數據進行排序存儲.數據值按范圍分布在多臺機器,數據更新操作有嚴格的一致性保證.

• Amazon的Dynamo

Dynamo使用的是另外一種分布式模型.Dynamo的模型更簡單,它將數據按key進行hash存儲.其數據分片模型有比較強的容災性,因此它實現的是相對松散的弱一致性：最終一致性.

HBase特征

HBase是Google Bigtable的開源實現,類似Google Bigtable利用GFS作為其文件存儲系統,HBase利用Hadoop HDFS作為其文件存儲系統；Google運行MapReduce來處理Bigtable中的海量數據,HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable利用 Chubby作為協同服務,HBase利用ZooKeeper作為對應.

主要特點

1. 列的可以動態增加,并且列為空就不存儲數據,節省存儲空間.
2. HBase自動切分數據,使得數據存儲自動具有水平scalability.
3. HBase可以提供高并發讀寫操作的支持,分布式架構,讀寫鎖等待的概率大大降低.
4. 不能支持條件查詢,只支持按照Rowkey來查詢.
5. 暫時不能支持Master server的故障切換,當Master宕機后,整個存儲系統就會掛掉.

HBase底層架構

HBase是一個列式存儲的數據庫系統,跟所有的數據庫系統一樣,數據庫是依賴文件系統的,在傳統數據庫里面我們經常提到存儲引擎,例如MySQL有MyISAM/InnoDB,Oracle/SqlServer不開源,沒有那么多選擇,但都會有自己的存儲引擎,說得通俗一點就是虛擬文件系統,HBase的文件系統是HDFS,一種分布式文件系統,所以HBase天然具備分布式的特性.同時Hadoop MapReduce為HBase提供了高性能的計算能力,Zookeeper為HBase提供了穩定服務和failover機制.

HBase設計要點

1、邏輯數據模型

• Table
• Region
• ColumnFamily
• Row
• Column
• Value
• TimeStamp

你也可以把HBase看成一個多維度的Map模型去理解它的數據模型.正如下圖.

2、HBase的體系組成

NameNode存儲DataNode信息,ZooKeeper負責調度.

一個Region只會存在一臺RegionServer上,一臺RegionServer上可以包含多個Region.

一個邏輯的表包含多個Region,分布在各個RegionServer上,對應用程序來說只有一個大表不用管分表分庫.

• Region的定位

-ROOT-

.META

• 存儲分布

每一行包含N個列,以列的形式分布在不同Region里面.

3、HBase各對象職責

• Client

HBase的訪問接口,維護cache加快HBase的訪問.

• Zookeeper

監控Master,保證只有一個Master；

存儲Region的入口地址；

監控RegionServer上下線,并告知Master；

存儲Hbase shcema和Table的元數據.

• Master

分配Region到RegionServer；

RegionSever的負載均衡；

發現失效的RegionServer并重新分配其上的Region

管理用戶對Table的增刪改查操作.

• RegionServer

維護Region,處理對這些Region的IO；

Split&Compact.

4、應用方式

HBase是三維有序存儲的,通過RowKey(行鍵),column key(column family和qualifier)和TimeStamp(時間戳)這個三個維度可以對HBase中的數據進行快速定位.

RowKey是HBase表結構設計中很重要的一環 ,HBase中RowKey可以唯一標識一行記錄,在HBase查詢的時候,有以下2種方式：

1. 按指定RowKey獲取唯一一條記錄,get方法(org.apache.hadoop.hbase.client.Get)
2. 按指定的條件獲取一批記錄,scan方法(org.apache.hadoop.hbase.client.Scan)

第一種類似key-value查找,第二種可以實現簡單的條件查詢功能.

Q&A

Q1：HBase是不是沒有傳統表的概念了.感覺都像是鍵值存儲.

A1：如果存儲角度看是涵蓋了的,但是去掉了關系.

Q2：HBase 與MongoDB的使用場景的區別老師能否簡單介紹一下?

A2：HBase適合做數據分析,MongoDB在線服務性能很好,尤其是讀,HBase要結合MapReduce,還有就是MongoDB適合Web服務,例如PHP.

 

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4127.html