資料庫系統是鎯頭; MapReduce 則是螺絲起子
最近年來不管是雲端運算(Cloud computing) 或是網格運算(Grid computing) 都相當的熱門, 而它們的核心技術 MapReduce 則受到相當程度的重視. 04 年時 MapReduce 一開始被 Google 所提出來, 它本身是一種程式開發的模式,可以用來處理大量的資料. 但因為長時間以來, 不管是在學校或是業界, 資料庫系統都廣泛的被教授和使用,很多人一看到"處理大量的資料", 自然的就會把 MapReduce 跟資料庫系統放在一起, 拿來做比較等等, 因而產生一些錯誤的認知.
目前任職在 Google 的 Mark 日前撰寫了一篇文章 Databases are hammers; MapReduce is a screwdriver 來說明這兩者的不同. 這篇文章是我個人認為目前在網路上說明 MapReduce 文章當中寫的最貼切且淺顯易懂的. 經過原作者的同意 , 我把它翻譯成中文, 希望讓更多人藉著閱讀這篇文章來瞭解 MapReduce.
資料庫系統是鎯頭; MapReduce 則是螺絲起子.
有一群朋友們把一篇關於批評MapReduce的文章傳 給我. 我曾經猶豫是否我應該寫些什麼, 因為目前為止有很多關於MapReduce的東西正被開發中, 而且被Google的同仁們廣泛的使用. 但是這篇文章真的是有點惱人, 我理當回應它. 所以我在這邊先做個澄清, 我並不是以一位Google員工的身份來評論它.(事實上, 我在工作上並沒有使用MapReduce). 這純粹是用我自己的時間, 發表我個人的意見. 如果您覺得這是一篇愚蠢的文章, 那是我個人的錯跟Google無關. 如果您覺得這篇文章寫的很出色, 那也是我個人的榮幸跟Google無關. Google 並沒有要求我寫這篇文章, 同樣的我也沒有要求 Google 的同意. 這僅只是我個人的行為, 瞭解嗎?
我會對這件事情有興趣的原因是因為這跟我的博士研究有關. 回想起研究所那時候, 我的研究是關於在非科學性的應用軟體上, 將平行運算的技術應用在結構化資料上.這差不多是 MapReduce 所要做的事情. 而我所提出的解決方案是某種階層式的分散(scatter)/收集(gather)運算子,非常接近 MapReduce 運作的方式. 那最大的差異在哪邊? 那就是 MapReduce 打敗了我, 設計MapReduce 的人注意到我沒注意到的東西, 並且利用了它使得 MapReduce 程式更乾淨, 更容易開發.
讓我們從頭開始, MapReduce 是啥, 它能做什麼?
今天假設你在工作, 你需要做某件事情, 但是它在你的電腦上會跑蠻久的時間, 你不想等但是你也不想要花幾百萬去買台超級電腦, 那你要怎樣才能夠讓它跑快一點? 有一個方法是買一群便宜的電腦, 讓它們同時一起幫你執行工作. 另一方面你也注意到辦公室內有很多台電腦, 幾乎每個員工座位上都有一台, 在某個時間點上大部分的電腦並沒有在做太多事情, 那為何不利用它們呢? 當你的機器不甚忙碌的時候, 你允許你的同事借用你當下並不在使用的資源, 當你需要的時候也可以借用他們的機器. 所以當你需要執行大的工作的時候, 你可以輕鬆的找到好幾打的機器來用.
這個方法最大的問題在於, 大部分的程式並沒撰寫成可以在多台的機器上執行的模式, 它們被寫成只能在一臺機器上執行. 而要把一件困難的工作分到很多台機器執行上是件困難的事情.
MapReduce 是一種程式語言開發模式, 它讓你可以透過撰寫特有的制式化程式, 輕鬆的把工作分散到一群機器上面去執行. 它基本的概念在於你把工作分成兩部份 Map 以及 Reduce. Map 基本上負責把問題分成好幾份並且送到不同的機器去,所以它們可以同時被處理. Reduce 則接收每份問題的處理的結果, 最後組合成單一的答案.
MapReduce 運作的關鍵在於, 把輸入的資料在概念上當成成一個包含很多筆紀錄的 list, 透過 map 這些紀錄被分配到不同的機器上去處理. map 計算的結果是一個包含許多 key/value 組的 list. Reduce 會取得同樣 key 值的所有 value, 並組合成為最後的單一 value. 也就是 Map 將資料產生成為 key/value 組, reduce 則組合結果給你單一的結果. 你無法知道這個工作是被分成100份或是2份, 而最後應該是跟只有單一 map 時候是一樣的. (這就是 MapReduce 和我博士研究方法不同的地方, 領悟到把結果當作是 key/value map 來看,你會得到非常乾淨且一致的歸納流程. 雖然我的 scatter/gather 模式是同樣的概念 , 但是我的 reduces 跟 Map/Reduce 比起來相對的醜陋許多.)
MapRedue 美麗的地方在於撰寫它是多麼的簡單, 在平行處理程式語言的領域上從來沒這麼簡單過.
回到該篇批評 MapReduce 的文章, 他們批評 MapRduce, 其實基本上並不是基於關聯式資料庫(Relational databaes) 的概念.
當我第一次花時間學習關聯式資料庫的時候, 我的老闆告訴我ㄧ個關於資料庫專家的故事, 是我認為最貼切的故事. 這個故事是說關聯式資料庫的專家們發現了這個世界上最美麗,最漂亮,最完美的鎯頭, 完美到不會太重,也不會太輕,恰到好處的可以把釘子給釘進去,它的柄是根據所有者手的角度去特製化的, 所以釘一整天也不會起水泡.同時它也是裝飾的很漂亮的鎯頭, 上面有寶石鑲嵌跟黃金的工飾在適當的地方, 絲毫不會減損鎯頭的功能. 它真的是一個最偉大的鎯頭.資料庫專家們熱愛他們的鎯頭, 因為它是多麼美妙的工具. 而且他們真的利用這個工具做出許偉大的東西. 他們是如此的喜歡關聯式資料庫,以致於認為這是這是他們唯一需要的工具. 如果你給他們一個螺絲釘, 他們會把它當成釘子一樣的釘進去. 當你提醒他們說, 嘿這樣會弄壞東西 , 那是螺絲釘不是釘子, 他們會說"我知道阿, 但是我有這隻極好的鎯頭 , 你不能期待我使用那鱉腳的小螺絲起子"
現況是這樣, 他們有關聯式資料庫, 關聯式資料庫絕對是個傑出的東西, 是個驚人的工具可以幫我們做出驚人的軟體. 我自己曾經利用關聯式資料庫完成許多工作, 沒有它, 我將沒有辦法完成一些令我感到驕傲的事情. 我完全不想貶低關聯式資料庫, 它真的是偉大的系統.但是不是每件事情都是關聯式資料庫, 不是每件事情天生就適合把它當作關聯來看待. 所有對 Mapreduce 的指責都源於"這不是我們關聯式資料庫會做的方式", 而並沒有瞭解到事情的重點. 關聯式資料庫的平行處理並不是很好, 你知道有多少關聯式資料庫可以有效的把工作分給 1,000 台普通機器? 關聯式資料庫無法很好的處理非表格式的資料, 像是面對遞迴資料的處理上可以說是是聲名狼藉. MapReduce 不是為了要取代關聯式資料庫, 它是提供一種輕便的程式語言開發方式, 讓大家可以快速且以平行的方式在一群機器上面執行, 僅止於這樣.
