HBase為什麼火？它適用於那些業務場景？
HBase應該是OLTP的一類，相比傳統OLTP資料庫來說，優點是數據量可以無限擴展，但是弱勢是沒法支持關係查詢，join，trasaction，然後在Real-Time應用領域也完全無法替代redis/memcached，那麼它到底適用於哪些應用場景呢？
做online服務風險很大，hbase的數據定位很繁瑣，還時常要做數據整理比如compaction，目前了解到的業務場景有：1. 搜索引擎系統的web存儲2. OLAP的cube存儲3. 電商的實時數據分析（比如淘寶的給店家看的實時數據，自營電商自己做數據分析就沒要求那麼實時）
還有其他什麼嗎？感覺場景還是很局限的，為什麼這麼火呢？-----------------------再補充幾個場景：1. 新浪微博的feed2. 淘寶的交易記錄或者購物車（其實BAT的場景還是蠻多的，仗不住不管什麼情況數據量都超大啊）3. 分散式系統的性能跟蹤數據存儲-----------------------我說成OLTP確實是不嚴密的，但這麼說是為了對應兩個專有名詞，OLTP和OLAP，便於表達。看了回答我又產生了兩個疑問：
1. 在什麼場景下需要在hbase上做MR啊？沒有Hadoop的前提下嗎？不是數據分析業務而突然有了個數據分析的需求？2. 用戶的生命周期數據，應該都是日誌形式的吧，那麼存儲的話Hadoop/HDFS不就可以了？ 如果說不能update是hbase的特點，那其他存儲也一樣可以不update這是存儲策略的選擇問題啊。如果像BAT這種幾億用戶的畫像數據，有需要經常查詢的話，是有必要存在hbase了。我覺得hbase是為了解決大數據量大範圍的查詢而設計的，大範圍，大數據量，兩個必要條件，二者缺其一都可以用其他工具不必採用hbase，而這兩個條件都存在的場景， 其實還是不多見的，不是一個普遍的常見的場景。
我覺得@向磊 的回答已經指出了重點。我補充一下。
HBase是根據谷歌的BigTable設計的。典型的應用場景就是不斷插入新的信息（谷歌的情況下就是互聯網上新生成的網頁），而不怎麼修改。比如現在Facebook的messenger就是用HBase實現的。
這裡要提到HBase是按行存儲的，所以特點就是插入（ingest）快。但是做分析的時候經常是要按列掃描（scan）的。比如算一個公司員工的平均工資。
Cloudera在推出新的列存儲引擎Kudu的時候討論過HDFS，HBase，和Kudu的應用場景。
糾正一個理解錯誤，hbase不是oltp，作為一個NoSQL，他頂多是olp, 沒有transaction。而且僅在rowkey上支持索引。在性能上不如memcached和redis，但是持久化存儲方面比內存NoSQL強啊。作為文檔型NoSQL在分散式存儲上比mongo做sharding和MapReduce分析方便多了啊。
當然最重要的原因是這樣，設想你要存儲用戶的地址和喜好，這當然可以做成結構化SQL。但是用戶把家搬到上海了，那麼以前在北京的地址要update覆蓋掉嗎，我們要計算分析用戶的整個人生周期的活動記錄和喜好，來推測他的行為，收入，知識層次，信用，道德水準之類的，當然他的相關歷史行為是不能被丟棄的。所以hbase可以很好的適應這樣的場景。
這只是簡單的舉個例子，mongo在小規模下也可以適應這種場景，不過隨著數據增長，會涉及到sharding和gridfs讓人痛苦的要命。當然以上場景也可以用其他工具，比如Cassandra，但是hbase和accumulo是跟hdfs以及mapreduce,Spark等結合的最好的，不但可以方便地存，更可以方便地算，這才是用hbase重要的原因吧。當然hbase不是銀彈，不能解決所有問題，所以才會有那麼多其他的NoSQL和SQL。
---------
補充你的補充提問的補充回答
1.當然會有數據分析的需求，放了N多數據，如果只是為了存著，成本太高了。hbase依賴於hdfs存儲，就我目前的認知範圍，還不知道怎麼在沒有hadoop的情況下安裝hbase。2.用戶生命周期數據為何要存成日誌，難道不需要獲取了嗎，每次網頁申請獲取一個用戶數據都要跑一遍MR計算嗎？另外，hbase是可以update的。只不過機制跟sql完全不同。3.事實上，hbase適合大數據量的查詢，但並不適合大範圍的查詢，他就是put，get kv對，海量數據下跑類似select一樣的檢索scan一遍全表？呵呵，you gonna die.HBase是一種NoSQL，通常被稱為Hadoop Database，它是開源並基於Google Big Table白皮書，HBase運行在HDFS之上，因此使它具有高度可擴展性，並支持Hadoop map-reduce程序設計模型。HBase有兩種訪問方式：通過行鍵進行隨機訪問；通過map-reduce離線或批訪問。
谷歌曾經面對過一個挑戰的問題：如何能在整個互聯網上提供實時的搜索結果？答案是它本質上需要將互聯網緩存，並重新定義在這樣龐大的緩存上快速查找的新方法。為了達到這個目的，定義如下技術：
谷歌文件系統GFS：可擴展分散式文件系統，用於大型的、分散式的、數據密集型的應用程序。
BigTable：分散式存儲系統，用於管理被設計成規模很大的結構化數據：來自數以千計商用伺服器的PB級別的數據。
MapReduce：一個程序模型，用於處理和生成大數據集的相關實現。
在谷歌發布這些技術的文檔之後, 不久以後我們就看到了它們的開源實現版本 ，就在2007年，Mike Cafarella發布了BigTable開源實現的代碼，他稱其為HBase，自此，HBase成為Apache的頂級項目，並運行在Facebook，Twitter，Adobe……僅舉幾個例子。
HBase不是一個關係型資料庫，它需要不同的方法定義你的數據模型，HBase實際上定義了一個四維數據模型，下面就是每一維度的定義：
行鍵：每行都有唯一的行鍵，行鍵沒有數據類型，它內部被認為是一個位元組數組。
列簇：數據在行中被組織成列簇，每行有相同的列簇，但是在行之間，相同的列簇不需要有相同的列修飾符。在引擎中，HBase將列簇存儲在它自己的數據文件中，所以，它們需要事先被定義，此外，改變列簇並不容易。
列修飾符：列簇定義真實的列，被稱之為列修飾符，你可以認為列修飾符就是列本身。
版本：每列都可以有一個可配置的版本數量，你可以通過列修飾符的制定版本獲取數據。
HBase Four-Dimensional Data Model
如圖1中所示，通過行鍵獲取一個指定的行，它由一個或多個列簇構成，每個列簇有一個或多個列修飾符（圖1中稱為列），每列又可以有一個或多個版本。為了獲取指定數據，你需要知道它的行鍵、列簇、列修飾符以及版本。當設計HBase數據模型時，對考慮數據是如何被獲取是十分有幫助的。你可以通過以下兩種方式獲得HBase數據：
通過他們的行鍵，或者一系列行鍵的表掃描。
使用map-reduce進行批操作
這種雙重獲取數據的方法使得HBase變得十分強大，典型地，在Hadoop中存儲數據意味著它對離線或批處理方式分析是有益的（尤其是批處理分析），但是，對實時獲取是不必要的。HBase通過key/value存儲來支持實時分析，以及通過map-reduce支持批處理分析。讓我們首先來看實時數據獲取，作為key/value存儲，key是行鍵，value是列簇的集合，如圖2所示。
HBase as a Key/Value Store
如你在圖2中看到的，key是我們所提到過的行鍵，value是列簇的集合。你可以通過key檢索到value，或者換句話說，你可以通過行鍵「得到」行，或者你能通過給定起始和終止行鍵檢索一系列行，這就是前面提到的表掃描。你不能實時的查詢一個列的值，這就引出了一個重要的話題：行鍵的設計。
有兩個原因令行鍵的設計十分重要：
表掃描是對行鍵的操作，所以，行鍵的設計控制著你能夠通過HBase執行的實時/直接獲取量。
當在生產環境中運行HBase時，它在HDFS上部運行，數據基於行鍵通過HDFS，如果你所有的行鍵都是以user-開頭，那麼很有可能你大部分數據都被分配一個節點上（違背了分散式數據的初衷），因此，你的行鍵應該是有足夠的差異性以便分散式地通過整個部署。
你定義行鍵的方式取決於你想怎樣存取那些行。如果你想以用戶為基礎存儲數據，那麼一個策略是利用位元組隊列在HBase中存儲行鍵，所以我們可以創建一個用戶ID的哈希（例如MD5或SHA-1），然後在哈希後面附上時間（long類型）。使用哈希有兩個重點：（1）是它能夠將value分散開，數據能夠分散式地通過簇，（2）是它確保key的長度是一致的，以更加容易在表掃描中使用。
講了足夠多的理論，下面部分向你展示如何搭建HBase環境，並如何通過命令行使用。
你可以從Apache網站下載HBase，HBase團隊推薦你在UNIX/Linux環境下安裝HBase，如果你想在Windows下運行，你需要先安裝Cygwin，並在這上運行HBase。當你下載完這些文件，解壓到硬碟上。此外，你還需要安裝Java環境，如果你還沒有，從Oracle網站下載Java環境。在環境配置中添加名為HBASE_HOME的變數，值為你解壓HBase文件的根目錄，隨後，執行bin文件夾下的start-hbase.sh腳本，它會在下面目錄輸出日誌文件：
$HBASE_HOME/logs/
你可以在瀏覽器中輸入下面URL測試是否安裝正確：
http://localhost:60010
如果安裝正確，你應該看到下面界面。
HBase Management Screen
讓我們開始用命令行操作HBase，在HBase bin目錄下執行下面命令：
./hbase shell
你應該看到如下類似的輸出：
1
2
3
4
5
6
7
HBase Shell; enter "help&
Type "exit&
Version 0.98.5-hadoop2, rUnknown, Mon Aug 4 23:58:06 PDT 2014
hbase(main):001:0&>
創建一個名為PageViews的表，並具有名為info的列簇：
1
2
3
4
5
hbase(main):002:0&> create "PageViews", "info"
0 row(s) in 5.3160 seconds
=&> Hbase::Table - PageViews
每張表至少要有一個列簇，因此我們創建了info，現在，看看我們的表，執行下面list命令：
1
2
3
4
5
6
7
8
9
hbase(main):002:0&> list
TABLE
PageViews
1 row(s) in 0.0350 seconds
=&> ["PageViews"]
如你所見，list命令返回一個名為PageViews的表，我們可以通過describe命令得到表的更多信息：
1
2
3
4
5
6
7
8
9
10
11
12
13
hbase(main):003:0&> describe "PageViews"
DESCRIPTION ENABLED
"PageViews", {NAME =&> "info", DATA_BLOCK_ENCODING =&> "NONE", BLOOMFILTER =&> "ROW",
REPLICATION_SCOPE =&> "0", VERSIONS =&> "1", COMPRESSION =&> "NONE true
", MIN_VERSIONS =&> "0", TTL =&> "FOREVER", KEEP_DELETED_CELLS =&> "false",
BLOCKSIZE =&> "65536", IN_MEMORY =&> "false", BLOCKCACHE =&> "true"}
1 row(s) in 0.0480 seconds
Describe命令返回表的詳細信息，包括列簇的列表，這裡我們創建的僅有一個：info，現在為表添加以下數據，下面命令是在info中添加新的行：
1
2
3
hbase(main):004:0> put #039;PageViews#039;, #039;rowkey1#039;, #039;info:page#039;, #039;/mypage#039;
0 row(s) in 0.0850 seconds
Put命令插入一條行鍵為rowkey1的新紀錄，指定在info下的page列，插入值為/mypage的記錄，我們隨後可以通過get命令通過行鍵rowkey1查詢到這條記錄：
1
2
3
4
5
6
7
hbase(main):005:0&> get "PageViews", "rowkey1"
COLUMN CELL
info:page timestamp=1410374788088, value=/mypage
1 row(s) in 0.0250 seconds
你可以看到列info：page，或者更多具體的列，其值為/mypage，並帶有時間戳表明該條記錄是什麼時候插入的。讓我們在做表掃描之前再添加一行：
1
2
3
hbase(main):006:0&> put "PageViews", "rowkey2", "info:page", "/myotherpage"
0 row(s) in 0.0050 seconds
現在我們有兩行記錄了，讓我們查詢出PageViews表的所有記錄：
1
2
3
4
5
6
7
8
9
hbase(main):007:0&> scan "PageViews"
ROW COLUMN+CELL
rowkey1 column=info:page, timestamp=1410374788088, value=/mypage
rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage
2 row(s) in 0.0350 seconds
如前面所提到的，我們不能查詢本身，但是我們可以對錶進行scan操作，如果你執行scan table命令，它會返回表中所有行，這很有可能不是你想要做的。你可以給出行的範圍來限制返回的結果，讓我們插入一帶有s開頭行鍵的新記錄：
1
hbase(main):012:0&> put "PageViews", "srowkey2", "info:page", "/myotherpage"
現在，如果我增加點限制，想查詢行鍵在r和s之間的記錄，可以使用如下結構：
1
2
3
4
5
6
7
8
9
hbase(main):014:0&> scan "PageViews", { STARTROW =&> "r", ENDROW =&> "s" }
ROW COLUMN+CELL
rowkey1 column=info:page, timestamp=1410374788088, value=/mypage
rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage
2 row(s) in 0.0080 seconds
這個scan返回了僅有s開頭的記錄，這個類比是基於全行鍵上的，所以rowkey1比r大，所有它被返回了。另外，scan的結果包含了所指範圍的STARTROW，但不包含ENDROW，注意，ENDROW不是必須指定的，如果我們執行相同查詢只給出了STARTROW，那麼我們會得到行鍵比r大的所有記錄。
1
2
3
4
5
6
7
8
9
10
11
hbase(main):013:0&> scan "PageViews", { STARTROW =&> "r" }
ROW COLUMN+CELL
rowkey1 column=info:page, timestamp=1410374788088, value=/mypage
rowkey2 column=info:page, timestamp=1410374823590, value=/myotherpage
srowkey2 column=info:page, timestamp=1410375975965, value=/myotherpage
3 row(s) in 0.0120 seconds
HBase
HBase是一個高可靠、高性能、面向列、可伸縮的分散式存儲系統，利用HBase技術可以在廉價PC上搭建起大規模結構化存儲集群。
HBase是Google Bigtable的開源實現，類似於Google Bigtable利用GFS作為其文件存儲系統，HBase利用Hadoop HDFS作為其文件存儲系統；Google運行MapRecue來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapRecue來處理HBase中的海量數據；Google Bigtable利用Chubby作為協同服務，HBase利用Zookeeper作為對應。
特性：
強一致性讀寫：HBase不是「Eventual Consistentcy（最終一致性）」數據存儲，這讓它很適合高速計數聚合類任務；
自動分片（Automatic sharding）：HBase表通過region分布在集群中，數據增長時，region會自動分割並重新分布；
RegionServer自動故障轉移
Hadoop/HDFS集成：HBase支持開箱即用HDFS作為它的分散式文件系統；
MapRecue：HBase通過MapRecue支持大並發處理；
Java客戶端API：HBase支持易於使用的Java API進行編程訪問;
Thrift/REST API：HBase也支持Thrift和Rest作為非Java前端訪問；
Block Cache和Bloom Filter：對於大容量查詢優化，HBase支持Block Cache和Bloom Filter;
運維管理：HBase支持JMX提供內置網頁用於運維。
HBase應用場景
HBase不適合所有場景。
首先，確信有足夠多數據，如果有上億或上千億行數據，HBase是很好的備選。如果只有上千或上百萬行，則用傳統的RDBMS可能是更好的選擇。因為所有數據如果只需要在一兩個節點進行存儲，會導致集群其他節點閑置。
其次，確信可以不依賴於RDBMS的額外特性。例如，列數據類型、第二索引、事務、高級查詢語言等
最後，確保有足夠的硬體。因為HDFS在小於5個數據節點時，基本上體現不出來它的優勢。
雖然HBase能在單獨的筆記本上運行良好，但這應僅當成是開發階段的配置 。
HBase的優點
列可以動態增加，並且列為空就不存儲數據，節省存儲空間；
HBase可以自動切分數據，使得數據存儲自動具有水平擴展功能；
HBase可以提供高並發讀寫操作的支持；
與Hadoop MapRecue相結合有利於數據分析；
容錯性；
版權免費；
非常靈活的模式設計（或者說沒有固定模式的限制）；
可以跟Hive集成，使用類SQL查詢；
自動故障轉移；
客戶端介面易於使用；
行級別原子性，即PUT操作一定是完全成功或者完全失敗。
HBase的缺點
不能支持條件查詢，只支持按照row key來查詢；
容易產生單點故障（在只使用一個HMaster的時候）；
不支持事務；
JOIN不是資料庫層支持的，而需要用MapRecue；
只能在主鍵上索引和排序；
沒有內置的身份和許可權認證；
HBase與Hadoop/HDFS的差異
HDFS是分散式文件系統，適合保存大文件。官方宣稱它並非普通用途的文件系統，不提供文件的個別記錄的快速查詢。另一方面，HBase基於HDFS，並能夠提供大表的記錄快速查詢和更新。HBase內部將數據放到索引好的「StoreFiles」存儲文件中，以便提供高速查詢，而存儲文件位於HDFS中。
HBase作為默認的大數據時代的存儲，基本解決以下三大類的場景：
推薦閱讀：