【Hadoop】18-作業調優

作業運作後，許多開發人員可能會問：“能夠讓它運作得更快一些嗎？"有一些Hadoop相關的“疑點”值得檢查一下，看它們是不是引發性能問題的“元兇”。在開始任務級别的分析或優化之前，必須仔細研究下表所示的檢查内容。

作業優化檢查表：

範圍	最佳實踐	更多參考資訊
mapper的數量	mapper需要運作多長時間？如果平均隻運作幾秒鐘，則可以看是否能用更少mapper 運作更長的時間，通常是一分鐘左右。時間長度取決于使用的輸人格式	輸入分片與記錄
reducer的數量	檢查使用的reducer數目是不是超過1個。根據經驗， Reduce任務應運作5分鐘左右，且能生産出至少一個資料塊的資料	預設的 MapReduce作業
combiner	作業能否充分利用combiner來減少通過shuffle傳輸的資料量	biner函數
中間值的壓縮	對map輸出進行壓縮幾乎總能使作業執行得更快	在MapReduce使用壓縮
自定義序列	如果使用自定義的Writab1e對象或自定義的comparator，則必須確定已實作RawComparator	實作定制的Writable集合
調整shuffle	MapReduce的shuffle過程可以對一些記憶體管理的參數進行調整，以彌補性能的不足	配置調優

分析任務

正如調試一樣，對MapReduce這類分布式系統上運作的作業進行分析也有諸多挑戰。Hadoop允許分析作業中的一部分任務，并且在每個任務完成時，把分析資訊放到使用者的機器上，以便日後使用标準分析工具進行分析。當然，對本地作業運作器中運作的作業進行分析可能稍微簡單些。如果你有足夠的資料運作map和reduce任務，那麼對于提高mapper和reducer的性能有很大的幫助。但必須注意一些問題。本地作業運作器是一個與叢集完全不同的環境，并且資料流模式也截然不同。如果MapReduce作業是1/0密集型的（很多作業都屬于此類），那麼優化代碼的CPU性能是沒有意義的。為了保證所有調整都是有效的，應該在實際叢集上對比新老執行時間。這說起來容易做起來難，因為作業執行時間會随着與其他作業的資源争奪和排程器決定的任務順序不同而發生改變。為了在這類情況下得到較短的作業執行時間，必須不斷運作（改變代碼或不改變代碼），并檢查是否有明顯的改進。

有些問題（如記憶體溢出）隻能在叢集上重制，在這些情況下，必須能夠在發生問題的地方進行分析。

1.HPROF分析工具

許多配置屬性可以控制分析過程，這些屬性也可以通過JobConf的簡便方法擷取。啟用分析很簡單，将屬性mapreduce.task.profile設定為true即可：

hadoop jar hadoop-examples.jar v4.MaxTemperatureDriver \
    -conf conf/hadoop-cluster.xml \
    -D mapreduce.task.profile=true \
    input/ncdc/allmax-temp
           

上述指令正常運作作業，但是給用于啟動節點管理器上的任務容器的Java指令增加了一個-agentlib參數。可以通過設定屬性mapreduce.task.profile.params來精确地控制該新增參數。預設情況下使用HPROF，一個JDK自帶的分析工具，雖然隻有基本功能，但是能提供程式的CPU和堆使用情況等有價值的資訊。

分析作業中的所有任務通常沒有意義，是以，預設情況下，隻有那些ID為0，1，2的map任務和reduee任務将被分析。可以通過設定mapreduce.task.profile.maps和mapreduce.task.profile.reduces兩個屬性來指定想要分析的任務ID的範圍。

每個任務的分析輸出和任務日志一起存放在節點管理器的本地日志目錄的userlogs子目錄下（和syslog，stdout，stderr）檔案一起），可以根據日志聚合是否啟用，使用hadoop日志章節介紹的方法擷取到。