Hbase特點
1. 高速寫入：高速寫入，對讀取需求比較小。
2.大數據：分布式存儲，海量數據搞得定。不用擔心無限增長的數據。
3. 可靠：寫入的不是內存，是硬盤，高性能
4. 查詢簡單：不需要復雜查詢條件來查詢數據的應用，HBase只支持基于rowkey的查詢，對于HBase來說，單條記錄或者小范圍的查詢是可以接受的。
Hbase使用場景1：對象存儲
我們知道不少的頭條類、新聞類的的新聞、網頁、圖片存儲在HBase之中，一些病毒公司的病毒庫也是存儲在HBase之中。
Hbase使用場景2：時序數據
HBase之上有OpenTSDB模塊，可以滿足時序類場景的需求。
Hbase使用場景3：用戶畫像
特別是用戶的畫像，是一個比較大的稀疏矩陣，螞蟻的風控就是構建在HBase之上。
Hbase使用場景4：時空數據
主要是軌跡、氣象網格之類，滴滴打車的軌跡數據主要存在HBase之中，另外在技術所有大一點的數據量的車聯網企業(yè)，數據都是存在HBase之中。
Hbase使用場景5：CubeDB OLAP
Kylin一個cube分析工具，底層的數據就是存儲在HBase之中，不少客戶自己基于離線計算構建cube存儲在hbase之中，滿足在線報表查詢的需求。
Hbase使用場景5：消息/訂單
在電信領域、銀行領域，不少的訂單查詢底層的存儲，另外不少通信、消息同步的應用構建在HBase之上。聊天系統(tǒng)的日志存儲。Facebook的在線聊天，每天數據量近百億。哨兵監(jiān)控系統(tǒng)，云信歷史數據，日志歸檔數據等一系列重要應用底層都由HBase提供服務。
Hbase使用場景6：Feed
典型的應用就是xx朋友圈類似的應用。
使用案例
Mozilla: Moving Socorro to HBase
Facebook: Facebook’s New Real-Time Messaging System: HBase
http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html
Facebook和淘寶的總結：
摘自facebook的相關文檔
1 storing large amounts of data（100s of TBs）
存儲大量的數據（100s TB級數據）
2 need high write throughput
需要很高的寫吞吐量
3 need efficient random access (key lookups) within large data sets
在大規(guī)模數據集中進行很好性能的隨機訪問（按列）
4 need to scale gracefully with data
需要進行優(yōu)雅的數據擴展
5 for structured and semi-strured data
結構化和半結構化的數據
6 don‘t need full RDFS capabilites（cross row/cross table transactions,joins etc.）
不需要全部的 關系數據庫特性，例如交叉列、交叉表，事務，連接等等
來自淘寶的使用場景總結：
1 瞬間寫入量很大，數據庫不好支撐或需要很高成本支撐的場景。
2 數據需要長久保存，且量會持久增長到比較大的場景
3 HBase不適用與有join，多級索引，表關系復雜的數據模型
4 合理設計rowkey，非常重要
5 數據較好是可恢復的
6 生產環(huán)境關閉split，region數不要太多。
整理總結：
1大數據量 （100s TB級數據） 且有快速隨機訪問的需求。
例如淘寶的交易歷史記錄。數據量巨大無容置疑，面向普通用戶的請求必然要即時響應。
2 容量的優(yōu)雅擴展
大數據的驅使，動態(tài)擴展系統(tǒng)容量的必須的。例如：webPage DB。
3 業(yè)務場景簡單，不需要關系數據庫中很多特性（例如交叉列、交叉表，事務，連接等等）
4 優(yōu)化方面：合理設計rowkey。因為hbase的查詢用rowkey是較高效的，也幾乎的生產環(huán)境可行的方式。所以把你的查詢請求轉換為查詢rowkey的請求吧。
