1 Hadoop管道改進思想
在Hadoop系統的實現中，Map端的輸出數據首先被溢寫入本地磁盤，當本機任務完成後通知JobTracker，然後Reduce端在得到 JobTracker的通知後會發出HTTP請求，利用複製的方式從相應的Map端拉回其輸出。這樣的方式只能等該Map任務完成後才能開始執行 Reduce任務，並且Map任務和Reduce任務的執行是分離的。
我們的改進思想是使Map任務和Reduce任務能夠以管道的方式執行，即Map任務開始產生輸出後直接發送給相應的Reduce任務，這需要在用戶提交作業後JobTracker就分配相應的Map任務和Reduce任務，並將每個Map任務的位置發送給Reduce任務。每個Reduce任務啓動後就聯繫每個任務並打開一個Socket。當每個Map輸出一產生後Mapper便決定發送的分區（Reduce任務）並通過適合的Socket直接發送。
Reduce任務接收從每個Map任務收到的管道數據並將其存儲在內存緩衝區中，在需要時將已排好序的緩衝區內容寫到磁盤。一旦Reduce任務得知每個 Map任務均已完成，它執行已排序內容的最終合併，然後調用用戶自定義的Reduce函數，將輸出寫入HDFS。
2 面臨問題及解決方法
在以上的改進思想中面臨以下幾個實際問題，我們將對其進行分析並提出解決方法。
(1) Hadoop系統可能沒有最夠可用任務槽來調度作業的每個任務。
由於任務槽的限制，可能部分Reduce還沒有被調度，則Map輸出無法直接發送給它。改進方法爲將這部分Map的輸出寫入磁盤，當Reduce任務被分配任務槽後，就像Hadoop系統一樣從Map任務複製數據。
(2) 打開每個Map任務和Reduce任務之間的Socket需要大量的TCP連接。
大量的TCP將佔用過多的網絡帶寬，容易造成網絡堵塞。爲了減少併發TCP連接數，每個Reducer可以被配置爲從有限數量的Mapper以管道方式傳送數據，其餘的數據按Hadoop系統的傳統方式從Mapper拉回。
(3) 調用Map函數和將輸出寫入管道Socket使用相同的線程。
這可能將導致如下情況，由於Reducer過度使用而造成網絡I/O堵塞，則Mapper也無法做有用的工作。改進方法爲以單獨線程運行Map函數，將其輸出存儲到內存緩衝區，然後由另一線程定期發送緩衝區內容到管道Reducer端。
(4) Map任務急切發送產生的數據，阻止了Combiner的使用，並將一些排序工作從Mapper移動到Reducer。
Map任務一產生數據便使用管道方式傳送給對應的Reduce而沒有機會應用Combiner函數，會增大網絡流量。同時Map的排序過程更多的轉移到 Reduce任務會Reduce的響應時間並帶來很大的系統開銷，因爲通常Map任務的數量遠遠大於Reduce任務。改進方法爲修改內存緩衝區設計，不直接發送緩衝區內容給Reducer，而是等到緩衝區增長到閾值大小後應用Combiner函數，按分區和key值進行排序後將內容溢寫入磁盤。第二個線程監測溢寫文件並將其以管道方式發送給Reducer。如果Reducer能夠趕上Mapper並且網絡不是瓶頸，則溢寫文件在產生後馬上發送給 Reducer。否則溢寫文件將逐漸增加，Mapper定期對其應用Combiner函數將多個溢寫文件合併成一個單一的大型文件。
3 改進系統的實現
UC Berkeley的Tyson Condie等人基於MapReduce Online論文實現了Hadoop Online Prototype(HOP)[13]系統，它除了能夠實現作業內Mapper到Reducer的管道之外，還利用“快照”技術實現了作業間 Reducer到Mapper的管道執行。HOP還支持連續查詢，這使得MapReduce程序能夠被用於事件監測和流處理的等實時應用。同時，HOP保留了Hadoop的容錯特性，並能夠運行未修改的用戶定義的MapReduce程序。
HOP實現的數據流與Hadoop系統的對比如下圖所示：
在Hadoop-0.19.2中，org.apache.hadoop.mapred包實現了Hadoop MapReduce思想，HOP增加了org.apache.hadoop.mapred.bufmanager包來管理Map和Reduce任務的輸入和輸出。其中主要包含的類如下表所示：
我們參考HOP程序對Hadoop-0.19.2進行修改，並使用Ant編譯，成功後執行情況與HOP相同，同樣在集羣情況下執行MapReduce作業過程中停滯。分析原因，如果HOP系統本身的實現不存在問題，那可能是實驗集羣的配置或者網絡存在問題，但是具體原因一直沒有發現並解決。
基於Hadoop系統優化的測試實驗使用HOP系統進行，能夠使Map過程和Reduce過程管道執行。根據MapReduce Online論文中所示，作者在Amazon EC2上使用60節點集羣執行了性能測試實驗，對從維基百科提取的5.5GB數據進行排序，結果如下圖所示：
實驗結果顯示HOP比Hadoop更有優勢，大大減少了作業完成時間，具有更高的系統利用率。
但是由於在集羣中執行HOP出現錯誤，爲了驗證其優化效果，使用僞分佈式執行WordCount程序，通過與Hadoop系統上執行原始程序進行對比，得到兩者的執行時間分別爲314秒（HOP）和266秒（Hadoop），兩者的Map過程和Reduce過程分別如下圖1和下圖2所示。通過對比可以發現，HOP系統確實實現了Map過程和Reduce過程的管道執行，但是在作業執行時間上HOP系統更長，這於上圖的對比分析圖有差異。具體可能由HOP 系統實現、集羣數量及配置、處理數據量等多方面原因導致。但是HOP這種改進思想還是很值得學習和借鑑。