Hadoop中理論與工程的錯位

Hadoop是當前重要的大數(shù)據(jù)計算平臺，它試圖摒棄傳統(tǒng)數(shù)據(jù)庫的理念，重新構(gòu)建一套新的大數(shù)據(jù)體系。但是，這并不是件很容易的事，在Hadoop的設計和實現(xiàn)中能看到一些先天不足的地方，其中一點就是把理論問題和工程問題給搞擰了。

專注于為中小企業(yè)提供網(wǎng)站制作、網(wǎng)站設計服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)黃陂免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

Hadoop中理論與工程的錯位

所謂理論方法，是指試圖解決問題的一般情況，設計通用的算法能適應盡量多的情況，并努力使算法的復雜度降低。在研究問題時不會考慮具體環(huán)境下某個具體動作是否可以執(zhí)行以及該動作消耗的資源，而會假想一個理想的環(huán)境;工程方法則相反，不需要考慮普遍的一般情況，而是針對某個具體問題，充分利用當前環(huán)境提供的便利，并充分考慮每個具體動作消耗的資源(包括時間)，盡量高效率低成本地實現(xiàn)目標。原則上，在設計體系模型時要理論化，而在編碼實現(xiàn)時則要工程化，這樣才能做出一個即能解決足夠多問題且效率也可接受的產(chǎn)品。

但是，Hadoop在不少地方把這個事情搞反了。本該由理論解決的一般性問題被用工程方法簡化成特定問題，而具體實現(xiàn)時又把本該在工程層面優(yōu)化的問題想得過于理論化。導致的結(jié)果就是能方便解決的問題太少，而解決問題時效率又太低。一句話說就是理論問題工程化，工程問題理論化。

MapReduce是Hadoop中關(guān)鍵的并行機制，經(jīng)過多輪封裝改進，這個模型現(xiàn)在仍然是Hadoop的算法核心。這個方法認為可以將一個大任務拆成一些無關(guān)的小任務，分別處理(Map)后再按某個鍵值歸攏到一起再做處理(Reduce)。Hadoop實現(xiàn)好這個框架后，程序員就只要寫Map和Reduce動作即可了，這樣就編寫并行程序就會簡單很多。

MapReduce用來處理求和、計數(shù)等簡單問題也確實有效，但世界可沒有這么簡單!

琢磨一下用MapReduce去實現(xiàn)JOIN運算的麻煩度就知道了(具體做法可以從網(wǎng)上找到，這里不細說了)，而這種有關(guān)聯(lián)的運算在現(xiàn)實需求中相當常見，其它一些次序有關(guān)的運算用MapReduce實現(xiàn)也很困難。也就是說，MapReduce算法能夠方便描述的運算太少了，這個模型的適應面太窄?；谶@個理論實現(xiàn)的產(chǎn)品，面對復雜運算時基本上起不到減少工作量的目標，甚至根本無法應用。本該在理論上研究出更通用的算法，卻被工程化成簡單情況。

然而，Hadoop在實現(xiàn)MapReduce框架時，卻又缺乏對具體情況的考慮，而是假想了一個理想環(huán)境。Hadoop認為集群節(jié)點機可以無窮多，任何性能問題都只要增加節(jié)點就可以解決，這樣就沒興趣去關(guān)注單機性能了，肆意地跑出多個進程而很少采用經(jīng)常效率更高(但不總是)的多線程手段;Hadoop不考慮外存讀寫的巨大延遲，Map過程 的中間結(jié)果要寫盤暫存，理論上復雜度其實也不算很高(讀寫次數(shù)基本是確定的)，但實際運行效率之低令人難以容忍，很難想象有工程經(jīng)驗的程序員敢采用這種機制。實測情況是大概四五個節(jié)點的hadoop集群才能趕得上被充分工程優(yōu)化后的單臺機器性能。

Spark也有類似的問題。Spark前的Hadoop在工程上對內(nèi)存利用不足(如前述的MapReduce總是要落盤)，而Spark又走向另一個極端，從理論模型上就只考慮內(nèi)存計算了。我們知道，外存計算和內(nèi)存計算是很不一樣的，外存計算要復雜困難得多，而大數(shù)據(jù)常常面臨外存計算，原則上我們應當改進當前的外存計算算法體系，努力降低復雜度并擴大適應范圍，而不是簡單避開這個困難，這就是刻意簡化問題了，適應面會大折折扣。

退一步講，就算只考慮內(nèi)存計算，能做好也是有相當意義的。但是，Spark在實現(xiàn)時卻又走入了理論化的窠臼，它把那個RDD搞成immutable，這個機制有很強的理論色彩，和數(shù)學運算中的抽象數(shù)據(jù)類型一致，用來描述算法確實很美?？墒牵瑢嶋H運行時將造成大量沒有必要的內(nèi)存復制，本來是打算提高性能的，卻得不償失，然后又要再用其它手段去繞。

類似的情況，細糾下去還有。發(fā)明新理論確實很難，為降低難度而簡化問題還可以理解(其實傳統(tǒng)數(shù)據(jù)庫領(lǐng)域已經(jīng)積累了不少這理論，只是學會并不算很難)，但在工程實現(xiàn)時又搞得理論化就難以理解了，這樣怎么會有高性能？

網(wǎng)頁題目：Hadoop中理論與工程的錯位
文章起源：http://muchs.cn/article4/chooe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、網(wǎng)站設計、網(wǎng)站內(nèi)鏈、網(wǎng)站導航、虛擬主機、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)