最近在網(wǎng)上又看到有關(guān)于Hadoop適用性的討論[1]氧秘。想想今年大數(shù)據(jù)技術(shù)開始由互聯(lián)網(wǎng)巨頭走向中小互聯(lián)網(wǎng)和傳統(tǒng)行業(yè)年鸳，估計(jì)不少人都在考慮各種“紛繁復(fù)雜”的大數(shù)據(jù)技術(shù)的適用性的問題。這兒我就結(jié)合我這幾年在Hadoop等大數(shù)據(jù)方向的工作經(jīng)驗(yàn)丸相，與大家討論一下Hadoop搔确、Spark、HBase及Redis等幾個(gè)主流大數(shù)據(jù)技術(shù)的使用場景（首先聲明一點(diǎn)灭忠，本文中所指的Hadoop膳算，是很“狹義”的Hadoop，即在HDFS上直接跑MapReduce的技術(shù)更舞，下同）畦幢。
我這幾年實(shí)際研究和使用過大數(shù)據(jù)（包含NoSQL）技術(shù)包括Hadoop、Spark缆蝉、HBase宇葱、Redis和MongoDB等，這些技術(shù)的共同特點(diǎn)是不適合用于支撐事務(wù)型應(yīng)用刊头，特別是與“錢”相關(guān)的應(yīng)用黍瞧，如“訂購關(guān)系”、“超市交易”等原杂，這些場合到目前為止還是Oracle等傳統(tǒng)關(guān)系型數(shù)據(jù)庫的天下印颤。
- Hadoop Vs. Spark
Hadoop/MapReduce和Spark最適合的都是做離線型的數(shù)據(jù)分析，但Hadoop特別適合是單次分析的數(shù)據(jù)量“很大”的情景穿肄，而Spark則適用于數(shù)據(jù)量不是很大的情景年局。這兒所說的“很大”际看，是相對(duì)于整個(gè)集群中的內(nèi)存容量而言的，因?yàn)镾park是需要將數(shù)據(jù)HOLD在內(nèi)存中的矢否。一般的仲闽，1TB以下的數(shù)據(jù)量都不能算很大，而10TB以上的數(shù)據(jù)量都是算“很大”的僵朗。比如說赖欣，20個(gè)節(jié)點(diǎn)的一個(gè)集群（這樣的集群規(guī)模在大數(shù)據(jù)領(lǐng)域算是很小的了），每個(gè)節(jié)點(diǎn)64GB內(nèi)存（不算很小验庙，但也不能算大）顶吮，共計(jì)1.28TB。讓這樣規(guī)模的一個(gè)集群把500GB左右的數(shù)據(jù)HOLD在內(nèi)存中還是很輕松的粪薛。這時(shí)候悴了，用Spark的執(zhí)行速度都會(huì)比Hadoop快，畢竟在MapReduce過程中汗菜，諸如spill等這些操作都是需要寫磁盤的让禀。
這兒有2點(diǎn)需要提一下：1）一般情況下，對(duì)于中小互聯(lián)網(wǎng)和企業(yè)級(jí)的大數(shù)據(jù)應(yīng)用而言陨界，單次分析的數(shù)量都不會(huì)“很大”巡揍，因此可以優(yōu)先考慮使用Spark，特別是當(dāng)Spark成熟了以后（Hadoop已經(jīng)出到2.5了菌瘪，而Spark才剛出1.0呢）腮敌。比如說，中國移動(dòng)的一個(gè)省公司（在企業(yè)級(jí)俏扩，移動(dòng)公司的數(shù)據(jù)量還是算相當(dāng)大的）糜工，他們單次分析的數(shù)量一般也就幾百GB，連1TB都很少超過录淡，更不用說超過10TB了捌木，所以完全可以考慮用Spark逐步替代Hadoop。2）業(yè)務(wù)通常認(rèn)為Spark更適用于機(jī)器學(xué)習(xí)之類的“迭代式”應(yīng)用嫉戚，但這僅僅是“更”刨裆。一般地，對(duì)于中等規(guī)模的數(shù)據(jù)量彬檀，即便是不屬于“更適合”范疇的應(yīng)用帆啃，Spark也能快2～5倍左右。我自己做過一個(gè)對(duì)比測試窍帝，80GB的壓縮數(shù)據(jù)（解壓后超過200GB）努潘，10個(gè)節(jié)點(diǎn)的集群規(guī)模，跑類似“sum+group-by”的應(yīng)用，MapReduce花了5分鐘疯坤，而spark只需要2分鐘报慕。 - HBase
對(duì)于HBase，經(jīng)常聽到的一個(gè)說法是：HBase只適合于支撐離線分析型應(yīng)用贴膘，特別是做為MapReduce任務(wù)的后臺(tái)數(shù)據(jù)源卖子。持這個(gè)觀點(diǎn)不少略号，甚至在國內(nèi)一個(gè)響當(dāng)當(dāng)?shù)碾娦旁O(shè)備提供商中刑峡，HBase也是被歸入數(shù)據(jù)分析產(chǎn)品線的，并明確不建議將HBase用于在線應(yīng)用玄柠⊥幻危可實(shí)際情況真是這樣嗎？讓我們先看看它的幾大案例：Facebook的消息類應(yīng)用羽利，包括Messages宫患、Chats、Emails和SMS系統(tǒng)这弧，用的都是HBase娃闲；淘寶的WEB版阿里旺旺，后臺(tái)是HBase匾浪；小米的米聊用的也是HBase皇帮；移動(dòng)某省公司的手機(jī)詳單查詢系統(tǒng)，去年也由原先的Oracle改成了一個(gè)32節(jié)點(diǎn)的HBase集群——兄弟們蛋辈，這些可都是知名大公司的關(guān)鍵應(yīng)用啊属拾，夠能說明問題了吧。
實(shí)際上從HBase的技術(shù)特點(diǎn)上看冷溶，它特別適用于簡單數(shù)據(jù)寫入（如“消息類”應(yīng)用）和海量渐白、結(jié)構(gòu)簡單數(shù)據(jù)的查詢（如“詳單類”應(yīng)用）。在上面提到的4個(gè)HBase的應(yīng)用中逞频，F(xiàn)acebook消息纯衍、WEB版阿里旺旺、米聊等均屬于以數(shù)據(jù)寫入為主的消息類應(yīng)用苗胀，而移動(dòng)公司的手機(jī)詳單查詢系統(tǒng)則屬于以數(shù)據(jù)查詢?yōu)橹鞯脑攩晤悜?yīng)用襟诸。
HBase的另一個(gè)用途是作為MapReduce的后臺(tái)數(shù)據(jù)源，以支撐離線分析型應(yīng)用柒巫。這個(gè)固然可以励堡，但其性能如何則是值得商榷的。比如說堡掏，superlxw1234同學(xué)通過實(shí)驗(yàn)對(duì)比了“Hive over HBase”和“Hive over HDFS”后驚奇的發(fā)現(xiàn)[2]应结，除了在使用rowkey過濾時(shí)，基于HBase的性能上略好于直接基于HDFS外，在使用全表掃描和根據(jù)value過濾時(shí)鹅龄，直接基于HDFS方案的性能均比HBase好的多——這真是一個(gè)謬論翱健！不過對(duì)于這個(gè)問題扮休，我個(gè)人感覺從原理上看迎卤，當(dāng)使用rowkey過濾時(shí)，過濾程度越高玷坠，基于HBase方案的性能必然越好蜗搔；而直接基于HDFS方案的性能則跟過濾程度沒有關(guān)系。 - HBase Vs. Redis
HBase和Redis在功能上比較類似八堡，比如它們都屬于NoSQL級(jí)別的數(shù)據(jù)庫樟凄，都支持?jǐn)?shù)據(jù)分片等，關(guān)鍵的不同點(diǎn)實(shí)際上只有一個(gè)：對(duì)HBase而言兄渺，一旦數(shù)據(jù)被成功寫入缝龄，從原理上看是不會(huì)丟的，因?yàn)樗蠾rita-ahead Log（功能上類似于Oracle REDO）挂谍；而對(duì)于Redis而言叔壤，即便是配置了主從復(fù)制功能，在Failover時(shí)完全存在發(fā)生數(shù)據(jù)丟失的可能（如果不配置主從復(fù)制口叙，那么丟失的數(shù)據(jù)會(huì)更多）炼绘，因?yàn)樗谝粵]有類似REDO的重做日志，第二采用了異步復(fù)制的方式庐扫。
關(guān)鍵還在于性能饭望。通常，Redis的讀寫性能在100,000 ops/s左右形庭，時(shí)延一般為10～70微妙左右[4][5]铅辞；而HBase的單機(jī)讀寫性能一般不會(huì)超過1,000ops/s，時(shí)延則在1～5毫秒之間[3]萨醒。忽略其中的硬件因素斟珊，100倍的讀寫性能差異已經(jīng)足夠說明問題了。順便提一下的是富纸，Redis在Tuning上還是比較講究的囤踩，比如說，當(dāng)使用numactl（或taskset）將Redis進(jìn)程綁定到同一個(gè)CPU的不同CORE上時(shí)晓褪，它的性能一般可以提升30%左右[6]堵漱，在一些特別的場景下甚至可以有近一倍的提升。
從上述的功能和性能比較上涣仿，我們就很容易的總結(jié)出HBase和Redis各自的適用范疇：
1）當(dāng)用來支撐簡單“消息類”應(yīng)用時(shí)勤庐，如果數(shù)據(jù)失敗是不能容忍的示惊，那就用只能用HBase；如果需要一個(gè)高性能的環(huán)境愉镰，而且能夠容忍一定的數(shù)據(jù)丟失米罚，那完全可以考慮使用Redis。
2）Redis很適合用來做緩存丈探，但除此之外录择，它實(shí)際上還可以在一些“讀寫分離”的場景下作為“讀庫”來用，特別是用來存放Hadoop或Spark的分析結(jié)果碗降。
有不少人認(rèn)為Redis只適合用作“緩存”隘竭，根據(jù)我的理解，這主要是基于以下2個(gè)原因：第一遗锣，Redis在設(shè)計(jì)上存在數(shù)據(jù)丟失的可能性货裹；第二，當(dāng)無法將數(shù)據(jù)全部HOLD在內(nèi)存中時(shí)精偿，其讀寫性能會(huì)急劇下降到每秒幾百ops[6]，這一現(xiàn)象類似于Google開源的Leveldb[7]赋兵，F(xiàn)acebook的RocksDB團(tuán)隊(duì)的通過Performance Benchmark也證實(shí)了這一現(xiàn)象的存在[8]笔咽。但是，當(dāng)用作“讀庫”或用于支撐允許數(shù)據(jù)丟失的“消息類”應(yīng)用時(shí)霹期，這兩個(gè)問題實(shí)際上都沒有關(guān)系叶组。
[1] Hadoop雖然強(qiáng)大，但不是萬能的历造。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] 互聯(lián)網(wǎng)利器 Redis內(nèi)存數(shù)據(jù)庫性能評(píng)測吭产。http://tech.it168.com/a2012/1011/1406/000001406978_all.shtml
[5] Howfast is Redis?http://redis.io/topics/benchmarks
[6] Redis千萬級(jí)的數(shù)據(jù)量的性能測試侣监。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
