分析從管理員角度對Hadoop進行調優

hackeruncle發表於2016-03-24

Hadoop管理員負責為使用者作業提供一個高效的執行環境。管理員需要從全域性出發,透過調整一些關鍵引數值提高系統的吞吐率和效能。總體上看,管理員需從硬體選擇、作業系統引數調優、JVM引數調優和Hadoop引數調優等四個方面人手,為Hadoop使用者提供一個高效的作業執行環境。

1.硬體選擇

Hadoop自身架構的基本特點決定了其硬體配置的選型。Hadoop採用了master/slave架構,其中,master(JobTracker或者NameNode)維護了全域性後設資料資訊,重要性遠遠大幹 slave(TaskTracker或者DataNode)。在較低Hadoop版本中,master均存在單點故障問題,因此,master的配置應遠遠好於各個slave(TaskTracker或者DataNode),具體可參考Eric Sammer的《Hadoop Operations》 -書。

2.作業系統引數調優

由於Hadoop自身的一些特點,它只適合用於將Linux作為作業系統的生產環境。在實際應用場景中,管理員適當對Linux核心引數進行調優,可在一定程度上提高作業的執行效率,比較有用的調整選項如下。

(1)增大同時開啟的檔案描述符和網路連線上限

在Hadoop叢集中,由於涉及的作業和任務數目非常多,對於某個節點,由於作業系統核心在檔案描述符和網路連線數目等方面的限制,大量的檔案讀寫操作和網路連線可能導致作業執行失敗,因此,管理員在啟動Hadoop叢集時,應使用ulimit命令將允許同時開啟的檔案描述符數目上限增大至一個合適的值,同時調整核心引數net.core.somaxconn至一個足夠大的值。
此外,Hadoop RPC採用了epoll作為高併發庫,如果你使用的Linux核心版本在2.6.28以上,你需要適當調整epoll的檔案描述符上限。

(2)關閉swap分割槽

在Linux中,如果一個程式的記憶體空間不足,那麼,它會將記憶體中的部分資料暫時寫到磁碟上,當需要時,再將磁碟上的資料動態置換到記憶體中,通常而言,這種行為會大大降低程式的執行效率。在MapReduce分散式計算環境中,使用者完全可以透過控制每個作業處理的資料量和每個任務執行過程中用到的各種緩衝區大小,避免使用swap分割槽。具體方法是調整/etc/sysctl.conf檔案中的vm.swappiness引數。

(3)設定合理的預讀取緩衝區大小

磁碟I/O效能的發展遠遠滯後於CPU和記憶體,因而成為現代計算機系統的一個主要瓶頸。預讀可以有效地減少磁碟的尋道次數和應用程式的I/O等待時間,是改進磁碟讀I/O效能的重要最佳化手段之一。管理員可使用Linux命令blockdev設定預讀取緩衝區的大小,以提高Hadoop中大檔案順序讀的效能。當然,也可以只為Hadoop系統本身增加預讀緩衝區大小。 

(4)檔案系統選擇與配置

Hadoop的I/O效能很大程度上依賴於Linux本地檔案系統的讀寫效能。Linux中有多種檔案系統可供選擇,比如ext3和ext4,不同的檔案系統效能有一定的差別。如果公司內部有自主研發的更高效的檔案系統,也鼓勵使用。

在Linux檔案系統中,當未啟用noatime屬性時,每個檔案讀操作會觸發一個額外的檔案寫操作以記錄檔案最近訪問時間。該日誌操作可透過將其新增到mount屬性中避免。

(5) 110排程器選擇

主流的Linux發行版自帶了很多可供選擇的I/O排程器。在資料密集型應用中,不同的I/O排程器效能表現差別較大,管理員可根據自己的應用特點啟用最合適的I/O排程器,具體可參考AMD的白皮書《Hadoop Performance Tuning Guide》。 

除了以上幾個常見的Linux核心調優方法外,還有一些其他的方法,管理員可根據需要進行適當調整。

3.JVM引數調優

由於Hadoop中的每個服務和任務均會執行在一個單獨的JVM中,因此,JVM的一些重要引數也會影響Hadoop效能。管理員可透過調整JVM FLAGS和JVM垃圾回收機制提高Hadoop效能,具體可參考AMD的白皮書《Hadoop Performance Tuning Guide》。

4. Hadoop引數調優

1)合理規劃資源

(1)設定合理的槽位數目

在Hadoop中,計算資源是用槽位(slot)表示的。slot分為兩種:Map slot和Reduce slot。每種slot代表了一定量的資源,且同種slot(比如Map slot)是同質的,也就是說,同種slot代表的資源量是相同的。管理員需根據實際需要為TaskTracker配置一定數目的 Map slot和Reduce slot數目,從而限制每個TaskTracker上併發執行的Map Task和Reduce Task數目。

槽位數目是在各個TaskTracker上的mapred-site.xml中配置的,具體如表9-1所示。

表9-1
設定槽位數目


Hadoop版本號

配置引數
預設值
0.20.X(包括1.X),CDH 3
mapred.tasktracker.map.tasks.maximum
mapred.tasktracker.reduce.tasks.maxin,um
2

(兩個引數值相同)
0.21.X, 0.22.X
mapreduce.tasktracker.map.tasks.maximum
mapreduce.tasktracker.reduce.tasks.maximum
2

(兩個基斯信相同)
(2)編寫健康監測指令碼

Hadoop允許管理員為每個TaskTracker配置一個節點健康狀況監測指令碼@。TaskTracker中包含一個專門的執行緒週期性執行該指令碼,並將指令碼執行結果透過心跳機制彙報給 JobTracker。一旦JobTracker發現某個TaskTracker的當前狀況為“不健康”(比如記憶體或者 CPU使用率過高),則會將其加入黑名單,從此不再為它分配新的任務(當前正在執行的任務仍會正常執行完畢),直到該指令碼執行結果顯示為“健康”。健康監測指令碼的編寫和配置的具體方法。

需要注意的是,該機制只有Hadoop 0.20.2以上版本中有。

2)調整心跳配置

(1)調整心跳間隔

TaskTracker與JobTracker之間的心跳間隔大小應該適度。如果太小,JobTracker需要處理高併發的心跳資訊,勢必造成不小的壓力;如果太大,則空閒的資源不能及時通知 JobTracker(進而JJ之分西己新ly.J Tagk),造成資源空閒,進而降叮氐系統{軍吐率。對於中JJ、規模(300個節點以下)的Hadoop叢集,縮短TaskTracker與JobTracker之間的心跳間隔可明顯提高系統吞吐率。

在Hadoop l.0以及更低版本中,當節點叢集規模小於300個節點時,心跳間隔將一直是3秒(不能修改)。這意味著,如果你的叢集有10個節點,那麼JobTracker平均每秒只需處理3.3
(10/3=3.3)個心跳請求;而如果你的叢集有100個節點,那麼JobTracker平均每秒也只需處理33個心跳請求。對於一臺普通的伺服器,這樣的負載過低,完全沒有充分利用伺服器資源。綜上所述,對於中小規模的Hadoop叢集,3秒的心跳間隔過大,管理員可根據需要適當減小心跳間隔@,具體配置如表9—2所示。

表9-2設定心跳間隔


Hadoop版本號

配置引數

預設值
0.20.X, 
0.21.X, 
0.22.X
不可配置
叢集規模小於300時,心跳間隔為3秒,之後每增加100個節點,則心跳間隔增加1秒
1.X,

CDH 3
mapreduce.jobtracker.heartbeat.interval.min
mapred.heartbeats.in.second
mapreduce.jobtracker.heartbeats.scaling.factor
叢集規模小於300時,心跳間隔為300毫秒(具體解釋參考6.3.2小節)
(2)啟用帶外心跳

通常而言,心跳是由各個TaskTracker以固定時間間隔為週期傳送給JobTracker的,心跳中包含節點資源使用情況、各任務執行狀態等資訊。心跳機制是典型的pull-based模型。 TaskTracker週期性透過心跳向JobTracker彙報資訊,同時獲取新分配的任務。這種模型使得任務分配過程存在較大延時:當TaskTracker出現空閒資源時,它只能透過下一次心跳(對於不同規模的叢集,心跳間隔不同,比如1 000個幣點的叢集,心跳間隔為10秒鐘)告訴JobTracker,而不能立刻通知它。為了減少任務分配延遲,Hadoop引入了帶外心跳(out- of-band heartbeat)e。帶外心跳不同於常規心跳,它是任務執行結束或者任務執行失敗時觸發的,能夠在出現空閒資源時第一時間通知JobTracker,以便它能夠迅速為空閒資源分配新的任務。帶外心跳的配置方法如表9-3所示。

表9-3配置帶外心跳


Hadoop版本號

配置引數

含義

預設值
0.20.2
未引入該機制
--
--
0.20.X (除 0.20.2), 0.21.X,
0.22.X, CDH 3
mapreduce.tasktracker.
outofband.heartbeat
是否啟用帶外心跳

false


3)磁碟塊配置

Map Task中間結果要寫到本地磁碟上,對於I/O密集型的任務來說,這部分資料會對本地磁碟造成很大壓力,管理員可透過配置多塊磁碟緩解寫壓力。當存在多塊可用磁碟時, Hadoop將採用輪詢的方式將不同Map Task的中間結果寫到這些磁碟上,從而平攤負載,具體配置如表9-4所示。

表9-4配置多個磁碟塊


Hadoop版本號

配置引數

預設值
0.20.X(包括1.X),CDH 3
mapred.local.dir
/tmp/hadoop-${user.name}/mapred/local
0.21.X, 0.22.X
mapreduce.cluster.local.dir
/tmp/hadoop-${user.name}/mapred/local


4)設定合理的RPC Handler和HTTP執行緒數目

(1)配置RPC Handler數目

JobTracker需要併發處理來自各個TaskTracker的RPC請求,管理員可根據叢集規模和伺服器併發處理能夠調整RPC Handler數目,以使JobTracker服務能力最佳,配置方法如表9-5所示。

表9-5配置RPC Handler數目


Hadoop版本號

配置引數

預設值

0.20.X(包括1X),CDH 3
mapred.job.tracker.handler.count

10
0.21.X, 0.22.X
mapreduce.jobtracker.handler.count

10
(2)配置HTTP執行緒數目

在Shuffle階段,Reduce Task透過HTTP請求從各個TaskTracker上讀取Map Task中間結果,而每個TaskTracker透過Jetty Server處理這些HTTP請求。管理員可適當調整Jetty Server的工作執行緒數以提高Jetty Server的併發處理能力,具體如表9-6所示。

表9-6配置HTTP執行緒數目


Hadoop版本號

配置引數

預設值

0.20.x(包括1.X),CDH 3
tasktracker.http.threads

40
0.21.X, 0.22.X
mapreduce.tasktracker.http.threads

40


5)慎用黑名單機制

當一個作業執行結束時,它會統計在各個TaskTracker上失敗的任務數目。如果一個 TaskTracker失敗的任務數目超過一定值,則作業會將它加到自己的黑名單中。如果一個 TaskTracker被一定數目的作業加入黑名單,則JobTracker會將該TaskTracker加入系統黑名單,此後JobTracker不再為其分配新的任務,直到一定時間段內沒有出現失敗的任務。

當Hadoop叢集規模較小時,如果一定數量的節點被頻繁加入系統黑名單中,則會大大降低叢集吞吐率和計算能力,因此建議關閉該功能,具體配置方法可參考6.5.2小節。

6)啟用批次任務排程

在Hadoop中,排程器是最核心的元件之一,它負責將系統中空閒的資源分配給各個任務。當前Hadoop提供了多種排程器,包括預設的FIFO排程器、Fair Scheduler、Capacity Scheduler等,排程器的排程效率直接決定了系統的吞吐率高低。通常而言,為了將空閒資源儘可能分配給任務,Hadoop排程器均支援批次任務排程e,即一次將所有空閒任務分配下去,而不是一次只分配一個,具體配置如表9.7所示(FIFO排程器本身就是批次排程器)。

表9-7配置批次任務排程


排程器名稱

Hadoop版本

配置引數

引數含義

預設值


0.20.2, 
0.21.X, 
0.22.X
---
---
不支援批次排程,

一次分配一個任務
Capacity
Scheduler
0.20.X(包括 i.x),
CDH 3
mapred.capacity-scheduler.maximum-tasks-per-
heartbeat
每次心跳最多分配的任務數目

32 767

0.20.205之前
---
---
不支援批次排程,

一次分配一個任務

Fair
Scheduler
0.20.205之後, 0.21.X,
0.22.X
mapred.fairscheduler.assignrnultiple
mapred.fairscheduler.assignmultiple.
maps
mapred.fairscheduler.assignmultiple.
reduces
是否啟用批次

排程功能,如果

是,則一次最多分配的Map Task和Reduce Task數目
啟用批次排程功

能,且一次分配Map
Task和Reduce Task的最高數目不受限
7)選擇合適的壓縮演算法

Hadoop通常用於處理I/O密集型應用。對於這樣的應用,Map Task會輸出大量中間資料,這些資料的讀寫對使用者是透明的,如果能夠支援中間資料壓縮儲存,則會明顯提升系統的I/O效能。當選擇壓縮演算法時,需要考慮壓縮比和壓縮效率兩個因素。有的壓縮演算法有很好的壓縮比,但壓縮/解壓縮效率很低;反之,有一些演算法的壓縮/解壓縮效率很高,但壓縮比很低。因此,一個優秀的壓縮演算法需平衡壓縮比和壓縮效率兩個因素。

當前有多種可選的壓縮格式,比如gzip、zip、bzip2、LZO e、Snappy@等,其中,LZO和Snappy在壓縮比和壓縮效率兩方面的表現都比較優秀。其中,Snappy是Google開源的資料壓縮庫,它的編碼/解碼器已經內建到Hadoop l.0以後的版本中@;LZO則不同,它是基於GPL許可的,不能透過Apache來分發許可,因此,它的Hadoop編碼/解碼器必須單獨下載。

下面以Snappy為例介紹如何讓Hadoop壓縮Map Task中間輸出資料結果(在mapred-
site.xml中配置):

mapred. compresg .map. output 

true



mapred. map. output. compression. codec
org. apache .hadoop .iQ. compress. SnappyCodec< /value>



其中,“mapred.compress.map.output”表示是否要壓縮Map Task中間輸出結果,“mapred.map.output.compression.codec”表示採用的編碼/解碼器。

表9-8顯示了Hadoop各版本是否內建了Snappy壓縮演算法。

表9-8配置Snappy壓縮演算法


Hadoop版本號

是否內建Snappy

0.20.X(不包括1.X),0.21.X.0.22.X



1.X, CDH 3




8)啟用預讀取機制

前面提到,預讀取機制可以有效提高磁碟的I/O讀效能。由於Hadoop是典型的順序讀系統,採用預讀取機制可明顯提高HDFS讀效能和MapReduce作業執行效率。管理員可為 MapReduce的資料複製和IFile檔案讀取啟用預讀取功能,具體如表9—9所示。




表9-9配置預讀取功能


Hadoop版本號

配置引數




預設值
Apache各版本和CDH 3 u3以下版本
暫未引入該機制
---
---

mapred.tasktracker.shuffle. fadvise
是否啟用Shuffle預讀取機制

true
CDH 3 u3以及更高
mapred.tasktracker.shuffle.readahead.bytes

Shuffle預讀取緩衝區大小

4 MB
版本
mapreduce.ifile.readahead
是否啟用IFile預讀取機制

true
mapreduce.ifile.readahead.bytes
IFile預讀取緩衝區大小

4 MB


轉:

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30089851/viewspace-2062906/,如需轉載,請註明出處,否則將追究法律責任。

相關文章