MapReduce和并行數(shù)據(jù)庫(kù):朋友還是敵人？

在2010年1月的ACM上，有兩篇文章非常吸引人注意。一篇文章是Google的Jeffrey Dean、Sanjay Ghemawat發(fā)表的標(biāo)題為《MapReduce:一個(gè)靈活的數(shù)據(jù)庫(kù)處理工具》，另一篇文章是Michael Stonebraker、Daniel Abadi、David J. DeWitt、Sam Madden、Erik Paulson、Andrew Pavlo、Alexander、Rasin等人發(fā)表的《MapReduce和并行數(shù)據(jù)庫(kù)：是朋友還是敵人?》。這兩篇文章讓我想起去年初Michael Stonebraker等人就MapReduce發(fā)表的一些評(píng)論而導(dǎo)致了一次MapReduce和數(shù)據(jù)庫(kù)系統(tǒng)的大辯論。那篇文章的標(biāo)題是《MapReduce：一個(gè)巨大的倒退》。這次辯論雙方則準(zhǔn)備了豐富的實(shí)踐和實(shí)驗(yàn)案例。看上去更加有趣也更加有說(shuō)服力。

　　以下“正方”代表堅(jiān)持并行數(shù)據(jù)庫(kù)解決方案的Andrew Pavlo、 Michael Stonebraker等，而反方則是Google的MapReduce(下文簡(jiǎn)稱MR)的擁躉Jeffrey Dean、Sanjay Ghemawat等。

　　正方拋出觀點(diǎn)

　　2009年Andrew Pavlo等人發(fā)表了一篇標(biāo)題為《大規(guī)模數(shù)據(jù)分析的方法對(duì)比》的文章，里面對(duì)比了數(shù)據(jù)庫(kù)和MR兩種大規(guī)模數(shù)據(jù)分析方法的對(duì)比。通過(guò)對(duì)比流行的MR軟件Hadoop和一種并行數(shù)據(jù)庫(kù)之間的架設(shè)、使用和性能等方面的異同，指出MR并不是解決大規(guī)模數(shù)據(jù)分析的好方法，其在性能、易用性等方面有諸多問(wèn)題：

　　一、MR沒(méi)法用索引，總是對(duì)數(shù)據(jù)進(jìn)行完全掃描;

　　二、MR 輸入和輸出，總是文件系統(tǒng)中的簡(jiǎn)單文件;

　　三、MR需要使用不高效的文本數(shù)據(jù)格式。

　　反方接招

　　對(duì)于正方第一個(gè)觀點(diǎn)，反方如此應(yīng)對(duì)：“錯(cuò)了!MR的輸入本身可以是數(shù)據(jù)庫(kù)的輸出，所以，我們是可以用索引的。另外一個(gè)例子是MR從BigTable里面讀取數(shù)據(jù)，如果數(shù)據(jù)落在一個(gè)行范疇里面，當(dāng)然是可以用索引的。而且，在很多需要處理的數(shù)據(jù)里頭，比如Web Server的日志，經(jīng)過(guò)輪轉(zhuǎn)之后天然就有索引(文件名包含時(shí)間戳)。”

　　對(duì)于第二個(gè)觀點(diǎn)，反方認(rèn)為：“現(xiàn)存的很多MR系統(tǒng)，本身就是一個(gè)異構(gòu)環(huán)境，用戶的數(shù)據(jù)可能存儲(chǔ)在關(guān)系數(shù)據(jù)庫(kù)里頭，而其處理結(jié)果可能會(huì)記錄在文件系統(tǒng)里頭。而且，這樣的環(huán)境可能會(huì)進(jìn)化，用戶的數(shù)據(jù)會(huì)遷移到新的系統(tǒng)里。而MR可以非常便利地在這些環(huán)境上運(yùn)行。更進(jìn)一步，用戶可以擴(kuò)展這些存儲(chǔ)，比如分布文件系統(tǒng)、數(shù)據(jù)庫(kù)查詢結(jié)果，存儲(chǔ)在BigTable里面的數(shù)據(jù)，結(jié)構(gòu)化的數(shù)據(jù)(B-tree文件等)。對(duì)于這些場(chǎng)合，單個(gè)MR處理就可以很容易地捏合它們。”

　　對(duì)于第三個(gè)觀點(diǎn)，反方認(rèn)為：“這點(diǎn)的確很精辟。很到位，不過(guò)這個(gè)因素是取決于具體的實(shí)現(xiàn)的，比如在Google的MR實(shí)現(xiàn)里，有個(gè)Protocol Buffer層，可以對(duì)輸入的數(shù)據(jù)進(jìn)行格式定義，因此就可以直接適用二進(jìn)制類型，而不用有額外的格式轉(zhuǎn)換的開(kāi)銷，在我們的測(cè)試?yán)铮瓉?lái)要花1731ns的一個(gè)格式分析，用Protocol Buffer預(yù)定義之后，只要20幾ns。所以，如果實(shí)現(xiàn)得足夠好，我們認(rèn)為MR系統(tǒng)不會(huì)只能處理文本格式的數(shù)據(jù)，而是可以處理二進(jìn)制數(shù)據(jù)，因此效率還可以極大提升。”除了這些之外，反方還拋出了幾塊大磚頭，等著正方接招：

　　MR與存儲(chǔ)系統(tǒng)無(wú)關(guān)，而且可以不用把數(shù)據(jù)裝載到數(shù)據(jù)庫(kù)就直接處理之，在很多場(chǎng)合下，在數(shù)據(jù)庫(kù)系統(tǒng)把數(shù)據(jù)裝載到數(shù)據(jù)庫(kù)里頭并且完成一次分析所花的時(shí)間，用MR的方式都能完成50次分析運(yùn)算了。

　　用MR可以表現(xiàn)更復(fù)雜的數(shù)據(jù)變換規(guī)則，很多反方的意見(jiàn)都是實(shí)現(xiàn)相關(guān)的，是針對(duì)一些不好的MR的實(shí)現(xiàn)做出來(lái)的，因此站不住腳。

　　反方的最有力的證據(jù)就是，在Google里頭跑得很好的一萬(wàn)多各種MR應(yīng)用，從網(wǎng)頁(yè)分析到索引建立，從日志分析到網(wǎng)圖計(jì)算等等。

　　正方的回應(yīng)

　　作為正方，Michael Stonebraker 教授等人在同一期雜志上發(fā)表了另外一篇文章，很有趣的是剛好排在反方的文章之前。這篇文章以批評(píng)與自我批評(píng)的方式提出了若干有趣的觀點(diǎn)，其中有些剛好是對(duì)反方的一個(gè)回應(yīng)：

　　MR系統(tǒng)可以用于(注意：不是勝出)下列場(chǎng)合：

　　ETL類的應(yīng)用：從多個(gè)不同的源讀取日志信息;分析以及清理日志數(shù)據(jù);執(zhí)行復(fù)雜的變換，比如“會(huì)話轉(zhuǎn)換”;決定存儲(chǔ)什么樣的屬性以及把信息裝載到DBMS或者其他存儲(chǔ)引擎中;

　　復(fù)雜分析應(yīng)用：這種挖掘類型的應(yīng)用需要對(duì)數(shù)據(jù)進(jìn)行多步驟的計(jì)算和處理，通常一個(gè)程序的輸出會(huì)是另外一個(gè)程序的輸入，因此很難用單個(gè)SQL語(yǔ)句來(lái)表示，這種應(yīng)用場(chǎng)合下，MR是很好的候選方案;

　　半結(jié)構(gòu)化數(shù)據(jù)：因?yàn)镸R不需要對(duì)數(shù)據(jù)的存儲(chǔ)進(jìn)行格式定義，因此MR比較適合處理半結(jié)構(gòu)化數(shù)據(jù)，這些數(shù)據(jù)通常都是一些鍵值對(duì)。這些場(chǎng)合下，MR非常適合做ETL的事情，如果并行數(shù)據(jù)庫(kù)選用了面向列的存儲(chǔ)方案，并且查詢大多是分析性的查詢，那么數(shù)據(jù)庫(kù)方案依然是更好些的選擇(正方有試驗(yàn)結(jié)果支撐);

　　快速實(shí)施的系統(tǒng)：并行數(shù)據(jù)庫(kù)最大的缺點(diǎn)就是架設(shè)和調(diào)優(yōu)難度要比MR大得多，雖然一旦架設(shè)、調(diào)優(yōu)完畢，并行數(shù)據(jù)庫(kù)系統(tǒng)表現(xiàn)出遠(yuǎn)勝M(fèi)R的性能和特性，但對(duì)大多數(shù)急于上手的入門級(jí)用戶來(lái)說(shuō)，并行數(shù)據(jù)庫(kù)系統(tǒng)的學(xué)習(xí)門檻顯然要高得多。最后就是成本，雖然并行數(shù)據(jù)庫(kù)在性能和應(yīng)用編寫簡(jiǎn)易性方面明顯勝于MR系統(tǒng)，但現(xiàn)實(shí)世界里確實(shí)還缺乏完善和健壯的低成本開(kāi)源解決方案，這點(diǎn)是MR最大的優(yōu)點(diǎn)。數(shù)據(jù)庫(kù)社區(qū)顯然在這個(gè)方面輸了一陣。

　　正方認(rèn)為，把適合于數(shù)據(jù)庫(kù)的工作交給MR去做結(jié)果其實(shí)并不好。在正方的試驗(yàn)里，證實(shí)了MR更加適用于做數(shù)據(jù)轉(zhuǎn)換和裝載的(ETL)工作，在這些場(chǎng)合，MR可以成為并行數(shù)據(jù)庫(kù)的良好補(bǔ)充，而不是替代品。為了證明上述論點(diǎn)，正方做了一些有趣的試驗(yàn)，試驗(yàn)對(duì)比的雙方是并行數(shù)據(jù)庫(kù)集群和Hadoop集群，試驗(yàn)的主要內(nèi)容有：

　　Grep任務(wù)：兩個(gè)系統(tǒng)都對(duì)分布在100個(gè)節(jié)點(diǎn)上的1TB數(shù)據(jù)進(jìn)行無(wú)法使用排序和索引的Grep處理，按說(shuō)應(yīng)該是面向更低層數(shù)據(jù)接口的Hadoop勝出，結(jié)果卻出乎人們的意料，是并行數(shù)據(jù)庫(kù)快了兩倍左右。

　　Web日志分析：兩個(gè)系統(tǒng)都對(duì)分布在100個(gè)節(jié)點(diǎn)上的2TB數(shù)據(jù)進(jìn)行類似GROUP BY的操作，對(duì)每個(gè)來(lái)源IP的點(diǎn)擊和計(jì)費(fèi)記錄進(jìn)行統(tǒng)計(jì)運(yùn)算，這也是一個(gè)對(duì)所有數(shù)據(jù)進(jìn)行掃描的操作，沒(méi)有辦法使用排序和索引。所以，直覺(jué)認(rèn)為直接操作數(shù)據(jù)文件、更低層的Hadoop應(yīng)該勝出，結(jié)果依然讓人大跌眼鏡，并行數(shù)據(jù)庫(kù)勝出面甚至比Grep任務(wù)還要大。

　　連接(Join)任務(wù)的性能：把上面測(cè)試的用戶訪問(wèn)日志和另外一個(gè)包含18M URL的100GB的PageRank表連接起來(lái)。這個(gè)連接有兩個(gè)子任務(wù)，分別對(duì)兩個(gè)數(shù)據(jù)集進(jìn)行復(fù)雜的計(jì)算。第一個(gè)子任務(wù)連接在一個(gè)特定用戶數(shù)據(jù)范圍內(nèi)找出收入最高的IP地址，找到后再由第二個(gè)子任務(wù)連接計(jì)算這個(gè)范圍內(nèi)被訪問(wèn)頁(yè)面的平均PageRank。數(shù)據(jù)庫(kù)對(duì)付這種設(shè)計(jì)復(fù)雜連接的分析性查詢是非常在行的。最后的結(jié)果是并行數(shù)據(jù)庫(kù)比Hadoop快了21~36倍。

　　針對(duì)上面的結(jié)果，正方做了一些分析，認(rèn)為這些差距的來(lái)源主要來(lái)自于具體實(shí)現(xiàn)，而非并行數(shù)據(jù)庫(kù)模型和MR模型之間的差異。比如，MR可以使用并行數(shù)據(jù)庫(kù)為低層的存儲(chǔ)，所以所有分析都針對(duì)現(xiàn)實(shí)中兩種模式的具體實(shí)現(xiàn)。正方分析了導(dǎo)致差距的幾個(gè)實(shí)現(xiàn)相關(guān)的架構(gòu)原因：

　　數(shù)據(jù)解析。Hadoop需要用戶代碼來(lái)對(duì)輸入的文本數(shù)據(jù)進(jìn)行解析，然后再加以計(jì)算，而這個(gè)解析是每個(gè)Map和每個(gè)Reduce過(guò)程都要進(jìn)行的，相比之下，并行數(shù)據(jù)庫(kù)系統(tǒng)只在裝載數(shù)據(jù)的時(shí)候解析一次數(shù)據(jù)，中間計(jì)算的開(kāi)銷大大降低。

　　數(shù)據(jù)壓縮。并行數(shù)據(jù)庫(kù)系統(tǒng)使用數(shù)據(jù)壓縮后，性能顯著提升，而MR系統(tǒng)卻不能，甚至倒退，在反方的試驗(yàn)中，也沒(méi)有使用壓縮，這方面讓人感到奇怪，分析出來(lái)的可能原因是商業(yè)數(shù)據(jù)庫(kù)系統(tǒng)對(duì)壓縮的調(diào)優(yōu)做得比較好，很多壓縮算法，比如gzip，未經(jīng)調(diào)優(yōu)的話，在現(xiàn)代的CPU上，甚至都不能提供什么優(yōu)勢(shì)。

　　管道化。現(xiàn)代數(shù)據(jù)庫(kù)系統(tǒng)基本上都是先生成一個(gè)查詢規(guī)劃，然后在執(zhí)行的時(shí)候把計(jì)算分發(fā)到相應(yīng)節(jié)點(diǎn)上。在該計(jì)劃里一個(gè)操作符必須向下一個(gè)操作符發(fā)送數(shù)據(jù)，不管下一個(gè)操作符是否在同節(jié)點(diǎn)上，因此，合格數(shù)據(jù)是由第一個(gè)操作符“推送”給第二個(gè)操作符的。這就構(gòu)成了良好的從生產(chǎn)者到消費(fèi)者的流水線作業(yè)。中間狀態(tài)的數(shù)據(jù)不會(huì)寫到磁盤上，這種運(yùn)行時(shí)的“背壓”會(huì)在生產(chǎn)者把消費(fèi)者整崩潰之前把生產(chǎn)者停下來(lái)。這種流水線方式和MR的實(shí)現(xiàn)不同，MR是把中間狀態(tài)寫到一個(gè)本地的數(shù)據(jù)結(jié)構(gòu)中，然后由消費(fèi)者“拖取”。這種本地?cái)?shù)據(jù)結(jié)構(gòu)通常是相當(dāng)龐大的，雖然這種做法可以在中間步驟上設(shè)置更多檢查點(diǎn)，從而可以有更好的容錯(cuò)性，但很顯然也引入了新的瓶頸。

　　調(diào)度。在測(cè)試的并行數(shù)據(jù)庫(kù)一方，查詢規(guī)劃是編譯時(shí)生成，運(yùn)行時(shí)執(zhí)行。而MR的調(diào)度方案是運(yùn)行時(shí)針對(duì)每個(gè)存儲(chǔ)塊，在處理節(jié)點(diǎn)上調(diào)度一次。這種對(duì)每個(gè)存儲(chǔ)塊一次的調(diào)度顯然開(kāi)銷要大得多。當(dāng)然，這種調(diào)度方式可以讓MR適應(yīng)不同的負(fù)載風(fēng)格和不同性能的節(jié)點(diǎn)。

　　面向列的存儲(chǔ)。這個(gè)在對(duì)比雙方的系統(tǒng)里都不存在。但卻是并行數(shù)據(jù)庫(kù)可以進(jìn)一步提升的手段。

　　正方經(jīng)過(guò)試驗(yàn)得出的結(jié)論是：MR和并行數(shù)據(jù)庫(kù)結(jié)合是最好的方案，MR負(fù)責(zé)數(shù)據(jù)裝載、轉(zhuǎn)換等工作，并行數(shù)據(jù)庫(kù)負(fù)責(zé)查詢密集型的任務(wù)。正方最后發(fā)出的振聾發(fā)聵的呼吁是：很多事情并行數(shù)據(jù)庫(kù)系統(tǒng)已經(jīng)做得很好了，我們?yōu)槭裁床徽驹谶@個(gè)巨人的肩膀上?

　　作者結(jié)語(yǔ)

　　對(duì)于商業(yè)社會(huì)，這種爭(zhēng)論的背后往往帶著巨大的經(jīng)濟(jì)利益：MR和并行數(shù)據(jù)庫(kù)在一定程度上重疊的使用范疇會(huì)導(dǎo)致不小的市場(chǎng)沖突，而在這種潛在沖突的情況下，把握好理論制高點(diǎn)是很重要的一個(gè)指導(dǎo)措施。

　　而對(duì)于學(xué)術(shù)界，避免重新發(fā)明輪子以及因?yàn)槠娴倪m用范疇導(dǎo)致的學(xué)術(shù)資源不合理配置，相信也是各位大大爭(zhēng)論的緣由。這個(gè)爭(zhēng)論讓人想起十幾年前Tanenbaum老頭和Linus Torvalds之間在Kernel上的爭(zhēng)論。十多年后來(lái)看那場(chǎng)辯論，Tanenbaum站住了學(xué)術(shù)和技術(shù)方向的腳跟，而Linus成就了項(xiàng)目的輝煌。沒(méi)有對(duì)錯(cuò)，留給我們的是極為豐富的經(jīng)驗(yàn)，Linus站在了Tanenbaum肩膀上，而我們站在了Linus的肩膀上。可能看完這篇對(duì)比之后，大多數(shù)同學(xué)的反應(yīng)都會(huì)是：該干嗎干嗎，在哪好使就使啥。絕對(duì)沒(méi)錯(cuò)，不過(guò)，我們也要從歷史中學(xué)會(huì)更多經(jīng)驗(yàn)啊!可別因?yàn)槭掷镞N子，就滿世界都是釘子。雖說(shuō)各有各的好處和適用范圍，可事實(shí)呢?人們還是經(jīng)常會(huì)因?yàn)槟承┬掳l(fā)現(xiàn)而被頭腦發(fā)熱沖擊得失去了判斷力：滿世界都是釘子!可不是嗎?想想這些年流行的種種，人們總是易于認(rèn)為一個(gè)新技術(shù)可以搞定天下所有問(wèn)題。

　　做為一個(gè)數(shù)據(jù)庫(kù)用戶，我多少傾向數(shù)據(jù)庫(kù)大大們的意見(jiàn)。結(jié)合自己的實(shí)際，在很多場(chǎng)合下，自己會(huì)利用系統(tǒng)工具，如Awk、Perl等做數(shù)據(jù)并行裝載的事情，不知不覺(jué)用了MR的概念，很自然也很方便。而真正的數(shù)據(jù)查詢，還是喜歡高級(jí)而簡(jiǎn)單的SQL，讓我去寫一堆Map/Reduce過(guò)程而放棄手邊的SQL工具，感覺(jué)很痛苦。感覺(jué)自己還是應(yīng)該把一個(gè)東西用到極致，結(jié)合新的工具來(lái)站的更高，而不是盲目放棄。所以盡管自己經(jīng)常被冠以“手拿錘子，滿世界都是釘子”的頭銜，但實(shí)際工作中卻發(fā)現(xiàn)很多同學(xué)卻是在實(shí)際行動(dòng)中打的是MR的旗號(hào)，行的是革數(shù)據(jù)庫(kù)的命之行動(dòng)，在重新發(fā)明輪子的道路上越行越遠(yuǎn)，卻興致勃勃。不能不令人扼腕。在這個(gè)大討論里，正反雙方最后幾乎異口同聲地說(shuō)出了“實(shí)現(xiàn)相關(guān)”的結(jié)論，貌似這個(gè)爭(zhēng)論已經(jīng)可以畫上句號(hào)了。幾乎可以肯定的是，MR會(huì)以各種方式越來(lái)越像數(shù)據(jù)庫(kù)系統(tǒng)，而數(shù)據(jù)庫(kù)系統(tǒng)會(huì)以各種方式集成MR的優(yōu)點(diǎn)，變成前置的ETL系統(tǒng)/或后置的數(shù)據(jù)再處理系統(tǒng)。不管怎樣，爭(zhēng)論中留下的一個(gè)個(gè)閃光的要點(diǎn)，相信會(huì)對(duì)我們了解事物，做出判斷有著巨大的幫助。

服務(wù)器租用/服務(wù)器托管中國(guó)五強(qiáng)！虛擬主機(jī)域名注冊(cè)頂級(jí)提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]