HBase篇(1)-設計與應用場景
【每日五分鐘搞定大資料】系列，HBase第一篇
講完了Zookeeper， 接下來我們來說下Google三駕馬車之一BigTable的開源實現：HBase，要講得內容如下：
hbase的特點
- 千萬級高併發
- PB級儲存
- 非結構化儲存
- 動態列，稀疏列
- 支援二級索引
- 強一致性，可靠性，擴充套件性（CP系統，可用性做了一點讓步）
場景
1. 寫密集型應用，每天寫入量巨大，而相對讀數量較小的應用
2. 不需要複雜查詢條件來查詢資料的應用
使用rowkey，單條記錄或者小範圍的查詢效能不錯，大範圍的查詢由於分散式的原因，可能在效能上有點影響。
使用HBase的過濾器的話效能比較差。
3. 不需要關聯的場景，HBase為NoSQL無法支援join
4. 可靠性要求高
master支援主備熱切。
regionServer宕機，region會分配給線上的機器。
資料持久化在HDFS，預設3份，HDFS保證資料可靠性。
記憶體的資料若丟失可以通過Wal預寫日誌恢復。
5. 資料量較大，而且增長量無法預估的應用
HBase支援線上擴充套件，即使在一段時間內資料量呈井噴式增長，也可以通過HBase橫向擴充套件來滿足功能。
應用
- 物件儲存系統
HBase MOB（Medium Object Storage），中等物件儲存是hbase-2.0.0版本引入的新特性，用於解決hbase儲存中等檔案（0.1m~10m）效能差的問題。這個特性適合將圖片、文件、PDF、小視訊儲存到Hbase中。
- OLAP的儲存
Kylin的底層用的是HBase的儲存，看中的是它的高併發和海量儲存能力。kylin構建cube的過程會產生大量的預聚合中間資料，資料膨脹率高，對資料庫的儲存能力有很高要求。
Phoenix是構建在HBase上的一個SQL引擎，通過phoenix可以直接呼叫JDBC介面操作Hbase，雖然有upsert操作，但是更多的是用在OLAP場景，缺點是非常不靈活。
- 時序型資料
openTsDB應用，記錄以及展示指標在各個時間點的數值，一般用於監控的場景，是HBase上層的一個應用。
- 使用者畫像系統
動態列，稀疏列的特性。用於描述使用者特徵的維度數是不定的且可能會動態增長的(比如愛好，性別，住址等);不是每個特徵維度都會有資料
- 訊息/訂單系統
強一致性，良好的讀效能，至於hbase如何保證強一致性的後面的文章會詳細說明。
- feed流系統儲存
見下面的一波分析。
feed流系統
前幾天據說支援八個一線明星併發出軌的微博掛了....蹭個熱度，上面的系統我就不一一說了，大家應該知道微博是典型的feed流系統，那我們來詳細說下feed流系統。
什麼是feed流系統
feed流系統有三個概念，如圖（來自雲棲社群）
feed：
一個終端釋出的一些內容
- 可以是使用者釋出的動態訊息
- 可以是廣告系統推薦的廣告
- 也可以是系統本身推薦的一些公告
比如你在微博發了條動態，那這條動態就是feed
feeds流；
feeds流就是系統實時推送的根據了一定規則排序的資訊流
比如你刷了下微博，在你的首頁出現了按時間排好序的一堆新訊息，那這就是feed流
feeds訂閱；
這個比較簡單，就是你通過應用，微博，朋友圈這些，關注了某個人，那就是訂閱了Ta的feeds
Feed流系統的儲存
Feed流系統中需要儲存的內容大致可以分為兩部分，
- 賬號關係資料（比如關注列表）
- Feed訊息內容
其實有很多方案實現，但是這篇說的是HBase，那我們就說說如何用HBase實現。
關注列表
關注列表就不重點討論了，資料特點是：列數量不定，量大，關係簡單，有序，效能要求高，可靠性要求高。互相關注，單向關注這種場景用二級索引很好實現。
Feed訊息
資料的特點：
1.讀多寫少，舉個栗子，看我文章的人裡面有多少人是暗中觀察的，不評論不點讚自己也不發文章的，這樣“暗中觀察”的同學佔總使用者的比例是很大的。
2.資料模型簡單，訊息時間，訊息體，釋出人，訂閱人，很少會有需要關聯的場景
3.高併發，波峰波谷式訪問，Feed流系統屬於社交類系統，熱點來得快去得也快。
4.持久化可靠性儲存
每個人釋出的內容都是需要永久儲存且不能丟失的，儲存量會隨著時間的推移會越來越大。需要系統有很強的擴充套件性和可靠性。
5.訊息排序，HBase的rowKey按字典序排序正好適用於這個場景。比如rowkey可以設計成這樣
<userId><timestamp><feedId>這樣獲取某個使用者釋出的訊息時就可以指定時間範圍來scan，效能不錯的同時還能保證時間線正確。
總結
從上面feed資料的特性可以看出，HBase是適合做feed流系統的，實際生產中也確實有feed流應用是用HBase來做的儲存，
我這裡只是一個初步的討論，實際上還是有很多細節要考慮的，光靠HBase來實現肯定是遠遠不夠的，它也有很多不適用的地方，要靠開發者自己去判斷，
沒有最好的只有最合適的，希望對大家有幫助。
