一分鐘搞懂HBase
什么是HBase?
HBase(Hadoop Database)是Apache的Hadoop項目的子項目，是一個分布式的、面向列的開源數(shù)據(jù)庫，就像Bigtable利用了Google文件系統(tǒng)(GFS)所提供的分布式數(shù)據(jù)存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。
為什么采用HBase?
HBase不同于一般的關(guān)系數(shù)據(jù)庫，它是一個適合于非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫，HBase是介于Map Entry(key & value)和DB Row之間的一種數(shù)據(jù)存儲方式，有點類似于現(xiàn)在流行的Memcache，但不僅僅是簡單的一個key對應(yīng)一個 value，你還可以根據(jù)需要存儲多個屬性的數(shù)據(jù)結(jié)構(gòu)，但沒有傳統(tǒng)數(shù)據(jù)庫表中那么多的關(guān)聯(lián)關(guān)系，這就是所謂的松散數(shù)據(jù)。
簡單來說，你在HBase中創(chuàng)建的表可以看做是一張很大的表，而這個表的屬性可以根據(jù)需求去動態(tài)增加，在HBase中沒有表與表之間關(guān)聯(lián)查詢。你只需要告訴你的數(shù)據(jù)存儲到HBase表的哪個column families 就可以了，不需要指定它的具體類型：char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事務(wù)此類的功能。
Apache HBase 和Google Bigtable 有非常相似的地方，一個數(shù)據(jù)行擁有一個可選擇的鍵和任意數(shù)量的列。表是疏松的存儲的，因此用戶可以給行定義各種不同的列，對于這樣的功能在大項目中非常實用，可以簡化設(shè)計和升級的成本。
HBase與傳統(tǒng)RDBMS的區(qū)別
應(yīng)用場景
有時候了解軟件產(chǎn)品的***方法是看看它是怎么用的。它可以解決什么問題和這些解決方案如何適用于大型應(yīng)用架構(gòu)，能夠告訴你很多。因為HBase有許多公開的產(chǎn)品部署，我們正好可以這么做。本章節(jié)將詳細(xì)介紹一些人們成功使用HBase的使用場景。
注意：不要自我限制，認(rèn)為HBase只能解決這些使用場景。它是一個初生的技術(shù)，根據(jù)使用場景進(jìn)行創(chuàng)新正驅(qū)動著系統(tǒng)的發(fā)展。如果你有新想法，認(rèn)為可以受益于HBase提供的功能，試試吧。社區(qū)很樂于幫助你，也會從你的經(jīng)驗中學(xué)習(xí)。這正是開源軟件精神。
互聯(lián)網(wǎng)搜索應(yīng)用
BigTable，和模仿出來的HBase，為這種文檔庫提供存儲，BigTable提供行級訪問，所以爬蟲可以插入和更新單個文檔。搜索索引可以基于BigTable 通過MapReduce計算高效生成。
捕獲增量數(shù)據(jù)
數(shù)據(jù)通常是細(xì)水長流，累加到已有數(shù)據(jù)庫以備將來使用，例如分析，處理和服務(wù)。許多HBase使用場景屬于這個類別—使用HBase作為數(shù)據(jù)存儲，捕獲來自于各種數(shù)據(jù)源的增量數(shù)據(jù)。例如，這種數(shù)據(jù)源可能是網(wǎng)頁爬蟲(我們討論過的互聯(lián)網(wǎng)搜索應(yīng)用問題)，可能是記錄用戶看了什么廣告和多長時間的廣告效果數(shù)據(jù)，也可能是記錄各種參數(shù)的時間序列數(shù)據(jù)。
半結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)
對于數(shù)據(jù)結(jié)構(gòu)字段不夠確定或雜亂無章很難按一個概念去進(jìn)行抽取的數(shù)據(jù)適合用HBase。例如，當(dāng)業(yè)務(wù)發(fā)展需要存儲用戶的email，phone，address信息時RDBMS需要停機(jī)維護(hù)，而HBase支持動態(tài)增加。
記錄非常稀疏
RDBMS的行有多少列是固定的，為null的列浪費了存儲空間。HBase為null的Column不會被存儲，這樣既節(jié)省了空間又提高了讀性能。
多版本數(shù)據(jù)
根據(jù)Row key和Column key定位到的Value可以有任意數(shù)量的版本值，因此對于需要存儲變動歷史記錄的數(shù)據(jù)，用HBase就非常方便了。比如用戶表的address是會變動的，業(yè)務(wù)上一般只需要***的值，但有時可能需要查詢到歷史值。
超大數(shù)據(jù)量
當(dāng)數(shù)據(jù)量越來越大，RDBMS數(shù)據(jù)庫撐不住了，就出現(xiàn)了讀寫分離策略，通過一個Master專門負(fù)責(zé)寫操作，多個Slave負(fù)責(zé)讀操作，服務(wù)器成本倍增。
隨著壓力增加，Master撐不住了，這時就要分庫了，把關(guān)聯(lián)不大的數(shù)據(jù)分開部署，一些join查詢不能用了，需要借助中間層。
隨著數(shù)據(jù)量的進(jìn)一步增加，一個表的記錄越來越大，查詢就變得很慢，于是又得搞分表，比如按ID取模分成多個表以減少單個表的記錄數(shù)。經(jīng)歷過這些事的人都知道過程是多么的折騰。
采用HBase就簡單了，只需要加機(jī)器即可，HBase會自動水平切分?jǐn)U展，跟Hadoop的無縫集成保障了其數(shù)據(jù)可靠性(HDFS)和海量數(shù)據(jù)分析的高性能(MapReduce)。
【本文為51CTO專欄作者“朱國立”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號“開發(fā)者圓桌”獲取聯(lián)系和授權(quán)】
