????????經美國權威機構IDC調查發現，現如今的公司正在以前所未有的速度和豐富的類型產生數據，并且也有能力存儲這些數據，但是，如何關聯這兩方面以便產生最大的商業價值，是所有公司共同面臨的挑戰。這個問題非常復雜：雖然業務人員在技能提升和專業工具的幫助下，越來越了解數據，但由于數據的增長速度越來越快，積累量級越來越大，公司可以利用的數據比例正在迅速下降。

1.1.1.1 ?什么是大數據

????????Gartner認為與過去相關概念相比，大數據強調3V特征，即Volume（量級）、Varity（種類）、Velocity（速度）和Value（價值），如圖?1.1.1所示。

圖?1.1.1?大數據四大特性

????????如今存儲的數據量正在急劇增長，2000年全球存儲了EB級別的數據，預計到2020年，該值將變為ZB級別。僅TWitter每天就會生成超過10TB的數據，Facebook的數據為幾十TB，一些特殊的企業在每小時就會產生TB級別的數據。

????????上面這些企業是一些典型的案例，其實我們生活的方方面面都會形成很多“軌跡”。例如，打開手機會生成一個事件；乘坐公共交通刷卡，這是一個事件；檢票登機、打卡上班、App Store上購買應用、更換電視頻道、使用高速路電子收費系統等。每一項操作都會生成數據，并且該數據的量級與參與的人數相關，全球60億人口，如果僅僅1/10的人參與進來，那么這個數據量級就已經非常驚人。就在10年前IT界超過1TB的數據倉庫屈指可數，而現在則是“舉不勝舉”。

????????隨著傳感器、智能設備以及社交協作技術的激增，企業中的數據也變得更加復雜，因為它不僅包含傳統的關系型數據，還包含來自網頁、Web日志文件、社交媒體論壇、電子郵件、文檔、傳感器數據等原始、半結構化和非結構化數據。

????????傳統系統可能很難存儲、分析這些數據的內容，更不要說挖掘有價值的信息。因為傳統的數據庫、數據倉庫、聯機事務處理等技術并不適合處理這些數據。盡管一些公司正在朝大數據方向大力發展，但總體而言，大部分公司只是剛開始理解大數據。當回首整個數據庫發展的歷程會發現，人們將大部分時間都花在僅20％的數據上：這些數據格式整齊且符合嚴格模式的關系類型。但事實是，全球80％的數據是非結構化的或者半結構化的。

????????視頻和圖片不能輕松或高效地存儲在關系型數據庫中，某些事件信息可能動態地更改（如氣象），它們不太適合嚴格的模式。要利用大數據，企業必須能夠分析所有類型的數據，包括關系和非關系數據：文本、傳感器數據、音頻和視頻等。

????????有效處理大數據需要在數據變化的過程中對它的數量和種類進行分析，而不只是在“靜止”狀態進行分析。業界定義這種情況為從單純批量計算模式到實時動態計算模式的內涵式轉變。內涵式在這里也比較容易理解，即結構優化、質量提高，是一種實現實質性的跨越式的進程。大數據平臺允許用戶將所有數據存儲為其原生的業務對象格式，通過可用組件上的大規模并行計算實現價值，不僅僅是批量處理和離線分析，同時支持實時查詢和處理等特征，甚至要求響應時間在毫秒級別，并且可承受大規模的并發訪問，這些都是“速度”特征的范疇。

1.1.1.2 ?為何大數據至關重要

????????這種非傳統分析是否適合企業的業務需求？換句話說就是能否找到一個大數據平臺可為當前的分析工具提供補充實現，并且兼容現有解決方案，以實現更好的業務成果。

????????通常情況下，數據必須經過清理才能規范地存放到數據倉庫中。相反大數據解決方案不僅會利用不適合傳統倉庫且數量龐大的數據，而且不需要改變原有數據格式，保留了數據的真實性，并能夠快速訪問海量的信息。對于不能使用傳統關系型數據庫方法處理的信息所帶來的挑戰，大數據解決方案非常適合。大數據之所以重要，是因為其具備解決現實問題的三個關鍵方面。

• ???分析各種不同來源的結構化、半結構化和非結構化數據的理想選擇。
• ???當需要分析所有或大部分數據，或者對一個數據抽樣分析效果不明顯時，大數據解決方案是理想的選擇。
• ???未預先確定數據的業務度量指標時，是進行迭代式和探索式分析的理想選擇。

1.1.1.3 ?NoSQL在大數據中扮演的角色

????????NoSQL，是Not only SQL的縮寫，泛指非關系型的數據庫。與關系型數據庫相比，NoSQL存在許多顯著的不同點，其中最重要的是NoSQL不使用SQL作為查詢語言。其數據存儲可以不需要固定的表模式，也通常會避免使用SQL的JOIN操作，一般又都具備水平可擴展的特性。NoSQL的實現具有兩個特征：使用硬盤和把隨機存儲器作存儲載體。

1.??傳統關系型數據庫的缺陷

????????隨著互聯網Web2.0的興起，傳統的關系數據庫在應付Web2.0網站，特別是超大規模和高并發的SNS類型動態網站時已經力不從心，暴露了很多難以克服的問題。

(1)??高并發讀寫的瓶頸

????????Web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用靜態化技術，因此數據庫并發負載非常高，可能峰值會達到每秒上萬次讀寫請求。關系型數據庫勉強可以應付上萬次SQL，但是應付上萬次SQL寫數據請求，硬盤I/O卻無法承受。其實對于普通的BBS網站，往往也存在相對高并發寫請求的需求，例如，人人網的實時統計在線用戶狀態，記錄熱門帖子的點擊次數，投票計數等，這是一個相當普遍的業務需求。

(2)??可擴展性的限制

????????在基于Web的架構中，數據庫是最難以進行橫向擴展的，當應用系統的用戶量和訪問量與日俱增時，數據庫系統卻無法像Web Server和APP Server那樣簡單地通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，而不能通過橫向添加節點的方式實現無縫擴展。

(3)??事務一致性的負面影響

????????事務執行的結果必須是使數據庫從一個一致性狀態變化到另一個一致性狀態。保證數據庫一致性是指當事務完成時，必須使所有數據都具有一致的狀態。在關系型數據庫中，所有的規則必須應用到事務的修改上，以便維護所有數據的完整性，這隨之而來的是性能的大幅度下降。很多web系統并不需要嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了高負載下的一個沉重負擔。

(4)??復雜SQL查詢的弱化

????????任何大數據量的Web系統都非常忌諱幾個大表間的關聯查詢， 以及復雜的數據分析類型的SQL查詢，特別是SNS類型的網站，從需求以及產品設計角度就避免了這種情況的產生。更多的情況往往只是一單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大地弱化了，所以這部分功能不能得到充分發揮。

2.??NoSQL數據庫的優勢

(1)??擴展性強

????????NoSQL數據庫種類繁多，但是一個共同的特點就是去掉關系型數據庫的關系特性，若數據之間是弱關系，則非常容易擴展。例如，HBase、Cassandra等系統的水平擴展性能非常優越，非常容易實現支撐數據從TB到PB級別的過渡。

(2)??并發性能好

????????NoSQL數據庫具有非常良好的讀寫性能， 尤其在大數據量下，同樣表現優秀。這得益于它的弱關系性，數據庫的結構簡單。一般MySQL使用QueryCache，每當表發生更新操作時，Cache就會失效，這是一種大粒度的Cache，在針對Web2.0的交互中頻繁應用，Cache性能并不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說性能要高很多。

(3)??數據模型靈活

????????NoSQL無須事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系型數據庫中，增刪字段是一件非常麻煩的事情。對于數據量非常大的表，增加字段簡直就是一場噩夢。NoSQL允許使用者隨時隨地添加字段，并且字段類型可以是任意格式。HBase作為NoSQL數據庫的一種，當然也具備上面提到的種種優勢。使用過Hadoop的讀者知道，Hadoop最適合的應用場景是離線批量處理數據，其離線分析的效率非常高，能在分鐘級別處理TB級的數據，但是一般的應用系統并不適合批量模式訪問，更多的還是用戶的隨機訪問，就類似訪問關系型數據庫中的某條記錄一樣。HBase的列式存儲的特性支撐它實時隨機讀取、基于KEY的特殊訪問需求。當然，HBase還有不少新特性，其中不乏有趣的特性，在接下來的內容中將會詳細介紹。

????????HBase(Hadoop Database）是一個高可靠、高性能、面向列、可伸縮的分布式數據庫，利用HBase技術可在廉價PC上搭建起大規模結構化存儲集群。HBase參考Google的BigTable建模，使用類似GFS的HDFS作為底層文件存儲系統，在其上可以運行MapReduce批量處理數據，使用ZooKeeper作為協同服務組件。

????????HBase的整個項目使用Java語言實現，它是Apache基金會的Hadoop項目的一部分，既是模仿Google BigTable的開源產品，同時又是Hadoop的衍生產品。而Hadoop作為批量離線計算系統已經得到了業界的普遍認可，并經過了工業上的驗證，所以HBase具備“站在巨人肩膀之上”的優勢，其發展勢頭非常迅猛。HBase還是一種非關系型數據庫，即NoSQL數據庫。在Eric Brewer的CAP理論中，HBase屬于CP類型的系統，其NoSQL的特性非常明顯，這些特性也決定了其獨特的應用場景。接下來的內容將詳細講解HBase的發展歷史、發行版本和特性。

?

1.1.2.1 ?HBase的發展歷史

????????Apache HBase最初是Powerset公司為了處理自然語言搜索產生的海量數據而開展的項目，由Chad Walters和Jim Kellerman兩人發起，經過兩年的發展之后被Apache基金會收錄為頂級項目，同時成為非常活躍、影響重大的項目。

????????2006年11月，?Google開放了論文“Bigtable:A Distributed Storage System for structured Data"，該論文就是HBase的原型。2007年2月，倡導者提出作為Hadoop的模塊的HBase原型，該原型包含HBase的基本介紹、表設計、行鍵設計和底層數據存儲結構設計等內容。

????????經過一段時間的醞釀和開發工作，在2007年10月第一個可用的、簡單的HBase版本發布，該版本只實現了最基本的模塊和功能，因為只是初始開發階段，此時的HBase版本發展很不完善。2008年1月，Hadoop升級為頂級項目，HBase作為Hadoop的一個子項目存在，HBase的活躍度非常高，在短短不到2年的時間經歷了N多個版本的發布，并且其中包含了版本號的大“跳躍”。下面是一些版本發布的信息：

• ???HBase-0.18.0于2008年9月21日發布
• ???HBase-0.20.6于2010年7月10日發布
• ???HBase-0.89.20100621于2010年6月25日發布

????????其中，從HBase-0.20.6到HBase-0.89.20100621版本，經歷了版本的大“跳躍”。在2009年秋季發布0.20系列版本后，HBase經歷了發展歷史上的一次版本大變動，在此之前的版本都追隨Hadoop的主版本，例如，HBase 0.X.＊版本都會伴隨著Hadoop 0.X.＊版本，之所以出現版本跳躍，官方給出的解釋有兩點。

• ???Hadoop的版本更新已經放緩，而HBase相比Hadoop開發來講更加活躍，發布版本更加頻繁，并且Hadoop已經有多個分支，HBase也需要兼容多個分支，所以不再需要與Hadoop的版本更新步伐保持一致。
• ???從HBase的功能實現上來講，已經基本實現BigTable論文中實現的功能，也就是HBase的實現已經接近“1.0"，應該賦予一個更接近“1.0”的版本。

????????“跳躍”之后的版本發布比較規律，先后經歷了0.90.＊、0.92.＊、0.94.＊、0.96.＊、0.98.*、1.0.*、1.1*七個大的版本，現在穩定版本是1.0.1.1。

1.1.2.2 ?HBase的發行版本

????????本節主要介紹現有HBase的版本知識，從0.90.0之后，HBase的版本更新是非常有規律的，可以從0.90.0、0.91.0、0.92.0、0.93.0、0.94.0、0.95.0、0.96.0、0.97.0、0.98.0、0.99.0、1.0.0、1.1.0這樣的版本變化中發現一些規律。

????????這些版本都是大版本，其中偶數版本是穩定發布版，而奇數版本都是開發版，基本不對外發布，但是可以在官方JIRA的項目管理系統中找到這些奇數版本對應的開發信息，并且可以在SVN上找到相關的最新開發代碼。所以，偶數發布版本屬于穩定版本，奇數開發版本屬于不穩定版本，一般不建議用戶在生產環境中使用開發版本，這些也是大版本的發布規律。

????????小版本一般基于當前大版本的問題進行修正，一般表示小版本的數字在1-100之間，例如：?0.98.1、0.98.2、0.98.3、0.98.4。這些小版本都是基于0.98大版本的，截止到本書撰寫時，最新版本是1.1.1。小版本都是從小到大依次遞增，不存在版本跳躍的情況。對于小版本而言，原則上數值越大越穩定，因為小版本都是基于某一個大版本的，在小版本中并不會增加新特征，而是修正一些代碼的漏洞和問題。

????????截止到本書完稿時，HBase官方給出的最新版本信息如下面的代碼所示。從中可以看出，發布版本存在0.94、0.96、0.98、1.0、1.1幾個大版本。其中stable文件夾包含了最新的穩定發布版本；?HEADER.html文件用于對代碼發行版進行說明，即下面代碼中的前半部分，從“HBase Releases…”開始，一直到“’fresh’.”結束的解釋說明。每部分后面都有對應的發布時間，可以通過該時間判斷版本發布的間隔和項目的活躍程度。

HBase Releases

Please make sure you're downloading from a nearby mirror site, not from www.apache.org.

We suggest downloading the current stable release.

The 1.0.x series is the current stable release line, it supercedes 0.98.x and 0.94.x (the 0.98.x and 0.94.x lines are still seeing a monthly cadence of bug fix releases for those who are not easily able to update). Note that 0.96 was EOL'd September 1st, 2014. Use 1.0.x instead.

HBase最新版本，如表?1.1.1所示：

????????Stable文件夾存放的是最新的穩定發布版本，從下面的代碼中可以看到最新的穩定版本信息，其中發布版本包含文件名字、文件大小和發布日期等參數。

File Name? ??????????????????????? File Size?? ???????????? Date

HBase-1.0.1.1-bin.tar.gz?? ??????????? 95869521??? ????? 21-May-2015 18:01

HBase-1.0.1.1-bin.tar.gz.mds?? ?????????? 1133 ????????? 21-May-2015 18:01

HBase-1.0.1.1-src.tar.gz?? ??????????? 13701870??? ????? 21-May-2015 18:01

HBase-1.0.1.1-src.tar.gz.mds?? ??????????? 1133??? ????? 21-May-2015 18:01

????????這里不建議使用非穩定版本,因為很多的新功能并沒有經過工業界的驗證。需要特別聲明一下，本書的知識點講解、安裝部署、實戰案例和性能調優等都是基于HBase-1.0.1.1版本的，該版本是寫作本書時的最新穩定版。

1.1.2.3 ?HBase的特性

????????HBase作為一個典型的NoSQL數據庫，可以通過行鍵（Rowkey）檢索數據，僅支持行事務，主要用于存儲非結構化和半結構化的松散數據。與Hadoop相同，HBase主要依靠橫向擴展，通過不斷增加廉價的商用服務器來增加計算和存儲能力。

“典型”代表者HBase有不少特性，這些特性都標志著HBase的特立獨行、與眾不同，同時其良好的出身和特性也奠定了其在大數據處理領域的地位。下面介紹HBase具備的一些非常顯著的特點。

1.??容量巨大

????????HBase的單表可以有百億行、百萬列，數據矩陣橫向和縱向兩個維度所支持的數據量級都非常具有彈性。傳統的關系型數據庫，如Oracle和MySQL等，如果數據記錄在億級別，查詢和寫入的性能都會呈指數級下降，所以更大的數據量級對傳統數據庫來講是一種災難。而HBase對于存儲百億、千億甚至更多的數據都不存在任何問題。對于高維數據，百萬量級的列沒有任何問題。有的讀者可能關心更加多的列：千萬和億級別，這種非常特殊的應用場景，并不是說HBase不支持，而是這種情況下訪問單個Rowkey可能造成訪問超時，如果限定某個列則不會出現這種問題。

2.??面向列

????????HBase是面向列的存儲和權限控制，并支持列獨立檢索。有些讀者可能不清楚什么是列式存儲，下面進行簡單介紹。列式存儲不同于傳統的關系型數據庫，其數據在表中是按某列存儲的，這樣在查詢只需要少數幾個字段的時候，能大大減少讀取的數據量，比如一個字段的數據聚集存儲，那就更容易為這種聚集存儲設計更好的壓縮和解壓算法。下面是傳統行式數據庫與列式數據庫的不同特性。

傳統行式數據庫的特性如下：

• ???數據是按行存儲的。
• ???沒有索引的查詢使用大量I/O。
• ???建立索引和物化視圖需要花費大量的時間和資源。
• ???面對查詢需求，數據庫必須被大量膨脹才能滿足需求。

列式數據庫的特性如下：

• ???數據按列存儲，即每一列單獨存放。
• ???數據即索引。
• ???只訪問查詢涉及的列，可以大量降低系統I/O。
• ???每一列由一個線索來處理，即查詢的并發處理性能高。
• ???數據類型一致，數據特征相似，可以高效壓縮。

????????列式存儲不但解決了數據稀疏性問題，最大程度上節省存儲開銷，而且在查詢發生時，僅檢索查詢涉及的列，能夠大量降低磁盤I/O。這些特性也支撐HBase能夠保證一定的讀寫性能。

3.??稀疏性

????????在大多數情況下，采用傳統行式存儲的數據往往是稀疏的，即存在大量為空（NULL）的列，而這些列都是占用存儲空間的，這就造成存儲空間的浪費。對于HBase來講，為空的列不占用存儲空間，因此，表可以設計得非常稀疏。

4.??擴展性

????????HBase底層文件存儲依賴HDFS，從“基因”上決定了其具備可擴展性。這種遺傳的可擴展性就如同OOP中的繼承，“父類”HDFS的擴展性遺傳到HBase框架中。這是最底層的關鍵點。同時，HBase的Region和RegionServer的概念對應的數據可以分區，分區后數據可以位于不同的機器上，所以在HBase核心架構層面也具備可擴展性。HBase的擴展性是熱擴展，在不停止現有服務的前提下，可以隨時添加或者減少節點。

5.??高可靠性

????????HBase提供WAL和Replication機制。前者保證了數據寫入時不會因集群異常而導致寫入數據丟失；后保證了在集群出現嚴重問題時，數據不會發生丟失或者損壞。而且HBase底層使用HDFS，HDFS本身的副本機制很大程度上保證了HBase的高可靠性。同時，協調服務的ZooKeeper組件是經過工業驗證的，具備高可用性和高可靠性。

6.??高性能

????????底層的LSM數據結構和Rowkey有序排列等架構上的獨特設計， 使得HBase具備非常高的寫入性能。Region切分、主鍵索引和緩存機制使得HBase在海量數據下具備一定的隨機讀取性能，該性能針對Rowkey的查詢能夠達到毫秒級別。同時，HBase對于高并發的場景也具備很好的適應能力。該特性也是業界眾多公司選取HBase作為存儲數據庫非常重要的一點。

HBase參考了Google的BigTable建模，且將下面三篇博文作為HBase實現的理論基礎：

• ???BigTable by Google (2006)
• ???HBase and HDFS Locality by Lars George (2010)
• ???No Relation:The Mixed Blessings of Non-Relational Databases by Ian Varley (2009)

????????從上面的博文列表中也可以看出，HBase和HDFS有著非常緊密的關系，更準確的說法是：HBase嚴重依賴Hadoop的HDFS組件，HBase使用HDFS作為底層存儲系統。因此，如果要使用HBase，前提是首先必須有Hadoop系統。從后面第2節的HBase安裝過程的講解中也可以總結出這點。Hadoop的組件之一MapReduce可以直接訪問HBase，但是，這不是必需的，因為HBase中最重要的訪問方式是原生Java API，而不是MapReduce這樣的批量操作方式。圖1.1.2展示了HBase在Hadoop生態系統中的位置。

圖1.1.2?Hadoop生態系統總圖

????????因為HBase底層依賴Hadoop，所以選擇Hadoop版本對HBase部署很關鍵。表?1.1.2顯示了不同HBase發行版本所支持的Hadoop版本信息。基于HBase版本，應該選擇合適的Hadoop版本，表?1.1.2是官方給出的HBase和Hadoop的版本支持矩陣。

表?1.1.2?Hadoop版本支持矩陣

表?1.1.2中字母的含義如下。

• ???S：經過測試的、支持的。
• ???X：不支持。
• ???NT：可以運行但測試不充分。

當然，并不是說只要滿足表?1.1.2中的版本匹配就可以了，在考慮版本匹配的同時也需要考慮一些其他因素，例如：

1. ???對于ZooKeeper的版本只需要跟HBase依賴庫中的ZooKeeper保持一致即可。

????????Hadoop框架包含兩個核心組件：HDFS和MapReduce，其中HDFS是文件存儲系統，負責數據存儲；MapReduce是計算框架，負責數據計算。它們之間分工明確、低度耦合、相關關聯。對于HBase數據庫的核心組件，即核心功能模塊共有4個，它們分別是：客戶端Client、協調服務模塊ZooKeeper、主節點HMaster和Region節點RegionServer，這些組件相互之間的關聯關系如圖?1.1.3所示。

圖?1.1.3? HBase架構圖

1.1.4.1 ?客戶端Client

????????客戶端Client是整個HBase系統的入口。使用者直接通過客戶端操作HBase。客戶端使用HBase的RPC機制與HMaster和RegionServer進行通信。對于管理類操作，Client與HMaster進行RPC通信；對于數據讀寫類操作，Client與RegionServer進行RPC交互。這里客戶端可以是多個，并不限定是原生Java接口，還有Thrift、Avro、Rest等客戶端模式，甚至MapReduce也可以算作一種客戶端。

1.1.4.2 ?協調服務組件ZooKeeper

????????ZooKeeper Quorum（隊列）負責管理HBase中多HMaster的選舉、服務器之間狀態同步等。再具體一些就是，HBase中ZooKeeper實例負責的協調工作有：存儲HBase元數據信息、實時監控Regionserver、存儲所有Region的尋址入口，當然還有最常見的功能就是保證HBase集群中只有一個HMaster節點。

1.1.4.3 ?主節點HMaster

????????HMaster沒有單點問題，在HBase中可以啟動多個HMaster，通過ZooKeeper的Master選舉機制保證總有一個Master正常運行并提供服務，其他HMaster作為備選時刻準備（當目前HMaster出現問題時）提供服務。HMaster主要負責Table和Region的管理工作：

• ???管理用戶對Table的增、刪、改、查操作。
• ???管理RegionServer的負載均衡，調整Region分布。
• ???在Region分裂后，負責新Region的分配。
• ???在RegionServer死機后，負責失效RegionServer上的Region遷移。

1.1.4.4 ?Region節點HRegionServer

????????HRegionServer主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據，是HBase中最核心的模塊。HRegion內部管理了一系列HRegion對象，每個HRegion對應了Table中的一個Region。HRegion由多個HStore組成,?每個HStore對應了Table中的一個Column Family的存儲。可以看出每個Column Family其實就是一個集中的存儲單元，因此最好將具備共同I/O特性的列放在一個column Family中，這樣能保證讀寫的高效性。HRegionServer的組成結構如圖?1.1.4所示。

????????如圖?1.1.4所示，HStore存儲是HBase存儲的核心，由兩部分組成：MemStore和StoreFile。Memstore是Sorted Memory Buffer，用戶寫入的數據首先會放入MemStore中，當MemStore滿了以后會緩沖（flush）成一個StoreFile（底層實現是HFile)，當StoreFile文件數量增長到一定閾值，會觸發Compact操作，將多個StoreFiles合并成一個StoreFile，在合并過程中會進行版本合并和數據刪除，因此可以看出HBase其實只有增加數據，所有的更新和刪除操作都是在后續的Compact過程中進行的，這使得用戶的寫操作只要進入內存中就可以立即返回，保證了HBase I/O的高性能。

圖?1.1.4?HRegionServer的組成結構

????????StoreFiles在觸發Compact操作后，會逐步形成越來越大的StoreFile，當單個StoreFile大小超過一定閾值后，會觸發Split操作，同時把當前Region分裂成2個Region，父Region會下線，新分裂的2個子Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上。

????????每個HRegionServer中都有一個HLog對象，HLog是一個實現Write Ahead Log的類，在每次用戶操作寫入MemStore的同時，也會寫一份數據到HLog文件中，HLog文件定期會滾動出新，并刪除舊的文件（已持久化到StoreFile中的數據）。在HRegionServer意外終止后，HMaster會通過ZooKeeper感知到，首先處理遺留的HLog文件，將其中不同Region的Log數據進行拆分，分別放到相應Region的目錄下，然后再將失效的Region重新分配，領取到這些Region的HRegionServer在加載Region的過程中， 會發現有歷史HLog需要處理，因此會將HLog中的數據回放到MemStore中，然后緩沖（flush）到StoreFiles，完成數據恢復。

?

????????了解軟件產品的最好方法是如何使用，解決什么問題以及如何適用于大型應用架構。接下來的內容將詳細介紹一些業界成功使用HBase的場景。但是，不要認為HBase只能解決下面的這些使用場景，因為它是一個正在發展和完善的技術框架，根據使用場景進行的創新正驅動著系統的發展。

????????下面是對HBase適用場景的一些抽象概括，從需求角度進行抽象，涵蓋存儲量級、性能、擴展、數據格式和關聯關系等方面。

• ???存儲大量的數據（PB級數據）且能保證良好的隨機訪問性能。
• ???需要很高的寫吞吐量，瞬間寫入量很大，傳統數據庫不能支撐或需要很高成本支撐的場景。
• ???可以進行優雅的數據擴展，動態擴展整個存儲系統容量。
• ???數據格式無限制，支持半結構化和非結構化的數據。
• ???業務場景簡單，不需要全部的關系型數據庫特性，例如交叉列、交叉表，事務、連接等。

????????愿意使用HBase的用戶數量在過去幾年里迅猛增長，部分原因在于HBase產品變得更可靠，性能變得更好，主要原因在于越來越多的公司開始投入大量資源來支持和使用它。隨著越來越多的商業服務供應商提供支持，用戶越發自信地把HBase應用于關鍵應用系統。一個設計初衷是存儲互聯網持續更新網頁副本的技術， 用在互聯網相關的其他方面也很合適。下面涉及通過實際案例來介紹HBase最適合的應用場景。

1.1.5.1 ?搜索引擎應用

????????搜索是定位用戶感興趣信息的行為：例如，搜索某部電影，或者想了解這部電影的信息。搜索含有特定詞語的文檔，用戶可能非常想觀看這需要查找索引，該索引提供了特定詞語和包含該詞語的所有文檔的映射。為了能夠搜索，首先必須建立索引。Google、百度以及其他搜索引擎都是這么做的。它們的文檔庫是互聯網的Web頁面。

????????HBase為這種文檔庫提供存儲、行級訪問。網絡爬蟲可以基于HBase非常方便地插入和更新單個文檔。同時搜索索引可以基于HBase通過MapReduce計算高效生成。如果訪問單個文檔，可以直接從HBase取出（即隨機讀取），并且HBase支持多種訪問模式。

HBase應用于網絡搜索的整個邏輯過程如下：

1. ?爬蟲持續不斷地抓取新頁面存儲到HBase中；
2. 在整張表上使用MapReduce計算并生成索引，供網絡搜索應用使用；
3. ?用戶發起網絡搜索請求；
4. ?網絡搜索應用查詢建立好的索引，或者直接從HBase得到單個文檔；
5. ?搜索結果提交給用戶。

1.1.5.2 ?增量數據存儲

????????在大多數情況下，數據通常是慢慢累加到已有數據庫以備將來使用，例如分析、處理和服務。許多HBase使用場景屬于這個類別—用HBase作為數據存儲，存儲來自各種數據源的增量數據。這種數據源可能是網頁爬蟲，可能是記錄用戶看了什么廣告和看多長時間的廣告效果數據，也可能是記錄各種參數的時間序列數據。下面介紹一些有關該使用場景的成功案例。

• ???增量監控數據：OpenTSDB系統

????????如果一款Web產品的注冊用戶達到千萬，則后臺的基礎架構需要數百臺以上的服務器，用于承擔服務流量、日志收集、數據存儲和數據處理等操作。為了保持產品正常運行，監控服務器和其中運行軟件的健康狀態至關重要。大規模監控整個環境需要能夠采集和存儲來自不同數據源的各種參數的監控系統。一些公司使用商業工具來收集和展示參數，而其他一些公司采用開源框架。StumbleUpon開源了OpenTSDB框架，其含義是開放時間序列數據庫（Open Time Series Database)，用來收集服務器的各種監控參數。該框架使用HBase作為核心平臺來存儲和檢索所收集的參數。創建這個框架的目的是為了擁有一個可擴展的監控數據收集系統，一方面能夠存儲和檢索參數數據并保存很長時間，另一方面如果需要增加功能也可以隨時添加各種新參數。

1.??增量用戶交互數據：Facebook Like按鈕

????????用過Facebook的讀者，應該記得其特有的Like按鈕，該按鈕已經成為Facebook的標志之一，每次用戶喜歡一個特定主題時，計數器就增加一次。這里的計數器是一個整數類型的變量，每次觸發喜歡操作就加1。這就是另外一種增量數據—用戶交互數據。

????????Facebook使用HBase的計數器來計量用戶喜歡特定網頁的次數，內容原創人和頁面所有者可以得到近乎實時的多少用戶喜歡他們網頁的數據信息。他們可以因此更敏捷地判斷應該提供什么內容。Facebook為此創建了一個叫Facebook Insight的系統，該系統需要一個可擴展的存儲系統。在技術選型的時候考慮了很多種可能，包括關系型數據庫、內存數據庫和Cassandra數據庫，最后決定使用HBase。基于HBase, Facebook可以很方便地橫向擴展服務規模，提供給數百萬用戶，也可以繼續使用他們已有的運行大規模HBase集群的經驗。該系統每天處理數百億條事件，記錄數百個參數。

2.??增量遙測數據：Firefox瀏覽器

????????軟件運行和質量數據，不會像監控參數數據那么簡單。例如，軟件崩潰報告是有用的軟件運行數據，經常用來探究軟件質量和規劃軟件開發路線圖。HBase可以成功地收集和存儲用戶計算機上生成的軟件崩潰報告。這種使用場景與前兩種使用場景不同，不一定與網絡服務應用有關系。Mozilla最出色的軟件就是Firefox瀏覽器，該軟件安裝在全球數千萬量級的個人計算機上，支持各種操作系統。當瀏覽器出現異常或者崩潰時，會以Bug報告的形式返回給Mozilla后臺服務器。Mozilla后臺使用Socorro系統收集這些報告，該系統的數據存儲和分析建構在HBase上，分析結果用于向研發部門提供建議和決策支持。采用HBase可以存儲更多的數據，使得分析結果更加準確，可以在更大程度上幫助和指導開發人員。

3.??增量廣告點擊數據：電商、廣告監控行業

????????現今，在線廣告已經成為互聯網產品的一個主要收入來源。絕大部分的互聯網產品提供免費服務給用戶，在用戶使用服務時投放廣告給目標用戶。這種精準投放需要針對用戶交互數據做詳細的采集和分析，以便理解用戶的特征。精細的用戶交互數據帶來更好的模型，進而導致更好的廣告投放效果和更多的收入。但這類數據有兩個特點：以連續流的形式出現、很容易按用戶劃分。在理想情況下，這種數據一旦產生就能夠馬上使用，用戶特征模型可以沒有延遲地持續優化。國內的電商和廣告監控等非常前沿、活躍的互聯網公司已經在熟練地使用類似Hadoop和HBase這樣的新技術，例如淘寶的實時個性化推薦服務，中間推薦結果的存儲使用HBase， 并且廣告相關的用戶建模數據也存儲在HBase中。廣告監控行業中的AdMaster、締元信等公司的實時廣告數據監控和部分報表業務已經在使用HBase。

1.1.5.3 ?用戶內容服務

????????傳統數據庫的一個最大使用場合是為用戶提供內容服務。各種各樣的數據庫支撐著提供各種內容服務的應用系統。多年來，這些應用在發展，它們所依賴的數據庫也在發展。用戶希望使用和交互的內容種類越來越多。

1.??內容推薦引擎系統：搜狐

????????搜狐推薦引擎系統接入幾億用戶的行為日志，每日資訊量在百萬級，每秒約有幾萬條左右的用戶日志被實時處理入庫。在這種數據量上，要求推薦請求和相關新聞請求每秒支持的訪問次數在萬次以上，推薦請求的響應延時控制在70ms以內，同時系統要求10s左右完成從日志到用戶模型的修正過程。

????????這些性能需求指標是整個系統的難點，需要維護幾億用戶200GB的短期屬性信息，同時依靠這些隨用戶行為實時變化的屬性信息來更新用戶感興趣的文章主題，還要實時計算用戶所屬的興趣小組，完成由短期興趣主導的內容推薦和用戶組協同推薦。記錄用戶瀏覽歷史、周期性計算熱門文章等都是在HBase上完成的，由此可見HBase在高性能上的優勢。

2.??用戶模型服務：電商行業

????????經過HBase處理過的內容往往并不直接提交給用戶使用，而是用來豐富與用戶的交互，具體是決定應該提交給用戶什么內容。用戶模型可以存儲在HBase，用戶模型多種多樣，可以用于多種不同場景，例如，針對特定用戶投放什么廣告，用戶在電商門戶網站購物時是否實時報價，用戶在搜索引擎檢索時增加背景信息和關聯內容，等等。當用戶在電商網站上發生交易時，用戶模型服務可以用來實時報價。這種模型需要基于不斷產生的新用戶數據來持續優化。

1.1.5.4 ?實時消息系統構建

????????Facebook全新的Social Inbox產品，集成了E-mail、IM、短信、文本信息、在線消息。最為重要的是，該產品每個月要存儲超過1350億條消息。Facebook的Kannan Muthukkaruppan在《郵件的底層技術：HBase》一文中給了一個十分意外的答案-HBase。打敗了MySQL、Cassandra和其他一些技術，成為Facebook的選擇。為什么說是一個意外的答案？Cassandra是Facebook創造的，并且它就是為郵件類型的應用而打造的，但是Facebook發現Cassandra最終一致性模型并不適合其全新的實時郵件產品。Facebook同樣擁有大量的MySQL架構，但是在使用過程中發現MySQL性能會隨著數據和索引的增加變差。所以，Facebook同樣可以選擇自己來開發一個新的存儲模型，但是最終選擇了HBase。Facebook檢視了自己的應用場景，指出為什么要選擇HBase。Facebook所需要的系統應該能處理以下兩種數據：

• ???一個較小的臨時數據集，是經常變化的；
• ???一個不斷增加的數據集，是很少被訪問的。

????????顯然HBase就能搞定這一切。Facebook在Hadoop、Hive上積累了豐富的經驗，并且成為HBase的“大客戶”，基于這點，我們也有充足理由相信它能變得更加流行。

????????本節主要介紹了HBase上下文相關的知識，包括大數據背景、HBase的發展歷史、發行版本、特性、核心功能模塊以及使用場景和經典案例等知識點，并且詳細介紹了HBase是什么和HBase能做什么兩個要點，方便學生快速理解和掌握HBase框架。任何一種框架或者軟件都有其特定的應用場景，類似“萬金油”的框架是10年前大家追求的設計理念，所以HBase有其特定的使用場景。通過本節學習，學生可以迅速掌握HBase能用來做什么，不能用來做什么，最大程度上縮短學生的學習和使用成本。