最近在網上又看到有關于適用性的討論。想想今年開始由互聯網巨頭走向中小互聯網和傳統行業，估計不少人都在考慮各種“紛繁復雜”的的適用性的問題。這兒我就結合我這幾年在Hadoop等大數據方向的工作經驗，與大家討論一下Hadoop、Spark、HBase及Redis等幾個主流大數據技術的使用場景(首先聲明一點，本文中所指的Hadoop，是很“狹義”的Hadoop，即在HDFS上直接跑MapReduce的技術，下同)。

我這幾年實際研究和使用過大數據(包含NoSQL)技術包括Hadoop、Spark、HBase、Redis和MongoDB等，這些技術的共同特點是不適合用于支撐事務型應用，特別是與“錢”相關的應用，如“訂購關系”、“超市交易”等，這些場合到目前為止還是Oracle等傳統關系型數據庫的天下。

1. Vs.

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只適合于支撐離線分析型應用，特別是做為MapReduce任務的后臺數據源。持這個觀點不少，甚至在國內一個響當當的電信設備提供商中，HBase也是被歸入數據分析產品線的，并明確不建議將HBase用于在線應用?？蓪嶋H情況真是這樣嗎?讓我們先看看它的幾大案例：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”后驚奇的發現，除了在使用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微妙左右;而HBase的單機讀寫性能一般不會超過1,000ops/s，時延則在1～5毫秒之間。忽略其中的硬件因素，100倍的讀寫性能差異已經足夠說明問題了。順便提一下的是，Redis在Tuning上還是比較講究的，比如說，當使用numactl(或taskset)將Redis進程綁定到同一個CPU的不同CORE上時，它的性能一般可以提升30%左右，在一些特別的場景下甚至可以有近一倍的提升。

從上述的功能和性能比較上，我們就很容易的總結出HBase和Redis各自的適用范疇：

1)當用來支撐簡單“消息類”應用時，如果數據失敗是不能容忍的，那就用只能用HBase;如果需要一個高性能的環境，而且能夠容忍一定的數據丟失，那完全可以考慮使用Redis。

2)Redis很適合用來做緩存，但除此之外，它實際上還可以在一些“讀寫分離”的場景下作為“讀庫”來用，特別是用來存放或的分析結果。

有不少人認為Redis只適合用作“緩存”，根據我的理解，這主要是基于以下2個原因：第一，Redis在設計上存在數據丟失的可能性;第二，當無法將數據全部HOLD在內存中時，其讀寫性能會急劇下降到每秒幾百ops，這一現象類似于Google開源的Leveldb，Facebook的RocksDB團隊的通過Performance Benchmark也證實了這一現象的存在。但是，當用作“讀庫”或用于支撐允許數據丟失的“消息類”應用時，這兩個問題實際上都沒有關系。