影響MapReduce性能的幾個因素

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任務的性能。