Hadoop如何優化

這篇文章給大家分享的是有關Hadoop如何優化的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1. 網絡帶寬

Hadoop集群的服務器在規劃時就在統一的交換機下，這是在官方文檔中建議的部署方式。但是我們的這臺交換機和其他交換機的互聯帶寬有限，所以在客戶端遇到了HDFS訪問速度慢的問題。把操作集群的客戶端也聯入DataNode的交換機內部，解決了這個問題。

2. 系統參數

對ulimit -c的修改也是官方文檔建議的修改，在集群只有10臺服務器時，并沒有遇到問題。隨著機器增加和任務增加，這個值需要改的更大。

3. 配置文件管理

這個集群用的是Cloudera發行的版本，配置文件默認存在/etc/hadoop/conf位置。這是一個只有root才能修改的位置。為了修改方便，我把配置文件統一保存在一臺機器上，修改后用腳本分發。保證所有服務器都是統一的配置。

4. mapred.tasktracker.map.tasks.maximum

這個參數控制每個TaskTracker同時運行的Map任務數。以前的設置是和CPU核數相同的，偶爾遇到任務擠占DataNode資源的問題。現在改成map+reduce+1==num_cpu_cores。

5. 嚴格控制root權限

Cloudera的發行版會創建一個hadoop用戶，各種守護進程都應該以這個用戶運行。曾經有誤操作（/usr/lib/hadoop/bin/hadoop datanode &）導致本地的數據目錄被root寫入新文件，于是正確啟動的hadoop用戶進程無法讀寫。所以現在的集群服務器不提供日常的root權限訪問。

6. Java的GC模式

在mapred.child.java.opts和HADOOP_OPTS都增加了-XX:+UseConcMarkSweepGC。JDK的文檔中推薦現代多核處理器系統，采用這種GC方式，可以充分利用CPU的并發能力。這個改動對性能的積極影響很大。

7. 選擇正確的JDK

這個集群有部分服務器的JDK用的是32位版本，不能創建-Xmx4g以上的進程。統一為x64版本的JDK。

8. mapred.reduce.slowstart.completed.maps

這個參數控制slowstart特性的時機，默認是在5%的map任務完成后，就開始調度reduce進程啟動，開始copy過程。但是我們的機器數量不多，有一次大量的任務堆積在JobTracker里，每個TaskTracker的map和reduce slots都跑滿了。由于map沒有足夠資源迅速完成，reduce也就無法結束，造成集群的資源互相死鎖。把這個參數改成了0.75，任務堆積的列表從平均10個，變成了3個。

9. mapred.fairscheduler.preemption

這個參數設為了true。以便fairscheduler在用戶最小資源不能滿足時，kill其他人的任務騰出足夠的資源。集群運行著各種類型的任務，有些map任務需要運行數小時。這個參數會導致這類任務被頻繁kill，幾乎無法完成。曾經有個任務在7小時內被kill了137次。可以通過調整fairscheduler的pool配置解決，給這種任務單獨配置一個minMap==maxMap的pool。

10. mapred.jobtracker.completeuserjobs.maximum

限制每個用戶在JobTracker的內存中保存任務的個數。因為這個參數過大，我們的JobTracker啟動不到24小時就會陷入頻繁的FullGC當中。目前改為5，JT平穩運行一天處理1500個任務，只占用800M內存。這個參數在>0.21.0已經沒有必要設置了，因為0.21版本改造了completeuserjobs的用法，會盡快的寫入磁盤，不再內存中長期存在了。

11.mapred.jobtracker.update.faulty.tracker.interval，mapred.jobtracker.max.blacklist.percent

一個寫錯的任務，會導致一大批TaskTracker進入黑名單，而且要24小時才能恢復。這種狀況對中小規模的集群性能影響是非常大的。只能通過手工重啟TaskTracker來修復。所以我們就修改了部分JobTracker的代碼，暴露了兩個參數：mapred.jobtracker.update.faulty.tracker.interval控制黑名單重置時間，默認是24小時不能改變，我們現在改成了1小時。

mapred.jobtracker.max.blacklist.percent控制進入黑名單TT的比例，我們改成了0.2。我正在補充這兩個參數的TestCase，準備提交到trunk中。

12. 多用hive少用streaming

由于streaming的方便快捷，我們做了很多基于它的開發。但是由于streaming的任務在運行時還要有一個java進程讀寫stdin/out，有一定的性能開銷。類似的需求最好改用自定義的Deserializer+hive來完成。

感謝各位的閱讀！關于“Hadoop如何優化”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！