1. 程式人生 > >分散式資料庫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儲存。其資料分片模型有比較強的容災性,因此它實現的是相對鬆散的弱一致性:最終一致性。

Dynamo

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

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模型去理解它的資料模型。正如下圖。

Map模型

2、HBase的體系組成

HBase體系組成

NameNode儲存DataNode資訊,ZooKeeper負責排程。

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社群