要想非常明確什么場景下用Hbase集币，那么我們來先了解下Hbase的主要核心特性考阱，那么在什么業(yè)務場景下用Hbase，就比較清晰了鞠苟！

Hbase是一種在Hadoop之上的NoSQL的Key/vale數據庫乞榨，底層依靠HDFS進行數據存儲。

一当娱、Hbase核心特性

海量數據存儲

面對互聯網應用的海量數據吃既，傳統(tǒng)關系型數據庫比如mysql，一般單表不會超過一千萬跨细，并且單表字段數量也一般不會超過100個鹦倚，否則性能急劇下降。

但基于Hbase的設計理念與存儲原理冀惭，Hbase單表可以有百億行震叙、百萬列掀鹅，在橫向和縱向兩個維度所支持的數據量級都非常巨大，在列上其實并沒有數量的限制媒楼。

Hbase可支撐PB級數據存儲乐尊，即支持的記錄數達萬億以上。

所以根據業(yè)務需求划址，當表需要非常大時扔嵌，可考慮選型Hbase。
如果最多只是上億條記錄并且列不是特別大的話夺颤，沒有必要放入hbase中痢缎，ES和mongodb都能輕松搞定。

面向列存儲

Hbase的數據在表中是按照列進行存儲的（列簇）拂共，可動態(tài)增加列牺弄，這樣在只查詢少數幾個字段的時候，不需要全表掃描宜狐，能極大提高查詢效率势告。

存儲記錄的多個版本

Hbase的每一個列的數據存儲有多個版本，比如地理位置列抚恒、天氣溫度列等咱台，可能有多次變更，所以該列可以有多個版本俭驮。Hbase會記錄數據所有的歷史版本回溺，在特定應用場景中非常有用。后面將會具體提到混萝。

列的稀疏性

為空的列并不占用存儲空間遗遵，表可以設計的非常稀疏。不必像關系型數據庫那樣需要預先知道所有列名然后再進行null填充逸嘀。

彈性伸縮/可擴展性

Hbase底層是依賴HDFS進行數據存儲與查詢的车要，由于HDFS的高可用性與極強的擴展性，所以Hbase一樣具備這樣的能力崭倘。

當數據量劇增翼岁，需要擴充磁盤空間時，只需要動態(tài)增加HDFS的datanode節(jié)點即可司光，非常方便琅坡。

數據高可靠性

Hbase本身寫入高可靠性特性，保證數據寫入的時候不會因為集群異常而導致寫入數據丟失残家。內存中沒有寫入磁盤的數據會記錄在相應的日志文件中榆俺，集群恢復后會獲取日志中的數據，保證數據不丟失。

Hbase底層使用HDFS谴仙，本身數據也有多個副本迂求。這種副本機制，保證了在集群節(jié)點出現故障后晃跺，數據不會丟失。

高性能

Hbase的Region切分毫玖、主鍵索引掀虎、緩存機制等特性，使得Hbase在海量數據下具備一定的隨機讀取性能付枫，該性能針對Rowkey的查詢能夠到達毫秒級別烹玉。

Hbase能夠達到準實時查詢，在百億行百萬列的情況下阐滩，查詢速度能達到百毫秒以內二打；

底層的LSM數據結構和RowKey有序排列等架構上的獨特設計，使得Hbase寫入性能也非常高掂榔，可支持千萬級高并發(fā)继效。

HBase 寫入速度快是因為數據并不是真的立即落盤，而是先寫入內存装获，隨后異步刷入HFile瑞信。所以在客戶端看來，寫入速度很快穴豫。

HBase從自身讀寫性能對比而言凡简，是一種讀比寫慢的數據庫。

以上精肃，初步介紹了Hbase的核心特性秤涩，接下來我們看看它適合的業(yè)務場景。

二司抱、適合的業(yè)務場景

寫密集型應用筐眷，每天寫入量巨大，而相對讀數量較小的應用

比如互聯網公司的社交軟件的歷史消息状植，大型系統(tǒng)的各種日志等浊竟。

Facebook用Hbase進行社交信息的存儲、查詢與分析津畸，主要存儲在線消息振定，每天數據量近百億，每月數據量超過200T肉拓。

基于HBase后频，Facebook可以很方便地橫向擴展服務規(guī)模，提供給數百萬用戶。該系統(tǒng)每天處理數百億條事件卑惜， HBase讀寫比基本在1:1膏执，吞吐量達到150w QPS。

此外露久，米聊歷史數據更米，消息push系統(tǒng)等多個重要應用系統(tǒng)都建立在HBase基礎之上。

網易的哨兵監(jiān)控系統(tǒng)毫痕，云信歷史數據征峦，日志歸檔數據等一系列重要應用底層都由HBase提供服務。

京東用Hbase存儲賣家操作日志消请，即幾十萬商家時時刻刻進行的各種操作栏笆。以便進行分析，并且可以保證商家可以精確查詢自己的各種操作臊泰。賣家操作日志的特點是：數據量大蛉加、實時性強、增多查少缸逃。

此外针饥，互聯網公司還需要收集和存儲海量用戶的操作行為，比如轉發(fā)察滑、評論和點贊打厘，通過這些行為來分析用戶的特征，形成用戶畫像贺辰，精準投放廣告户盯，提升廣告收入。

Hbase非常適合收集這種海量用戶的交互數據（每天數十億）饲化，并已經成功地應用在這種場合莽鸭，它可以增量捕獲第一手點擊流和用戶交互數據，然后用不同處理方式（MapReduce是其中一種）來處理數據（清理吃靠、裝飾硫眨、使用數據）。在這種公司巢块，你會發(fā)現很多HBase案例礁阁。

HBase只支持基于rowkey的查詢，對于HBase來說族奢，單條記錄或者小范圍的查詢是可以接受的姥闭，大范圍的查詢由于分布式的原因，可能在性能上有點影響越走。

并且不支持多條件復雜查詢棚品，不支持二級索引靠欢。

但當你面對每天數十億數據，數據量接近PB級時铜跑，如果也只是通過rowkey去查數據门怪，那么對于上PB級的數據，都非常適合用Hbase來查詢锅纺，性能也是非常高的掷空。

因此，Hbase適合做海量數據（億萬條記錄）的最底層數據源囤锉。

海量數據源都存在Hbase中拣帽，把可搜索的字段存到ES/Solr中作為二級索引，提供搜索服務嚼锄，業(yè)務系統(tǒng)用時，先從ES中搜索出記錄的rowkey蔽豺，再根據rowkey查Hbase即可区丑。

對性能和可靠性要求非常高的應用

由于HBase本身沒有單點故障，可用性非常高修陡。 數據量較大沧侥，而且增長量無法預估的應用，HBase支持在線擴展魄鸦，即使在一段時間內數據量呈井噴式增長宴杀，也可以通過HBase橫向擴展來滿足功能。

需要存儲歷史記錄場景

當業(yè)務需求拾因，需要持續(xù)記錄用戶的歷史記錄信息時旺罢，比如你想要存儲用戶的地址和喜好，這當然可以做成結構化SQL绢记。但是用戶把家搬到上海了扁达，那么以前在北京的地址要update覆蓋掉嗎，我們要計算分析用戶的整個人生周期的活動記錄和喜好蠢熄，來推測他的行為跪解，收入，知識層次签孔，信用叉讥，道德水準之類的，當然他的相關歷史行為是不能被丟棄的饥追。所以hbase可以很好的適應這樣的場景图仓！

三、用在生產環(huán)境前的注意事項：

HBase從本身原理和特性上保證了其高可用判耕、高可靠性透绩，以及分布式全內存異步的高寫入性能，那么最終用在生成環(huán)前需要注意以下幾個方面？

查詢條件：

HBase查詢條件簡單帚豪，只支持基于主鍵rowkey索引碳竟，即只能通過rowkey進行查詢，不能像其他數據庫一樣使用多條件復雜查詢狸臣，不支持二級索引莹桅，因此選型前，需確認是否能滿足業(yè)務需求烛亦。

rowkey設計要求較高

HBase是Key/vale數據庫诈泼，也只能通過key（即rowkey）來查詢數據，rowkey的設計非常重要煤禽，一個優(yōu)秀的rowkey設計铐达，即可以滿足查詢業(yè)務需求，同時也能讓數據均衡分布在集群中的節(jié)點上檬果。提升讀寫性能瓮孙。

不太適合大范圍key查詢

從HBase的存儲原理可知，其根據rowkey字節(jié)范圍進行分區(qū)分文件存儲选脊，大范圍的數據查詢會使查詢落到多個不同的RegionServer上杭抠，所以大范圍的rokey查詢，查詢效率會比較低下恳啥。

Hbase部署相對復雜偏灿，運維成本高：

部署Hbase集群之前，首先要部署Hadoop集群钝的，這包括HDFS翁垂、Yarn、Mapredue等一系列組件扁藕，其次還要部署Zookeeper集群沮峡。

在這兩塊的服務都正常部署啟動后，才能部署HBase集群亿柑，此外還包括監(jiān)控運維等服務組件邢疙。

這樣看，部署Hbase集群望薄，其實就是要部署和運維Hadoop的整個生態(tài)疟游，對于初步使用的開發(fā)者而言，還是有不小的工作量痕支。

四颁虐、總結

HBase已成熟地應用于國內外的很多大公司，總之卧须，HBase 適合用來存儲各種類型的大規(guī)模的數據另绩，高可用儒陨、擴展性好，可無限伸縮笋籽，可為用戶提供實時的在線查詢蹦漠，同時也支持離線的應用，配合Hadoop平臺具備天然的大數據分析優(yōu)勢车海。但也要注意上面提到的局限性笛园，因此，需要架構人員和研發(fā)人員進行綜合考量侍芝，發(fā)揮HBase優(yōu)勢研铆。

喜歡本文的朋友，歡迎關注州叠、轉發(fā)棵红、評論，讓我們一起成為有智慧的架構師咧栗！