由於沒有機會對Hadoop、Spark、HBase與Redis的各個特性進行測試，所以在網路上找到了這篇文章，說說Hadoop、Spark、HBase與Redis的適用性問題。

轉自 http://datainsight.blog.51cto.com/8987355/1426538

問題導讀：
1.你認為Hadoop適用什麼場景？
2.Spark適用於什麼場景？
3.HBase與 Redis各有什麼特點？

1. Hadoop Vs. Spark
Hadoop/MapReduce和Spark最適合的都是做離線型的資料分析，但Hadoop特別適合是單次分析的資料量“很大”的情景，而Spark則適用於資料量不是很大的情景。這兒所說的“很大”，是相對於整個叢集中的記憶體容量而言的，因為Spark是需要將資料HOLD在記憶體中的。一般的，1TB以下的資料量都不能算很大，而10TB以上的資料量都是算“很大”的。比如說，20個節點的一個叢集（這樣的叢集規模在大資料領域算是很小的了），每個節點64GB記憶體（不算很小，但也不能算大），共計1.28TB。讓這樣規模的一個叢集把500GB左右的資料HOLD在記憶體中還是很輕鬆的。這時候，用Spark的執行速度都會比Hadoop快，畢竟在MapReduce過程中，諸如spill等這些操作都是需要寫磁碟的。


這兒有2點需要提一下：
1）一般情況下，對於中小網際網路和企業級的大資料應用而言，單次分析的數量都不會“很大”，因此可以優先考慮使用Spark，特別是當Spark成熟了以後（Hadoop已經出到2.5了，而Spark才剛出1.0呢）。比如說，中國移動的一個省公司（在企業級，移動公司的資料量還是算相當大的），他們單次分析的數量一般也就幾百GB，連1TB都很少超過，更不用說超過10TB了，所以完全可以考慮用Spark逐步替代Hadoop。


2）業務通常認為Spark更適用於機器學習之類的“迭代式”應用，但這僅僅是“更”。一般地，對於中等規模的資料量，即便是不屬於“更適合”範疇的應用，Spark也能快2～5倍左右。我自己做過一個對比測試，80GB的壓縮資料（解壓後超過200GB），10個節點的叢集規模，跑類似“sum+group-by”的應用，MapReduce花了5分鐘，而spark只需要2分鐘。


2. HBase
對於HBase，經常聽到的一個說法是：HBase只適合於支撐離線分析型應用，特別是做為MapReduce任務的後臺資料來源。持這個觀點不少，甚至在國內一個響噹噹的電信裝置提供商中，HBase也是被歸入資料分析產品線的，並明確不建議將HBase用於線上應用。可實際情況真是這樣嗎？讓我們先看看它的幾大案例：Facebook的訊息類應用，包括Messages、Chats、Emails和SMS系統，用的都是HBase；淘寶的WEB版阿里旺旺，後臺是HBase；小米的米聊用的也是HBase；移動某省公司的手機詳單查詢系統，去年也由原先的Oracle改成了一個32節點的HBase叢集——兄弟們，這些可都是知名大公司的關鍵應用啊，夠能說明問題了吧。


實際上從HBase的技術特點上看，它特別適用於簡單資料寫入（如“訊息類”應用）和海量、結構簡單資料的查詢（如“詳單類”應用）。在上面提到的4個HBase的應用中，Facebook訊息、WEB版阿里旺旺、米聊等均屬於以資料寫入為主的訊息類應用，而移動公司的手機詳單查詢系統則屬於以資料查詢為主的詳單類應用。


HBase的另一個用途是作為MapReduce的後臺資料來源，以支撐離線分析型應用。這個固然可以，但其效能如何則是值得商榷的。比如說，superlxw1234同學通過實驗對比了“Hive over HBase”和“Hive over HDFS”後驚奇的發現[2]，除了在使用rowkey過濾時，基於HBase的效能上略好於直接基於HDFS外，在使用全表掃描和根據value過濾時，直接基於HDFS方案的效能均比HBase好的多——這真是一個謬論啊！不過對於這個問題，我個人感覺從原理上看，當使用rowkey過濾時，過濾程度越高，基於HBase方案的效能必然越好；而直接基於HDFS方案的效能則跟過濾程度沒有關係。


3. HBase Vs. Redis
HBase和Redis在功能上比較類似，比如它們都屬於NoSQL級別的資料庫，都支援資料分片等，關鍵的不同點實際上只有一個：對HBase而言，一旦資料被成功寫入，從原理上看是不會丟的，因為它有Writa-ahead Log（功能上類似於Oracle REDO）；而對於Redis而言，即便是配置了主從複製功能，在Failover時完全存在發生資料丟失的可能（如果不配置主從複製，那麼丟失的資料會更多），因為它第一沒有類似REDO的重做日誌，第二採用了非同步複製的方式。


關鍵還在於效能。通常，Redis的讀寫效能在100,000 ops/s左右，時延一般為10～70微妙左右[4][5]；而HBase的單機讀寫效能一般不會超過1,000ops/s，時延則在1～5毫秒之間[3]。忽略其中的硬體因素，100倍的讀寫效能差異已經足夠說明問題了。順便提一下的是，Redis在Tuning上還是比較講究的，比如說，當使用numactl（或taskset）將Redis程序繫結到同一個CPU的不同CORE上時，它的效能一般可以提升30%左右[6]，在一些特別的場景下甚至可以有近一倍的提升。


從上述的功能和效能比較上，我們就很容易的總結出HBase和Redis各自的適用範疇：
1）當用來支撐簡單“訊息類”應用時，如果資料失敗是不能容忍的，那就用只能用HBase；如果需要一個高效能的環境，而且能夠容忍一定的資料丟失，那完全可以考慮使用Redis。


2）Redis很適合用來做快取，但除此之外，它實際上還可以在一些“讀寫分離”的場景下作為“讀庫”來用，特別是用來存放Hadoop或Spark的分析結果。
有不少人認為Redis只適合用作“快取”，根據我的理解，這主要是基於以下2個原因：第一，Redis在設計上存在資料丟失的可能性；第二，當無法將資料全部HOLD在記憶體中時，其讀寫效能會急劇下降到每秒幾百ops[6]，這一現象類似於Google開源的Leveldb[7]，Facebook的RocksDB團隊的通過Performance Benchmark也證實了這一現象的存在[8]。但是，當用作“讀庫”或用於支撐允許資料丟失的“訊息類”應用時，這兩個問題實際上都沒有關係。

[1] Hadoop雖然強大，但不是萬能的。http://database.51cto.com/art/201402/429789.htm
[2] Hiveover HBase和Hive over HDFS效能比較分析。http://superlxw1234.iteye.com/blog/2008274
[3] Hbase效能測試。http://www.cnblogs.com/colorfulkoala/archive/2013/05/13/3076139.html
[4] 網際網路利器 Redis記憶體資料庫效能評測。http://tech.it168.com/a2012/1011/1406/000001406978_all.shtml
[5] Howfast is Redis?http://redis.io/topics/benchmarks
[6] Redis千萬級的資料量的效能測試。http://www.cnblogs.com/lovecindywang/archive/2011/03/03/1969633.html
[7] Leveldb.https://code.google.com/p/leveldb/
[8] RocksDBbenchmark results. https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks