Hadoop容易遇到的問(wèn)題有：Namenode/jobtracker單點(diǎn)故障、HDFS小文件問(wèn)題、數(shù)據(jù)處理性能等。為此 “Hadoop Performance Optimization”(HPO)是必要的。本文試著從性能調(diào)優(yōu)的總體原則入手來(lái)了解概要，實(shí)際生產(chǎn)中遇到的問(wèn)題也會(huì)在這個(gè)框架下處理。

Hadoop運(yùn)行環(huán)境：

下面大致給出這四個(gè)層次的調(diào)優(yōu)原則。

1、硬件選型原則

?

2、操作系統(tǒng)調(diào)優(yōu)

1）避免使用swap分區(qū) 將hadoop守護(hù)進(jìn)程的數(shù)據(jù)交換到硬盤的行為可能會(huì)導(dǎo)致操作超時(shí)。

在Linux系統(tǒng)當(dāng)中，如果一個(gè)進(jìn)程的內(nèi)存不足，其內(nèi)存中的部分?jǐn)?shù)據(jù)會(huì)暫時(shí)寫到磁盤上，在需要的時(shí)候，會(huì)再將磁盤中的數(shù)據(jù)動(dòng)態(tài)的置換到內(nèi)存當(dāng)中，這樣一來(lái)，一些不必要的流程就會(huì)顯現(xiàn)出來(lái)。通常，這會(huì)導(dǎo)致進(jìn)程的執(zhí)行效率降低。再分布式環(huán)境當(dāng)中，使用MapReduce這樣的計(jì)算模型時(shí)，可以通過(guò)控制每個(gè)Job的處理數(shù)量和每個(gè)Task運(yùn)行過(guò)程使用的緩沖區(qū)的大小，避免我們?nèi)ナ褂肧wap分區(qū)。通過(guò)/etc/sysctl.conf文件中的vm.swappiness參數(shù)來(lái)達(dá)到目的。

2）調(diào)整內(nèi)存分配策略：操縱系統(tǒng)內(nèi)核根據(jù)vm.oversommit_memory 的值來(lái)決定分配策略，并且通過(guò)vm.overcommit_ratio的值來(lái)設(shè)定超過(guò)物理內(nèi)存的比例。

3）修改net.core.somaxconn參數(shù)：

該參數(shù)表示socker監(jiān)聽backlog的上限，默認(rèn)為128,socker的服務(wù)器會(huì)一次性處理backlog中的所有請(qǐng)求，hadoop的ipc.server.listen.queue.size參數(shù)和linux的net.core.somaxconn

參數(shù)控制了監(jiān)聽隊(duì)列的長(zhǎng)度，需要調(diào)大。

4）增大同時(shí)打開文件描述符的上限

對(duì)內(nèi)核來(lái)說(shuō)，所有打開的文件都通過(guò)文件描述符引用，文件描述符是一個(gè)非負(fù)整數(shù)，hadoop的作業(yè)經(jīng)常會(huì)讀寫大量文件，需要增大同時(shí)打開文件描述符的上限。

5）選擇合適的文件系統(tǒng)，并禁用文件的訪問(wèn)時(shí)間

ext4 xfs ,文件訪問(wèn)時(shí)間可以讓用戶知道那些文件近期被查看或修改，但對(duì)hdfs來(lái)說(shuō)， 獲取某個(gè)文件的某個(gè)塊 被修改過(guò)，沒有意義，可以禁用。

6）關(guān)閉THP(transparent Huge Pages)

THP 是一個(gè)使管理Huge Pages自動(dòng)化的抽象層， 它會(huì)引起cpu占用率增大， 需要關(guān)閉。

echo never> /sys/kernel/mm/redhat_transparent_hugepage/defrag

echo never> /sys/kernel/mm/redhat_transparent_hugepage/enabled

echo never> /sys/kernel/mm/transparent_hugepage/enabled

echo never> /sys/kernel/mm/transparent_hugepage/defrag

7）增大網(wǎng)絡(luò)連接上限

在Hadoop集群當(dāng)中，其內(nèi)部的一些通信依賴網(wǎng)絡(luò)，需調(diào)整Linux參數(shù)net.core.somaxconn，讓其處于一個(gè)足夠大的狀態(tài)。

8）預(yù)讀取

磁盤IO性能沒有CPU和內(nèi)存這樣發(fā)展迅猛，因而它成為OS當(dāng)中一個(gè)主要的性能瓶頸。改進(jìn)磁盤IO性能也是重要的優(yōu)化手段之一?？梢允褂肔inux的blockdev命令來(lái)設(shè)置預(yù)讀取的緩沖區(qū)大小，以便提高Hadoop的文件讀取性能。

3、JVM調(diào)優(yōu)

JVM本身的調(diào)優(yōu)，實(shí)際還是和OS以及Hadoop結(jié)合，如mapreduce作業(yè)的堆內(nèi)存執(zhí)行設(shè)置。

在YARN里面，可以啟用JVM的重用機(jī)制來(lái)得到性能的提升。啟用該功能能夠讓一些Task的執(zhí)行效率提高2～3倍。

YARN的默認(rèn)配置會(huì)禁用該組件，即不允許重用JVM。首先，我們需要明白YARN是如何執(zhí)行一個(gè)MapReduce的Job。其步驟如下所示：

1）RM（Resource Manager）里面的AM（Application Manager）會(huì)為每個(gè)Application（一個(gè)MR的Job）在NM（NodeManager）里面申請(qǐng)一個(gè)Container

2）在申請(qǐng)到的Container里面啟動(dòng)一個(gè)Application Master，Container在YARN中分配資源的容器（內(nèi)存、CPU、磁盤空間等），它啟動(dòng)便會(huì)對(duì)應(yīng)的啟動(dòng)一個(gè)JVM

3）ApplicationMaster會(huì)持續(xù)為Application包含的每一個(gè)Task（一個(gè)Map Task或者Reduce Task）向RM申請(qǐng)一個(gè)Container

4）每得到一個(gè)Container，該Container所屬的NM將此Container啟動(dòng)

5）該Container執(zhí)行對(duì)應(yīng)的Task

6）對(duì)應(yīng)的Task執(zhí)行完畢，該Container被NM回收，而Container所擁有的JVM相應(yīng)的推出

通過(guò)上述的流程可以看出，這種情況下，每一個(gè)JVM僅只執(zhí)行了一個(gè)Task，JVM并未被重用。

因而，用戶可以通過(guò)啟用ubertask屬性來(lái)重用JVM，在同一個(gè)Container里面一次執(zhí)行多個(gè)Task，可以在mapred-site.xml中配置對(duì)應(yīng)的參數(shù)即可，內(nèi)容如下所示：

<property>

<name>mapreduce.job.ubertask.enable</name>

<value>true</value>

</property>

如果啟用該功能，會(huì)將一個(gè)Application中的所有子Task在同一個(gè)JVM里面執(zhí)行，到達(dá)JVM重用的目的。該JVM負(fù)責(zé)Application中的Application Master中所用的JVM，即運(yùn)行在Container當(dāng)中。

最后，當(dāng)ubertask功能被啟用的時(shí)候，YARN是如何執(zhí)行一個(gè)application的。首先，RM里的AM會(huì)為每一個(gè)Application在NM里面申請(qǐng)一個(gè)Container，然后在該container里面啟動(dòng)一個(gè)Application Master。Containe啟動(dòng)時(shí)便會(huì)相應(yīng)啟動(dòng)一個(gè)JVM。此時(shí)，如果ubertask功能被啟用，Application Master會(huì)在JVM中按照順序依次在Container中執(zhí)行每一個(gè)Task，這樣Application Master便不用再為每一個(gè)Task向RM去申請(qǐng)一個(gè)單獨(dú)的Container，從而達(dá)到了重用JVM（資源重用）的目的。

4、Hadoop調(diào)優(yōu)

4.1 HDFS調(diào)優(yōu)

1）設(shè)置合理的塊大小(dfs.block.size)

2）將中間結(jié)果目錄設(shè)置為分布在多個(gè)硬盤以提升寫入速度(mapred.local.dir)

3）設(shè)置datanode處理RPC的線程數(shù)，大集群可以適當(dāng)加大（dfs.datanode.handler.count）,默認(rèn)為3，可以適當(dāng)加大為10

4）設(shè)置namenode能同時(shí)處理的請(qǐng)求數(shù)，(dfs.namenode.handler.count),為集群模式的自然對(duì)數(shù)(lnN)的20倍。

?

4.2 YARN調(diào)優(yōu)

yarn的資源表示模型為ceontainer（容器）,container 將資源抽象為兩個(gè)維度，內(nèi)存和虛擬cpu(vcore)

1）兼容各種計(jì)算框架

2）動(dòng)態(tài)分配資源，減少資源浪費(fèi)

容器內(nèi)存yarn.nodemanager.resource.memory-mb

最小容器內(nèi)存yarn.scheduler.minimum-allocation-mb

容器內(nèi)存增量yarn.scheduler.increment-allocation-mb

最大容器內(nèi)存yarn.scheduler.maximum-allocation-mb

容器虛擬cpu內(nèi)核yarn.nodemanager.resource.cpu-vcores

最小容器虛擬cpu內(nèi)核數(shù)量yarn.scheduler.minimum-allocation-vcores

容器虛擬cpu內(nèi)核增量yarn.scheduler.increment-allocation-vcores

最大容器虛擬cpu內(nèi)核數(shù)量yarn.scheduler.maximum-allocation-vcores

?

4.3 MapReduce調(diào)優(yōu)，調(diào)優(yōu)三大原則

1）增大作業(yè)并行程度

2）給每個(gè)任務(wù)足夠的資源

3）在滿足前2個(gè)條件下，盡可能的給shuffle預(yù)留資源。

參考hadoop官網(wǎng)對(duì)參數(shù)配置的說(shuō)明，結(jié)合實(shí)際問(wèn)題做調(diào)優(yōu)。在對(duì)Hadoop調(diào)優(yōu)時(shí)，這是一個(gè)龐大的任務(wù)，這里進(jìn)行分解來(lái)看，按Hadoop的組成模塊來(lái)分，比如HDFS、MapReduce、YARN等模塊去優(yōu)化對(duì)應(yīng)的模塊。若是在細(xì)分，我們可以優(yōu)化其各個(gè)組件的相關(guān)配置文件，其每個(gè)模塊都有對(duì)應(yīng)的XML文件，在系統(tǒng)啟動(dòng)時(shí)，會(huì)通過(guò)Configure加載到系統(tǒng)當(dāng)中，而對(duì)應(yīng)的XML文件當(dāng)中，配置的參數(shù)和屬性比較多，有些參數(shù)是根據(jù)業(yè)務(wù)本身去優(yōu)化，如：心跳間隔、緩沖區(qū)大小、JVM子進(jìn)程最大內(nèi)存、小文件的合并數(shù)、歸并map輸出數(shù)據(jù)占比等等。

　　另外，在處理一些IO密集的應(yīng)用，會(huì)在執(zhí)行MapReduce時(shí)產(chǎn)生大量的中間輸出數(shù)據(jù)（Map Task執(zhí)行階段），而產(chǎn)生的這些數(shù)據(jù)對(duì)于使用者來(lái)說(shuō)是并不關(guān)心的（透明化）。這里，可以思考一下，有木有一種辦法能夠集中處理這些輸出數(shù)據(jù)。答案是肯定的，在MapReduce中支持壓縮算法，我們可以在執(zhí)行這部分流程時(shí)，將中間輸出數(shù)據(jù)壓縮存儲(chǔ)，這樣在IO性能方面有會(huì)有明顯的提升。然而，萬(wàn)物皆有因果，在選擇壓縮算法時(shí)，需考慮壓縮比和壓縮效率，在一些壓縮算法當(dāng)中，有的壓縮比非常可觀，然而其壓縮效率卻非常低下；反之，有的壓縮比較差，然其壓縮效率非常理想。因?yàn)?#xff0c;我們需要在壓縮比和壓縮效率之間做一個(gè)平衡，選擇合適的算法，去平衡二者的關(guān)系。

　　目前，存在許多的壓縮格式，如：GZIP，ZIP，LZO，Snappy等等，測(cè)試表明其中LZO和Snappy較為可觀（具體量化指標(biāo)圖不方便給出）。當(dāng)然，這個(gè)也不是絕對(duì)的，是當(dāng)下業(yè)務(wù)去測(cè)試，然后選擇合適的壓縮格式。

　　上面提點(diǎn)過(guò)預(yù)讀取機(jī)制，可以通過(guò)預(yù)讀取機(jī)制來(lái)有效的提升磁盤IO的讀性能。通過(guò)改機(jī)制提高HDFS的讀性能以及MapReduce作業(yè)的執(zhí)行效率。

　　當(dāng)然，從應(yīng)用程序也是有優(yōu)化的空間的，處理應(yīng)用程序當(dāng)中配置必要的作業(yè)參數(shù)之外，其本身的編寫方式對(duì)性能也是有影響的。在執(zhí)行一大批MapReduce作業(yè)時(shí)，若是設(shè)置一個(gè)Combiner，對(duì)于提供作業(yè)的性能大有裨益。在了解MapReduce（其分兩部分，其一為計(jì)算模型，其二為運(yùn)行環(huán)境，盡管Hadoop版本升級(jí)到2.x，然其計(jì)算模型不變，變得只是其運(yùn)行環(huán)境。其運(yùn)行環(huán)境是基于YARN的資源管理）的計(jì)算模型時(shí)，在弄明白Combiner階段的好處后，會(huì)發(fā)現(xiàn)，我們?cè)诰帉懴嚓P(guān)作業(yè)時(shí)，添加Combiner可減少M(fèi)ap Task的中間輸出結(jié)果，從而減少各個(gè)Reduce Task的遠(yuǎn)程Copy數(shù)據(jù)量，最終帶來(lái)的益處是縮短了Map和Reduce兩者的執(zhí)行時(shí)間。

　　同樣，我們?cè)谶x擇Hadoop的相關(guān)類型時(shí)，如Writeable。在MapReduce中，Map Task和Reduce Task的輸入和輸出的數(shù)據(jù)類型均為Writable的衍生類型，其包含IntWritable、LongWriteable、FloatWritable等。在編寫相關(guān)代碼時(shí)，選擇合適的類型可以大大提升其性能。例如在處理整型數(shù)據(jù)之時(shí)，直接采用IntWritable比先以Text類型讀取在通過(guò)對(duì)應(yīng)的方法轉(zhuǎn)化為整型來(lái)的高效。

總結(jié)

以上是生活随笔為你收集整理的Hadoop性能调优概要说明的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。