MapReduce和并行數據庫:朋友還是敵人？

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

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

　　正方拋出觀點

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

　　一、MR沒法用索引，總是對數據進行完全掃描;

　　二、MR 輸入和輸出，總是文件系統中的簡單文件;

　　三、MR需要使用不高效的文本數據格式。

　　反方接招

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

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

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

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

　　用MR可以表現更復雜的數據變換規則，很多反方的意見都是實現相關的，是針對一些不好的MR的實現做出來的，因此站不住腳。

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

　　正方的回應

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

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

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

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

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

　　快速實施的系統：并行數據庫最大的缺點就是架設和調優難度要比MR大得多，雖然一旦架設、調優完畢，并行數據庫系統表現出遠勝MR的性能和特性，但對大多數急于上手的入門級用戶來說，并行數據庫系統的學習門檻顯然要高得多。最后就是成本，雖然并行數據庫在性能和應用編寫簡易性方面明顯勝于MR系統，但現實世界里確實還缺乏完善和健壯的低成本開源解決方案，這點是MR最大的優點。數據庫社區顯然在這個方面輸了一陣。

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

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

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

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

　　針對上面的結果，正方做了一些分析，認為這些差距的來源主要來自于具體實現，而非并行數據庫模型和MR模型之間的差異。比如，MR可以使用并行數據庫為低層的存儲，所以所有分析都針對現實中兩種模式的具體實現。正方分析了導致差距的幾個實現相關的架構原因：

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

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

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

　　調度。在測試的并行數據庫一方，查詢規劃是編譯時生成，運行時執行。而MR的調度方案是運行時針對每個存儲塊，在處理節點上調度一次。這種對每個存儲塊一次的調度顯然開銷要大得多。當然，這種調度方式可以讓MR適應不同的負載風格和不同性能的節點。

　　面向列的存儲。這個在對比雙方的系統里都不存在。但卻是并行數據庫可以進一步提升的手段。

　　正方經過試驗得出的結論是：MR和并行數據庫結合是最好的方案，MR負責數據裝載、轉換等工作，并行數據庫負責查詢密集型的任務。正方最后發出的振聾發聵的呼吁是：很多事情并行數據庫系統已經做得很好了，我們為什么不站在這個巨人的肩膀上?

　　作者結語

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

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

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

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]