分散式資料庫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在平臺購買增值服務的場景，會有很多種處理方式。
一般的程式設計師會如下處理：
- 在財務表中增加一條使用者A的扣費記錄。（扣費）
- 在使用者增值服務表中增加一條使用者A的增值服務記錄。（開通服務）
使用者至上的程式設計師會如下處理：
- 在使用者增值服務表中增加一條使用者A的增值服務記錄。（開通服務）
- 在財務表中增加一條使用者A的扣費記錄。（扣費）
三年以上工作經驗的程式設計師會如下處理：
- 在財務表中增加一條使用者A的扣費記錄。（扣費）
- 判斷財務表中是否扣費成功，不成功通知系統交易失敗。
- 在使用者增值服務表中增加一條使用者A的增值服務記錄。（開通服務）
- 判斷使用者增值服務表中是否增加成功，不成功刪除財務表中的扣費並且通知系統交易失敗。
那麼用上事務之後，你只要提交給資料庫一般程式設計師操作，資料庫就會給你三年以上工作經驗的程式設計師的操作結果，在主從架構讀寫分離的資料庫結構中效果還會更好。
2、豐富的資料型別和SQL的操作方式
傳統的資料庫系統可以存很多種型別的資料，主要包括：
- 數字家族、整數和小數。整數又可以分為32位的，64位的…
- 字串型別。字串又分為固定長度的和可變長度的…
- 時間家族。日期、時間…
- 二進位制流…
這麼多型別，確實很豐富。我們所看到的，都可以是字元，就算二進位制流，也可以通過Base64轉碼用字串表示。當然，在講字串的時候，我們是把程式語言進化到了一個很高階的程度，開發的友好性大於儲存成本。
對於傳統資料庫系統的常用操作，我們一般會說CURD。即對錶的增刪改查，基本都用SQL語句來實現。SQL語句的結構主要分為以下幾大部分：
- 操作，select、insert、update、delete。
- 表物件。
- 欄位範圍(*/f1/f2…)。
- Where條件。
- Order排序(desc/asc)。
- 查詢範圍限制（top/limit）。
……
SQL語句是為使用者友好而設計的，無論何種資料庫引擎，SQL最後都被對映成為IO和記憶體操作。
3、嚴格的資料模型：行式儲存
在傳統資料庫系統中，一般來說在第一次寫入資料之前，都需要建立庫和建立表，而每一個表都有確定的表頭，確定列數，每一列的名字以及確定的資料型別。在新資料的寫入或者資料的修改的時候，資料庫系統會根據建立好的表結構嚴格校驗資料的合法性，對錶結構的調整一般都需要很大的修改代價。
在儲存單元裡，同一行的資料會分佈在相鄰的儲存單元裡。
列式儲存相對於行式儲存而言，其同一列的資料會分佈在相鄰的儲存單元裡。
題外話：除了行儲存和列儲存，常見還有文件模型，典型的代表就是MongoDB。如果用傳統的行的角度來看，不同的行列數可以不一樣，列的名字和資料型別也可以不一樣，列裡面可以是另一個巢狀的行。
網際網路的需求
在網際網路化的大環境下，很多系統都很容易在短時間內系統收集上億的資料，並且這些資料經過加工，還要為幾十萬、幾百萬甚至更多使用者提供訪問。從平臺角度來說，一般就是從小到大，從簡單到複雜的過程。主要來說，具有一下三方面特點：
- 對資料高併發讀寫的要求
資料庫讀寫壓力巨大，硬碟IO無法承受。一般處理方法是主從架構，讀寫分離，分庫、分表，緩解寫壓力，增強讀庫的可擴充套件性。
- 對海量資料的儲存和訪問
儲存記錄數量有限，SQL查詢效率極低的情況下。通過分庫、分表，緩解資料增長壓力。
- 伸縮性，可用性，可靠性方面的需求
橫向擴充套件艱難，無法通過快速增加伺服器節點實現，系統升級和維護造成服務不可用。通過主從架構，增強讀庫的擴充套件性，利用MMM架構處理寫的瓶頸。
傳統資料庫的瓶頸
分庫分表缺點：
- 受業務規則影響，需求變動導致分庫分表的維護複雜。
- 系統資料訪問層程式碼需要修改。
主從架構缺點：
- Slave實時性的保障，對於實時性很高的場合可能需要做一些處理（在第一個購買增值服務的例子中，新增扣費記錄之後，在讀寫分離的場景下，立馬去從庫查詢扣費記錄不一定能查到）。
- 高可用性問題，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作為對應。
主要特點
- 列的可以動態增加，並且列為空就不儲存資料，節省儲存空間。
- HBase自動切分資料，使得資料儲存自動具有水平scalability。
- HBase可以提供高併發讀寫操作的支援，分散式架構，讀寫鎖等待的概率大大降低。
- 不能支援條件查詢，只支援按照Rowkey來查詢。
- 暫時不能支援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種方式：
- 按指定RowKey獲取唯一一條記錄，get方法（org.apache.hadoop.hbase.client.Get）
- 按指定的條件獲取一批記錄，scan方法（org.apache.hadoop.hbase.client.Scan）
第一種類似key-value查詢，第二種可以實現簡單的條件查詢功能。
Q1：HBase是不是沒有傳統表的概念了。感覺都像是鍵值儲存。
A1：如果儲存角度看是涵蓋了的，但是去掉了關係。
Q2：HBase 與MongoDB的使用場景的區別老師能否簡單介紹一下？
A2：HBase適合做資料分析，MongoDB線上服務效能很好，尤其是讀，HBase要結合MapReduce，還有就是MongoDB適合Web服務，例如PHP。
文章來自微信公眾號：DBAplus社群