理解MapReduce哲學

Google工程師將MapReduce定義為一般的HTTP://www.aliyun.com/zixun/aggregation/14345.html">資料處理流程。 一直以來不能完全理解MapReduce的真義，為什麼MapReduce可以「一般」？

最近在研究Spark，拋開Spark核心的記憶體計算，這裡只關心Spark做了什麼。 在Spark上的所有工作都是圍繞資料集進行，包括創建新的資料集、對資料集的轉換、對資料集的歸約。 對於實際應用中的資料處理流程，Spark的這些似乎足夠了，足夠形成一套一般的資料處理流程。 的確，Spark以資料集為操作物件，而可以不論資料集中資料的類型——很樸素的思想！

那麼MapReduce呢？ MapReduce是否應當被拋棄？ 在基於Hadoop的即時查詢問題上，Hadoop的MapReduce框架也因其效率低下而飽受詬病。 對於這個問題我想說的是，這絲毫不是MapReduce自身的問題，也不應全是Hadoop的MapReduce框架的問題，而更主要的是像Hive這類應用不當使用MapReduce的問題。 MapReduce無辜地說：「我只對單輪MapReduce處理流程負責，你應當慎重考慮MapReduce處理流程的資料來源和資料去向。 」

現在來讀讀MapReduce的哲學。 現實世界的資料是多樣的，這些資料在進入資訊系統處理之前，我們無法確定哪些資料對於我們的資料查詢或分析任務有用或無用，我們只能將所有能夠收集到的資料以最原始的形式存儲下來。 接下來就是MapReduce施展神威的時刻。 MapReduce第一步，Map：將資料歸類，為每個資料打上一個標明資料屬於哪個主題的標籤——Key或Key的一部分。 經過Map過程，無用資料被過濾，異構資料被統一表示，並且資料按主題分好組。 下一步如果要查詢或分析特定主題的資料，可以按主題取一組或多組資料。 MapReduce第二步，Reduce：將資料歸約，在選定的資料上實施查詢或分析動作，輸出查詢或分析結果。 Reduce過程可以做很多事情，可以做各類事情，包括遞迴發起新的MapReduce處理流程。 只要還沒有產生最終的查詢或分析結果，就盡可能不要從Reduce過程返回到使用者。 看看Hive做了什麼，Hive將一個SQL查詢命令翻譯成多個循序的MapReduce處理流程，難道不能在一個MapReduce處理流程的Reduce過程中完成所有工作嗎？ Hive的失敗在於把MapReduce當成了工具而不是指導思想——世俗化了!

MapReduce與Spark，二者並不排斥，而完全可能很好地結合。 我個人的想法是：在MapReduce的Reduce過程中使用Spark完成需要對資料集進行多次反覆運算才能得到結果的任務，如SQL查詢。