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

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

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

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

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

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

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

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

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

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