本文根據(jù)DBAplus社群第99期線上分享整理而成，文末還有好書送哦~

　　講師介紹

陳鴻威

云財經(jīng)大數(shù)據(jù)CTO

曾任百度高級工程師，現(xiàn)主持設(shè)計開發(fā)云財經(jīng)股市情報和大數(shù)據(jù)中心；

擁有豐富的在線電商、證券實時系統(tǒng)、金融海量數(shù)據(jù)在線計算的實戰(zhàn)經(jīng)驗；致力于各類分布式和大數(shù)據(jù)開源項目研究。

　　主題簡介：

　　1、傳統(tǒng)數(shù)據(jù)庫回顧

　　2、分布式基礎(chǔ)理論

　　3、HBase特征

　　4、HBase底層架構(gòu)

　　5、HBase設(shè)計要點

　　傳統(tǒng)數(shù)據(jù)庫回顧

　　近些年來，各種互聯(lián)網(wǎng)+的公司如雨后春筍般出現(xiàn)，做一個在線平臺或者做一個APP基本成為這些公司的標配。Web系統(tǒng)的流行，數(shù)據(jù)收集越來越容易，促使各類數(shù)據(jù)庫系統(tǒng)應(yīng)用得越來越廣泛。

　　我們在平時的技術(shù)討論或者實際應(yīng)用中經(jīng)常會提到傳統(tǒng)數(shù)據(jù)庫。提到傳統(tǒng)數(shù)據(jù)庫，很多人會很容易聯(lián)想到Oracle、MySQL、SQL Server等帶有很明顯關(guān)系型數(shù)據(jù)庫特征的數(shù)據(jù)庫系統(tǒng)。在我看來，傳統(tǒng)數(shù)據(jù)庫并不等于這些數(shù)據(jù)庫，而是看帝國分表你怎么用的。一般來說，傳統(tǒng)數(shù)據(jù)庫包括以下三個鮮明的特點：

　　1、事務(wù)的保障：ACID

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

Atomicity 原子性 事務(wù)中所有操作要么全部完成，要么全失敗。

Consistency 一致性 在事務(wù)開始時或者結(jié)束時，數(shù)據(jù)庫應(yīng)該處于同一狀態(tài)。

Isolation 隔離性 事務(wù)將假定只有它自己在操作數(shù)據(jù)庫，彼此不知曉。

Durablity 一旦事務(wù)完成，就不能返回。

　　要做到ACID，從編程的角度來說，數(shù)據(jù)庫系統(tǒng)一定會用到鎖。

　　一般對事務(wù)要求比較高的主要是交易場景，銀行系統(tǒng)、大型在線電商交易系統(tǒng)用得比較多。對于絕大多數(shù)創(chuàng)業(yè)公司而言，事務(wù)是一個偏理論的概念。實際上在，在線系統(tǒng)中，事務(wù)是一個很有用的東西，我們舉個栗子：

　　用戶A在平臺購買增值服務(wù)的場景，會有很多種處理方式。

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

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

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

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

　　三年以上工作經(jīng)驗的程序員會如下處理：

在財務(wù)表中增加一條用戶A的扣費記錄。（扣費）

判斷財務(wù)表中是否扣費成功，不成功通知系統(tǒng)交易失敗。

在用戶增值服務(wù)表中增加一條用戶A的增值服務(wù)記錄。（開通服務(wù)）

判斷用戶增值服務(wù)表中是否增加成功，不成功刪除財務(wù)表中的扣費并且通知系統(tǒng)交易失敗。

　　那么用上事務(wù)之后，你只要提交給數(shù)據(jù)庫一般程序員操作，數(shù)據(jù)庫就會給你三年以上工作經(jīng)驗的程序員的操作結(jié)果，在主從架構(gòu)讀寫分離的數(shù)據(jù)庫結(jié)構(gòu)中效果還會更好。

　　2、豐富的數(shù)據(jù)類型和SQL的操作方式

　　傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)可以存很多種類型的數(shù)據(jù)，主要包括：

數(shù)字家族、整數(shù)和小數(shù)。整數(shù)又可以分為32位的，64位的…

字符串類型。字符串又分為固定長度的和可變長度的…

時間家族。日期、時間…

二進制流…

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

　　對于傳統(tǒng)數(shù)據(jù)庫系統(tǒng)的常用操作，我們一般會說CURD。即對表的增刪改查，基本都用SQL語句來實現(xiàn)。SQL語句的結(jié)構(gòu)主要分為以下幾大部分：

操作，select、insert、update、delete。

表對象。

字段范圍(*/f1/f2…)。

Where條件。

Order排序(desc/asc)。

查詢范圍限制（top/limit）。

　　……

　　SQL語句是為使用者友好而設(shè)計的，無論何種數(shù)據(jù)庫引擎，SQL最后都被映射成為IO和內(nèi)存操作。

　　3、嚴格的數(shù)據(jù)模型：行式存儲

　　在傳統(tǒng)數(shù)據(jù)庫系統(tǒng)中，一般來說在第一次寫入數(shù)據(jù)之前，都需要創(chuàng)建庫和創(chuàng)建表，而每一個表都有確定的表頭，確定列數(shù)，每一列的名字以及確定的數(shù)據(jù)類型。在新數(shù)據(jù)的寫入或者數(shù)據(jù)的修改的時候，數(shù)據(jù)庫系統(tǒng)會根據(jù)創(chuàng)建好的表結(jié)構(gòu)嚴格校驗數(shù)據(jù)的合法性，對表結(jié)構(gòu)的調(diào)整一般都需要很大的修改代價。

　　在存儲單元里，同一行的數(shù)據(jù)會分布在相鄰的存儲單元里。

　　列式存儲相對于行式存儲而言，其同一列的數(shù)據(jù)會分布在相鄰的存儲單元里。

　　題外話：除帝國分表了行存儲和列存儲，常見還有文檔模型，典型的代表就是MongoDB。如果用傳統(tǒng)的行的角度來看，不同的行列數(shù)可以不一樣，列的名字和數(shù)據(jù)類型也可以不一樣，列里面可以是另一個嵌套的行。

　　互聯(lián)網(wǎng)的需求

　　在互聯(lián)網(wǎng)化的大環(huán)境下，很多系統(tǒng)都很容易在短時間內(nèi)系統(tǒng)收集上億的數(shù)據(jù)，并且這些數(shù)據(jù)經(jīng)過加工，還要為幾十萬、幾百萬甚至更多用戶提供訪問。從平臺角度來說，一般就是從小到大，從簡單到復(fù)雜的過程。主要來說，具有一下三方面特點：

對數(shù)據(jù)高并發(fā)讀寫的要求

　　數(shù)據(jù)庫讀寫壓力巨大，硬盤IO無法承受。一般處理方法是主從架構(gòu)，讀寫分離，分庫、分表，緩解寫壓力，增強讀庫的可擴展性。

對海量數(shù)據(jù)的存儲和訪問

存儲記錄數(shù)量有限，SQL查詢效率極低的情況下。通過分庫、分表，緩解數(shù)據(jù)增長壓力。

伸縮性，可用性，可靠性方面的需求

　　橫向擴展艱難，無法通過快速增加服務(wù)器節(jié)點實現(xiàn)，系統(tǒng)升級和維護造成服務(wù)不可用。通過主從架構(gòu)，增強讀庫的擴展性，利用MMM架構(gòu)處理寫的瓶頸。

　　傳統(tǒng)數(shù)據(jù)庫的瓶頸

　　分庫分表缺點：

受業(yè)務(wù)規(guī)則影響，需求變動導(dǎo)致分庫分表的維護復(fù)雜。

系統(tǒng)數(shù)據(jù)訪問層代碼需要修改。

　　主從架構(gòu)缺點：

Slave實時性的保障，對于實時性很高的場合可能需要做一些處理（在第一個購買增值服務(wù)的例子中，添加扣費記錄之后，在讀寫分離的場景下，立馬去從庫查詢扣費記錄不一定能查到）。

高可用性問題，Master就是那個致命點，容易產(chǎn)生單點故障。

　　MMM缺點：

本身擴展性差，一次只能一個Master可以寫入，只能解決有限數(shù)據(jù)量下的可用性。

　　分布式基礎(chǔ)理論

　　1、CAP

分布式領(lǐng)域CAP理論

Consistency 一致性：數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的。

Availability(可用性)：好的響應(yīng)性能。

Partition tolerance：分區(qū)容忍性。

　　在分布式系統(tǒng)中，這三個要素最多只能同時實現(xiàn)兩點，不可能三者兼顧；對于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求；對于大多數(shù)Web應(yīng)用，犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

　　2、Base

Basically Available：基本可用 支持分區(qū)失敗。

Soft state 軟狀態(tài)：狀態(tài)可以有一段時間不同步，異步。

Eventually consistent：最終一致性 ，最終數(shù)據(jù)是一致的就可以了，而不是時時一致。

　　3、NoSQL運動兩個核心理論

Google的BigTable

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

Amazon的Dynamo

　　Dynamo使用的是另外一種分布式模型。Dynamo的模型更簡單，它將數(shù)據(jù)按key進行hash存儲。其數(shù)據(jù)分片模型有比較強的容災(zāi)性，因此它實現(xiàn)的是相對松散的弱一致性：最終一致性。

　　HBase特征

　　HBase是Google Bigtable的開源實現(xiàn)，類似Google Bigtable利用GFS作為其文件存儲系統(tǒng)，HBase利用Hadoop HDFS作為其文件存儲系統(tǒng)；Google運行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數(shù)據(jù)；Google Bigtable利用 Chubby作為協(xié)同服務(wù)，HBase利用ZooKeeper作為對應(yīng)。

　　主要特點

列的可以動態(tài)增加，并且列為空就不存儲數(shù)據(jù)，節(jié)省存儲空間。

HBase自動切分數(shù)據(jù)，使得數(shù)據(jù)存儲自動具有水平scalability。

HBase可以提供高并發(fā)讀寫操作的支持，分布式架構(gòu)，讀寫鎖等待的概率大大降低。

不能支持條件查詢，只支持按照Rowkey來查詢。

暫時不能支持Master server的故障切換，當Master宕機后，整個存儲系統(tǒng)就會掛掉。

　　HBase底層架構(gòu)

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

　　HBase設(shè)計要點

　　1、邏輯數(shù)據(jù)模型

Table

Region

ColumnFamily

Row

Column

Value

TimeStamp

　　你也可以把HBase看成一個多維度的Map模型去理解它的數(shù)據(jù)模型。正如下圖。

　　2、HBase的體系組成

　　NameNode存儲DataNode信息，ZooKeeper負責調(diào)度。

　　一個Region只會存在一臺RegionServer上，一臺RegionServer上可以包含多個Region。

　　一個邏輯的表包含多個Region，分布在各個RegionServer上，對應(yīng)用程序來說只有一個大表不用管分表分庫。

Region的定位

　　-ROOT-

　　.META

存儲分布

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

　　3、HBase各對象職責

Client

　　HBase的訪問接口，維護cache加快HBase的訪問。

Zookeeper

　　監(jiān)控Master，保證只有一個Master；

　　存儲Region的入口地址；

　　監(jiān)控RegionServer上下線，并告知Master；

　　存儲Hbase shcema和Table的元數(shù)據(jù)。

Master

　　分配Region到RegionServer；

　　RegionSever的負載均衡；

　　發(fā)現(xiàn)失效的RegionServer并重新分配其上的Region

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

RegionServer

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

　　Split&Compact。

　　4、應(yīng)用方式

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

　　RowKey是HBase表結(jié)構(gòu)設(shè)計中很重要的一環(huán) ，HBase中RowKey可以唯一標識一行記錄，在HBase查詢的時候，有以下2種方式：

按指定RowKey獲取唯一一條記錄，get方法

　　（org.apache.hadoop.hbase.client.Get）

按指定的條件獲取一批記錄，scan方法

　?。╫rg.apache.hadoop.hbase.client.Scan）

　　第一種類似key-value查找，第二種可以實現(xiàn)簡單的條件查詢功能。

　　Q&A

　　Q1：HBase是不是沒有傳統(tǒng)表的概念了。感覺都像是鍵值存儲。

　　A1：如果存儲角度看是涵蓋了的，但是去掉了關(guān)系。

　　Q2：HBase 與MongoDB的使用場景的區(qū)別老師能否簡單介紹一下？

　　A2：HBase適合做數(shù)據(jù)分析，MongoDB在線服務(wù)性能很好，尤其是讀，HBase要結(jié)合MapReduce，還有就是MongoDB適合Web服務(wù)，例如PHP。

　　直播鏈接

　　回聽直播請戳：

　　https://m.qlchat.com/topic/240000397746115.htm

　　密碼：222

好書相送

　　在本文微信訂閱號（dbaplus）評論區(qū)留下足以引起共鳴的真知灼見，并在本文發(fā)布后32小時之內(nèi)成為點贊數(shù)最多的一名，可獲得以下書籍一本~

　　特別鳴謝清華大學出版社提供圖書贊助。

　　精選專題（官網(wǎng)：dbaplus.cn）

　　◆ MVP專欄 ◆

　　楊志洪丨楊建榮丨鄒德裕丨韓鋒丨歐陽辰

　　網(wǎng)易丨騰訊云丨百度丨朱祥磊丨盧鈞軼

　　◆ 近期活動 ◆

　　云數(shù)據(jù)庫架構(gòu)設(shè)計與實踐沙龍火熱報名中