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

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

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

　　正方拋出觀點

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

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

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

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

　　反方接招

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

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

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

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

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

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

　　正方的回應(yīng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　作者結(jié)語

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

　　而對于學(xué)術(shù)界，避免重新發(fā)明輪子以及因為片面的適用范疇導(dǎo)致的學(xué)術(shù)資源不合理配置，相信也是各位大大爭論的緣由。這個爭論讓人想起十幾年前Tanenbaum老頭和Linus Torvalds之間在Kernel上的爭論。十多年后來看那場辯論，Tanenbaum站住了學(xué)術(shù)和技術(shù)方向的腳跟，而Linus成就了項目的輝煌。沒有對錯，留給我們的是極為豐富的經(jīng)驗，Linus站在了Tanenbaum肩膀上，而我們站在了Linus的肩膀上�？赡芸赐赀@篇對比之后，大多數(shù)同學(xué)的反應(yīng)都會是：該干嗎干嗎，在哪好使就使啥。絕對沒錯，不過，我們也要從歷史中學(xué)會更多經(jīng)驗啊!可別因為手里攥著錘子，就滿世界都是釘子。雖說各有各的好處和適用范圍，可事實呢?人們還是經(jīng)常會因為某些新發(fā)現(xiàn)而被頭腦發(fā)熱沖擊得失去了判斷力：滿世界都是釘子!可不是嗎?想想這些年流行的種種，人們總是易于認(rèn)為一個新技術(shù)可以搞定天下所有問題。

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

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