引子：

古代，人們用牛來拉重物。當(dāng)一頭牛拉不動一根圓木時，他們不曾想過培育更大更壯的牛。

同樣：我們也不需要嘗試開發(fā)超級計算機(jī)，而應(yīng)試著結(jié)合使用更多計算機(jī)系統(tǒng)。

—— Grace Hopper（計算機(jī)軟件第一夫人，計算機(jī)歷史上第一個BUG的發(fā)現(xiàn)者，也是史上最大BUG千年蟲的制造者）

這就是分布式。

再來看一組令人瞠目結(jié)舌的數(shù)據(jù)：

2012年11月11日

支付寶總交易額191億元，訂單1億零580萬筆，生成15TB日志，訪問1931億次內(nèi)存數(shù)據(jù)塊，13億個物理讀……

從上面的資料中我們看到了：高性能！高并發(fā)！高一致性！高可用性！海量數(shù)據(jù)！

這就是海量數(shù)據(jù)處理。遠(yuǎn)遠(yuǎn)超出單臺計算機(jī)的能力范疇。

這就是分布式集群能力的體現(xiàn)，更說明了采用分布式系統(tǒng)的必要性。

正文：

單臺設(shè)備的性能、資源、可擴(kuò)展性等限制 —— 分布式系統(tǒng)（Hadoop）

傳統(tǒng)關(guān)系型數(shù)據(jù)庫在面對海量數(shù)據(jù)時的乏力 —— 分布式數(shù)據(jù)庫（HBase）

關(guān)系型數(shù)據(jù)庫，顧名思義，善于處理數(shù)據(jù)模型間復(fù)雜的關(guān)系、邏輯、事務(wù)。

但在處理海量數(shù)據(jù)時速度、并發(fā)量、可擴(kuò)展性卻慘不忍睹。

當(dāng)然，我們可以通過巧妙的設(shè)計與二次開發(fā)來解決上述問題。

速度：分表（減少單表數(shù)據(jù)量）、緩存查詢、靜態(tài)預(yù)生成、提高硬件性能。

并發(fā)量：打破單機(jī)（或雙機(jī)）模式，組建數(shù)據(jù)庫集群。

可擴(kuò)展性：復(fù)雜的數(shù)據(jù)遷移方案。

這個過程想必相當(dāng)痛苦，而且由于技術(shù)約束，造成的用戶體驗(yàn)也不夠好。

比如我們查銀行賬單、手機(jī)話費(fèi)的歷史記錄，總要先選擇指定的月份或時間范圍，然后點(diǎn)提交。

這就是分表帶來的用戶體驗(yàn)下降。

什么是Hadoop

而在原生的分布式系統(tǒng)中，整個集群的節(jié)點(diǎn)間共享計算、存儲、IO資源，完美的解決了性能、并發(fā)、數(shù)據(jù)存儲問題。

看一組關(guān)于Google的資料（約在2010年）：

Google共有36個數(shù)據(jù)中心。其中美國有19個、歐洲12個、俄羅斯1個、南美1個和亞洲3個（北京-Google.cn<這個……>、香港-Google.com.hk和東京各1個）。
數(shù)據(jù)中心以集裝箱為單位，每個數(shù)據(jù)中心有眾多集裝箱，每個集裝箱里面有1160臺服務(wù)器。

如何使這么多臺服務(wù)器協(xié)同工作？

Google的三大核心元素：
　　1、Google文件系統(tǒng)（GFS）
　　2、Google大表；Bigtable：是Google一種對于半結(jié)構(gòu)化數(shù)據(jù)進(jìn)行分布存儲與訪問的接口或服務(wù)）；由于Google的文件系統(tǒng)異常龐大，以至于甲骨文和IBM公司的商業(yè)數(shù)據(jù)庫在方面無用武之地。另外，商業(yè)數(shù)據(jù)庫都是按 CPU數(shù)量來收費(fèi)，如果Google使用商業(yè)數(shù)據(jù)庫，可想而知，這是一筆天文數(shù)字。所以，Google量體裁衣地設(shè)計了符合自身的大表。
　　3、Mapreduce 算法；它是Google開發(fā)的C++編程工具，用于大于1TB數(shù)據(jù)的大規(guī)模數(shù)據(jù)集并行運(yùn)算。MapReduce能夠找出一個詞語在Google搜索目錄中 出現(xiàn)的次數(shù)；一系列網(wǎng)頁中特定詞語出現(xiàn)的頻率；鏈接到某個特定網(wǎng)站的所有網(wǎng)站數(shù)量等。

好用的東西，總能找到對應(yīng)的開源實(shí)現(xiàn)，這就是Hadoop。

Hadoop的構(gòu)成

其中：

Pig，可以使用Pig Latin流式編程語言來操作HBase中的數(shù)據(jù)

Hive，可以使用類似SQL語言來訪問HBase，最終本質(zhì)是編譯成MapReduce Job來處理HBase表數(shù)據(jù)，適合做數(shù)據(jù)統(tǒng)計。

誰在用Hadoop

Amazon、Adobe、Ebay、Facebook、Twitter、Yahoo、IBM……

國內(nèi)：淘寶和支付寶的數(shù)據(jù)倉庫、華為、百度的搜索日志分析，騰訊……

這里有更多的資料可查 http://wiki.apache.org/hadoop/PoweredBy

Facebook實(shí)時消息存儲系統(tǒng)于2010年下半年遷移到了HBase。

HBase的前生今世

2006 年末 —— Google “BigTable: A Distributed Storage System for Structured Data”；

2007 02月 —— HBase的源代碼初稿；

2007 10月 —— 第一個版本，隨Hadoop 0.15.0 捆綁發(fā)布；

2010 05月 —— HBase從Hadoop子項(xiàng)目升級成Apache頂層項(xiàng)目；

什么是HBase

HBase是一個在Hadoop上開發(fā)的面向列（同類軟件還有Cassandra和HyperTable）的分布式數(shù)據(jù)庫。

利用HDFS作為其文件存儲系統(tǒng)

利用MapReduce來處理HBase中的海量數(shù)據(jù)

利用Zookeeper作為協(xié)同服務(wù)，主要用于實(shí)時隨機(jī)讀/寫超大規(guī)模數(shù)據(jù)集

很多關(guān)系型數(shù)據(jù)庫為了應(yīng)對這種場景提供了復(fù)制（replication）和分區(qū)（partitioning）解決方案，讓數(shù)據(jù)庫能從單個節(jié)點(diǎn)上擴(kuò)展出去。

但是難以安裝和維護(hù)，且需要犧牲一些重要的RDBMS（Relational DataBase Management System）特性，連接、復(fù)雜查詢、觸發(fā)器、視圖以及外鍵約束這些功能要么運(yùn)行開銷大，要么根本無法使用。

HBase從另一個方向來解決可伸縮性的問題。它自底向上的進(jìn)行構(gòu)建，能夠簡單的通過增加節(jié)點(diǎn)來達(dá)到線性擴(kuò)展。

HBase并不是關(guān)系型數(shù)據(jù)庫，它不支持SQL，但它能夠做RDBMS不能做的事；

在廉價硬件構(gòu)成的集群上管理超大規(guī)模的稀疏表。

HBase的特點(diǎn)

面向列：列的動態(tài)、無限擴(kuò)展 —— 內(nèi)容評論的擴(kuò)展，同類數(shù)據(jù)集中存儲便于壓縮

稀疏表：有數(shù)據(jù)時這個單元格才存在 —— 節(jié)省空間

HBase表格示意圖

Row Key: 行鍵，Table的主鍵，Table中的記錄按照Row Key排序

Timestamp: 時間戳，每次數(shù)據(jù)操作對應(yīng)的時間戳，可以看作是數(shù)據(jù)的version number

Column Family：列簇，Table在水平方向有一個或者多個Column Family組成，一個Column Family中可以由任意多個Column組成，即Column Family支持動態(tài)擴(kuò)展，無需預(yù)先定義Column的數(shù)量以及類型，所有Column均以二進(jìn)制格式存儲，用戶需要自行進(jìn)行類型轉(zhuǎn)換。

HBase的組件構(gòu)成

HMaster （HA），負(fù)責(zé)Table和Region的管理工作

1、建表、刪表、查看表格屬性；

2、管理RegionServer負(fù)載均衡，調(diào)整Region分布；

3、Region Split后，負(fù)責(zé)新Region的分配；

4、在RegionServer失效后，負(fù)責(zé)失效節(jié)點(diǎn)上的Regions遷移；

RegionServer（x N），主要負(fù)責(zé)響應(yīng)用戶I/O請求，向HDFS文件系統(tǒng)中讀寫數(shù)據(jù)

HBase中表格的存儲

一張表存儲在[1-N)個HRegion中，每個HRegion保存某張表RowKey連續(xù)的一段記錄。

建表時可以預(yù)劃分HRegion——提高并行度，進(jìn)而提升讀寫速度

否則初始表存在單一HRegion中，隨著數(shù)據(jù)增大HRegion會分裂為多個HRegion

HBase中有兩張?zhí)厥獾腡able，-ROOT-和.META.

 .META.：記錄了用戶表的Region信息，.META.可以有多個regoin

 -ROOT-：記錄了.META.表的Region信息，-ROOT-只有一個region

 Zookeeper中記錄了-ROOT-表的location

首先 HBase Client端會連接Zookeeper Qurom

通過 Zookeeper組件Client 能獲知哪個 RegionServer管理-ROOT- Region 。

那么Client就去訪問管理 -ROOT-的HRegionServer ，在META中記錄了 HBase中所有表信息，(你可以使用   scan '.META.' 命令列出你創(chuàng)建的所有表的詳細(xì)信息 )，從而獲取Region 分布的信息。一旦 Client獲取了這一行的位置信息，比如這一行屬于哪個 Region，Client 將會緩存這個信息并直接訪問 HRegionServer。

久而久之Client 緩存的信息漸漸增多，即使不訪問 .META.表 也能知道去訪問哪個 HRegionServer。

HBase讀數(shù)據(jù)

HBase讀取數(shù)據(jù)優(yōu)先讀取HMemcache中的內(nèi)容，如果未取到再去讀取Hstore中的數(shù)據(jù)，提高數(shù)據(jù)讀取的性能。

HBase寫數(shù)據(jù)

HBase寫入數(shù)據(jù)會寫到HMemcache和Hlog中，HMemcache建立緩存，Hlog同步Hmemcache和Hstore的事務(wù)日志，發(fā)起Flush Cache時，數(shù)據(jù)持久化到Hstore中，并清空HMemecache。

文本部分內(nèi)容與圖片引用于互聯(lián)網(wǎng)，引用地址如下：

http://www.searchtb.com/2011/01/understanding-hbase.html

Author：Pirate Leo

myBlog: http://blog.csdn.net/pirateleo/

myEmail: codeevoship@gmail.com