Hadoop MapReduce效能優化
影響MapReduce輸入資料處理時間的因素很多。其中之一是實現map和reduce函式時使用的演算法。其他外部因素也可能影響MapReduce效能。根據我們的經驗和觀察，可能影響MapReduce的主要因素有以下幾個。

• 硬體（或者資源）因素，如CPU時鐘、磁碟I/O、網路頻寬和記憶體大小。
• 底層儲存系統。
• 輸入資料、分揀（shuffle）資料以及輸出資料的大小，這與作業的執行時間緊密相關。
• 作業演算法（或者程式），如map、reduce、partition、combine和compress。有些演算法很難在MapReduce中概念化，或者在MapReduce中效率可能會降低。

執行map任務時，shuffle子任務的中間輸出儲存在記憶體緩衝區中，用以減少磁碟I/O。輸出的大小可能會超過記憶體緩衝區而造成溢位，因此需要spill子階段把資料重新整理到本地檔案系統。這個子階段也會影響MapReduce效能，它經常採用多執行緒技術實現，以便使磁碟I/O利用率最大化並縮減作業的執行時間。

MapReduce程式設計模型允許使用者使用自己的map和reduce函式指定資料轉換邏輯。本模型並不限定map函式產生的中間對在交由reduce函式處理前如何被分組。因此，歸併排序（merge-sort）演算法被用作預設的分類演算法。然而，歸併排序演算法並非總是最高效的，尤其是對分析型任務（如聚合和等值連線）而言，這類任務並不關心中間鍵的順序。

提示.tif對於MapReduce程式設計模型來說，分組（grouping）/劃分（partitioning）是一個序列的任務。這就意味著在reduce任務可以執行之前，框架需要等待所有map任務完成。

想要深入學習歸併排序演算法，請參考http://en.wikipedia.org/wiki/Merge_sort。
MapReduce效能是以map和reduce的執行時間為基礎的。這是因為典型環境下叢集節點數目和節點插槽數目這類引數是不可修改的。

其他可能對MapReduce效能構成潛在影響的因素具體如下。

• I/O模式：也就是從儲存系統獲取資料的方式。從底層儲存系統讀取資料有以下兩種模式。
  直接I/O：通過硬體控制器把資料從本地硬碟快取中直接讀到記憶體，因而不需要程序間通訊成本。

流式I/O：通過特定程序間通訊手段，如TCP/IP和JDBC，從其他正在執行程序（典型情況是儲存系統程序）讀取資料。

從提高效能的角度看，使用直接I/O比流式I/O更高效。

• 輸入資料解析：是指從儲存系統獲取資料時，從原始資料到鍵值對的轉換過程。資料解析過程的目標是把原始資料按照原來的格式解碼，並轉換為可供Java等程式語言處理的資料物件。

輸入資料可以解碼為（Java或者其他語言）物件，這樣當物件例項建立後，物件內容可以改變，典型的情況是使用對物件例項的引用（這樣的物件叫做可變物件），輸入資料也可以解碼為一經建立其內容就不可改變的物件（叫做不可變物件）。在上百萬條記錄的情況下，不可變物件的解碼過程會明顯比可變物件的解碼過程慢，這是因為在前者解碼過程中產生了大量不可變物件。因此，這會導致系統性能的降低。 - 輸入資料儲存：當MapReduce獲取資料並進行進一步處理時，所在的儲存系統必須保證高速訪問和資料可用性（如HDFS和HBase）。如果選用的不是那些推薦的與MapReduce一起使用的儲存檔案系統，那麼輸入資料的訪問會潛在地影響MapReduce效能。

使用Hadoop框架時，許多因素可能會影響整個系統的效能和作業的執行時間。這些因素可能是Hadoop MapReduce引擎的一部分，也可能是引擎之外的。

Hadoop配置引數通常會影響併發執行的任務數，並決定作業的執行時間，因為Hadoop叢集被建立且作業開始執行後，其他因素就不可改變了。如果Hadoop框架配置不當，可能無法充分利用叢集資源，並因此影響MapReduce作業效能。這是因為大量的配置引數控制著Hadoop框架的行為。

一項Hadoop作業經常由許多實現不同演算法的子模組組成，這些子模組要麼以序列方式連線，要麼以並行方式連線。如果Hadoop框架配置不當，可能會影響內部任務完成的協作方式。所有這類引數（將在第2章討論）設定的影響都依賴於map和reduce函式的程式碼、叢集資源，當然還有輸入資料。

MapReduce作業的效能也可能受Hadoop叢集節點數的影響，以及受所有節點中執行map和reduce任務的可用資源的影響。每個節點的容量決定了一個節點可以執行的mapper和recducer任務的數量。因此，如果節點資源利用不充分或者過度利用，都會直接影響MapReduce任務的效能。