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

成都創(chuàng)新互聯(lián)自成立以來，一直致力于為企業(yè)提供從網(wǎng)站策劃、網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、成都網(wǎng)站制作、電子商務(wù)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個性化軟件開發(fā)等基于互聯(lián)網(wǎng)的全面整合營銷服務(wù)。公司擁有豐富的網(wǎng)站建設(shè)和互聯(lián)網(wǎng)應(yīng)用系統(tǒng)開發(fā)管理經(jīng)驗、成熟的應(yīng)用系統(tǒng)解決方案、優(yōu)秀的網(wǎng)站開發(fā)工程師團(tuán)隊及專業(yè)的網(wǎng)站設(shè)計師團(tuán)隊。

1. 網(wǎng)絡(luò)帶寬

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

2. 系統(tǒng)參數(shù)

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

3. 配置文件管理

這個集群用的是Cloudera發(fā)行的版本，配置文件默認(rèn)存在/etc/hadoop/conf位置。這是一個只有root才能修改的位置。為了修改方便，我把配置文件統(tǒng)一保存在一臺機(jī)器上，修改后用腳本分發(fā)。保證所有服務(wù)器都是統(tǒng)一的配置。

4. mapred.tasktracker.map.tasks.maximum

這個參數(shù)控制每個TaskTracker同時運行的Map任務(wù)數(shù)。以前的設(shè)置是和CPU核數(shù)相同的，偶爾遇到任務(wù)擠占DataNode資源的問題?，F(xiàn)在改成map+reduce+1==num_cpu_cores。

5. 嚴(yán)格控制root權(quán)限

Cloudera的發(fā)行版會創(chuàng)建一個hadoop用戶，各種守護(hù)進(jìn)程都應(yīng)該以這個用戶運行。曾經(jīng)有誤操作（/usr/lib/hadoop/bin/hadoop datanode &）導(dǎo)致本地的數(shù)據(jù)目錄被root寫入新文件，于是正確啟動的hadoop用戶進(jìn)程無法讀寫。所以現(xiàn)在的集群服務(wù)器不提供日常的root權(quán)限訪問。

6. Java的GC模式

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

7. 選擇正確的JDK

這個集群有部分服務(wù)器的JDK用的是32位版本，不能創(chuàng)建-Xmx4g以上的進(jìn)程。統(tǒng)一為x64版本的JDK。

8. mapred.reduce.slowstart.completed.maps

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

9. mapred.fairscheduler.preemption

這個參數(shù)設(shè)為了true。以便fairscheduler在用戶最小資源不能滿足時，kill其他人的任務(wù)騰出足夠的資源。集群運行著各種類型的任務(wù)，有些map任務(wù)需要運行數(shù)小時。這個參數(shù)會導(dǎo)致這類任務(wù)被頻繁kill，幾乎無法完成。曾經(jīng)有個任務(wù)在7小時內(nèi)被kill了137次?？梢酝ㄟ^調(diào)整fairscheduler的pool配置解決，給這種任務(wù)單獨配置一個minMap==maxMap的pool。

10. mapred.jobtracker.completeuserjobs.maximum

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

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

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

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

12. 多用hive少用streaming

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

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