性能挑戰(zhàn)

01

?

HDFS 是一個(gè)分布式系統(tǒng)，只要有足夠的資源，可以擴(kuò)容上千個(gè)節(jié)點(diǎn)支持100PB以上的集群。我們發(fā)現(xiàn)Hadoop集群升級(jí)（2.5.0-cdh5.3.2-->2.6.0-cdh5.13.1）以后，NameNode RPC（remote procedure call）queue time在持續(xù)的在間隔一周左右性能惡化，在極端環(huán)境下出現(xiàn)一個(gè)RPC查詢需要等待好幾分鐘的情況，Hive作業(yè)出現(xiàn)大量的同一類型錯(cuò)誤失敗：

Error in org.apache.Hadoop.Hive.ql.exec.mr.MapRedTask. Unable to close file because the last block does not have enough number of replicas.

重啟集群以后問題可以得到緩解，但是這個(gè)問題需要從根本上考慮如何解決。

?

性能優(yōu)化

02

?

RPC變慢的根源在于HDFS的NameNode吞吐量和性能瓶頸。NameNode存在最大吞吐量限制，每一次寫的請(qǐng)求都會(huì)產(chǎn)生排他性“寫鎖”，強(qiáng)制其他任何操作必須在隊(duì)列里等待它完成。NameNode的RPC queue time指標(biāo)可以顯示表達(dá)這個(gè)系統(tǒng)當(dāng)前狀態(tài)。對(duì)此我們主要從代碼和業(yè)務(wù)兩方面進(jìn)行優(yōu)化。

?

Datanode延遲塊匯報(bào)

03

?

1.Datanode的塊匯報(bào)

當(dāng)datanode上新寫完一個(gè)塊，默認(rèn)會(huì)立即匯報(bào)給namenode。在一個(gè)大規(guī)模Hadoop集群上，每時(shí)每刻都在寫數(shù)據(jù)，datanode上隨時(shí)都會(huì)有寫完數(shù)據(jù)塊然后匯報(bào)給namenode的情況。因此namenode會(huì)頻繁處理datanode這種快匯報(bào)請(qǐng)求，會(huì)頻繁地持有鎖，其實(shí)非常影響其他rpc的處理和響應(yīng)時(shí)間。

?

2.優(yōu)化方案

通過延遲快匯報(bào)配置可以減少datanode寫完塊后的塊匯報(bào)次數(shù)，提高namenode處理rpc的響應(yīng)時(shí)間和處理速度。

配置：

<property> <name>dfs.blockreport.incremental.intervalMsec</name> <value>300</value></property>

目前我們HDFS集群上此參數(shù)配置為300毫秒，就是當(dāng)datanode新寫一個(gè)塊，不是立即匯報(bào)給namenode，而是要等待300毫秒，在此時(shí)間段內(nèi)新寫的塊一次性匯報(bào)給namenode。

?

刪除塊個(gè)數(shù)可配置

04

?

由于HDFS的單一鎖設(shè)計(jì)，NN對(duì)于大目錄刪除行為并沒有表現(xiàn)出很好的執(zhí)行效果，嚴(yán)重時(shí)甚至?xí)霈F(xiàn)長時(shí)間block其它應(yīng)用的正常請(qǐng)求處理。Hadoop新版本引入新結(jié)構(gòu)FoldedTreeSet來存儲(chǔ)DN的塊數(shù)據(jù)，但是它并不利于update操作，因此刪除問題在升級(jí)后的版本中體現(xiàn)更為明顯了。我們也在社區(qū)上提了相關(guān)issue：https://issues.apache.org/jira/browse/HDFS-13671。

?

后續(xù)我們?cè)谘芯縃DFS刪除塊的行為中，發(fā)現(xiàn)NN在每次batch刪除塊的時(shí)候，是以固定size按照batch方式定期刪除收集到的塊信息。在每次batch間隙，其它請(qǐng)求就有機(jī)會(huì)得到NN鎖的機(jī)會(huì)。于是我們考慮到一個(gè)改進(jìn)手段，即是否能讓batch size變得更加靈活可配置化，以此來控制給其它請(qǐng)求得到NN鎖處理的概率。

?

基于這個(gè)思路，我們新建了以下配置項(xiàng)，并改動(dòng)了相關(guān)代碼邏輯。???????

<property> <name>dfs.namenode.block.deletion.increment</name> <value>1000</value> <description> The number of block deletion increment. This setting will control the block increment deletion rate to ensure that other waiters on the lock can get in. </description> </property>

此優(yōu)化也已經(jīng)被我們貢獻(xiàn)到Hadoop社區(qū)，相關(guān)JIRA鏈接：https://issues.apache.org/jira/browse/HDFS-13831（點(diǎn)擊閱讀原文即可進(jìn)入頁面）

?

HDFS Federation

05

?

1.獨(dú)立集群模式弊端

在日常HDFS集群維護(hù)過程中，我們發(fā)現(xiàn)HDFS集群獨(dú)立運(yùn)行模式存在著許多弊端：

●獨(dú)立集群模式運(yùn)維成本高，上下線機(jī)器每次都要制定分配所屬集群。

●多獨(dú)立集群模式無非良好均衡資源和請(qǐng)求，經(jīng)常發(fā)現(xiàn)A集群平時(shí)負(fù)載要遠(yuǎn)遠(yuǎn)高于B集群，這本質(zhì)上是資源共享利用的問題。

●單集群模式性能瓶頸問題。

?

綜上，我們對(duì)現(xiàn)有大集群獨(dú)立運(yùn)行模式進(jìn)行了Federation改造。Federation改造的關(guān)鍵前提是不同namespace的Cluster ID必須保持一致，否則DN在上報(bào)過程中會(huì)拋出異常而注冊(cè)失敗。鑒于我們內(nèi)部集群在初始搭建時(shí)指定了統(tǒng)一的Cluster ID，所以并沒有在前期再對(duì)Cluster ID做額外人工轉(zhuǎn)換工作。

?

2.Federation問題解決

在Federation過程中，我們主要遇到了3個(gè)問題：

不同集群拓?fù)浣Y(jié)構(gòu)不一致導(dǎo)致DN注冊(cè)上報(bào)錯(cuò)誤，錯(cuò)誤如下：???????

2019-01-29 14:12:10,821 ERROR [Thread-30] org.apache.Hadoop.HDFS.server.datanode.DataNode: Initialization failed for Block pool BP-1508644862-xx.xx.xx.xx-1493781183457 (Datanode Uuid b8a47300-9fd9-4226-93a1-6649341b3b2c) service to xx.xx.xx.xx:8022 Failed to add /default-rack/xx.xx.xx.xx:50010: You cannot have a rack and a non-rack node at the same level of the network topology.at org.apache.Hadoop.net.NetworkTopology.add(NetworkTopology.java:414)at org.apache.Hadoop.HDFS.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:987)at org.apache.Hadoop.HDFS.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:5264)at org.apache.Hadoop.HDFS.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:1291)at org.apache.Hadoop.HDFS.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:100)at org.apache.Hadoop.HDFS.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:29184)??

?

上述錯(cuò)誤產(chǎn)生的根本原因是DN在Federation注冊(cè)時(shí)在不同的namespace擁有不同level層級(jí)。后面經(jīng)過原因排查，是由于我們沒有完全同步好2個(gè)集群rack-awareness的腳本映射關(guān)系，由配置項(xiàng)net.topology.script.file.name所配置。

?

后續(xù)在DN Federation上報(bào)過程中，我們又遇到了因?yàn)楸镜豥u命令不準(zhǔn)確導(dǎo)致DN capacity容量double的異常，繼而導(dǎo)致DN無非正常進(jìn)行寫數(shù)據(jù)塊行為。因?yàn)镈N在上報(bào)自身capacity容量時(shí)，需要依賴于本地系統(tǒng)du命令來計(jì)算實(shí)際使用空間大小。后面我們對(duì)系統(tǒng)du命令進(jìn)行了校準(zhǔn)修復(fù)，最后DN能正常Federation上報(bào)注冊(cè)。

?

如今，我們已經(jīng)完全打通2個(gè)獨(dú)立大集群，同時(shí)加入第三套NN，來做新的namespace存儲(chǔ)，在未來會(huì)對(duì)數(shù)據(jù)進(jìn)行業(yè)務(wù)劃分，將數(shù)據(jù)均衡打散在不同namespace下，充分利用每個(gè)namespace下NN的處理能力。

?

另外一個(gè)問題是在Federation完成后發(fā)現(xiàn)的。因?yàn)镕ederation過程是將已有獨(dú)立大集群模式改造成Federation模式，而不是直接搭建新Federation集群模式，我們發(fā)現(xiàn)NN元數(shù)據(jù)膨脹地比較厲害，即使block的元數(shù)據(jù)沒有發(fā)生多大變化，但是實(shí)質(zhì)上DN和block的映射是會(huì)得到膨脹的，因此后期馬上對(duì)NN的JVM參數(shù)進(jìn)行了相關(guān)調(diào)整。

?

我們?cè)兄骷旱倪\(yùn)行模式如下，兩個(gè)獨(dú)立大集群運(yùn)作模式：

經(jīng)Federation改造完成的結(jié)構(gòu)如下，?最終效果是所有datanode向全部三套NN匯報(bào)：

客戶端監(jiān)控以及temp目錄分流，Hive本身降低HDFS請(qǐng)求

06

?

1.HDFS客戶端監(jiān)控

客戶端監(jiān)控主要是從HDFS的客戶端角度出發(fā)，監(jiān)控HDFS的rename、create等部分rpc操作或者write這種涉及datanode操作的操作時(shí)長。這是補(bǔ)充HDFS服務(wù)端rpc監(jiān)控的手段之一。

?

出發(fā)點(diǎn)是，有時(shí)服務(wù)端這邊的監(jiān)控比較正常，但是從任務(wù)（Hive，spark或者presto）角度來看，發(fā)現(xiàn)一些move或者load等操作依舊花費(fèi)很長時(shí)間。這意味著服務(wù)端監(jiān)控僅能夠體現(xiàn)服務(wù)端處理性能，并不能很好地衡量整個(gè)集群向外提供服務(wù)的性能。

上圖是rename的平均時(shí)長，考量的是一個(gè)文件被rename后的平均時(shí)長。

上圖write的平均時(shí)長，考量一個(gè)只有少量數(shù)據(jù)的文件被創(chuàng)建時(shí)的平均時(shí)長，通過這個(gè)指標(biāo)可以評(píng)估當(dāng)前namenode的8022端口以及datanode性能。

?

2.temp目錄分流

從上面分析bip以及bip03的文件操作以及rpc情況來看，可以得出如下兩個(gè)結(jié)論：

●占用rpc大頭的是 /mr/staging, /tmp/Hive/HDFS/, /bip/developer/vipdm， 其次還有/tmp/Hive/.Hive-staging， ? ? ?/mr/intermediate_done， /bip

●切換 ? ? ?defaultFs， 明顯影響到 /mr/staging, /tmp/Hive/HDFS/ ，/mr/intermediate_done， 也非常明顯影響了rpc。

●如此，對(duì)temp目錄進(jìn)行分流將會(huì)很大程度影響集群的rpc情況。

?

解決方案如下：

●在Hive引擎層面（或者在調(diào)度層面也ok），平衡切換defaultFs，確保臨時(shí)目錄均衡地分布在bip或者bip03上面。

●采用第三個(gè)集群，將 ? ? ?/mr/staging, /tmp/Hive/HDFS/， ? ? ?/mr/intermediate_done 遷移到上面，簡而言之，就是把defaultFs設(shè)置成第三個(gè)集群(最好可以通過Federation進(jìn)行分流，這樣不會(huì)太大影響數(shù)據(jù)的本地性)。

●使用雙報(bào)，通過自動(dòng)化的方式平衡bip以及bip03的壓力。

?

3.Hive本身降低rpc請(qǐng)求

Hive有很多地方都調(diào)用了HDFS的rpc接口，并發(fā)出大量rpc請(qǐng)求。如果能夠從Hive的rpc客戶方降低rpc請(qǐng)求，也能夠很大程度緩解HDFS的壓力。

●Hive的insert、create等操作產(chǎn)生的臨時(shí)數(shù)據(jù)，需要統(tǒng)一放到非表下，這樣能夠大量減少在最后rename的操作。

●因?yàn)闀簳r(shí)用不上HDFS的Encryption，所以多次的Encryption檢測顯然非常浪費(fèi)性能，可以設(shè)置參數(shù)選擇性關(guān)閉。

?

小文件治理

07

?

小文件問題在大規(guī)模HDFS集群中是經(jīng)常會(huì)遇到的問題。小文件過多引發(fā)的各種性能瓶頸在一定程度上影響了集群穩(wěn)定性。我們采取了以下措施進(jìn)行優(yōu)化改善。

?

1.改進(jìn)措施

●HDFS Federation。相當(dāng)于橫向擴(kuò)展namenode的處理能力，增加namenode數(shù)量來共同分擔(dān)元數(shù)據(jù)管理的壓力。但這并不十全十美，只是暫時(shí)隱藏了小文件多的問題。

●合并小文件。這個(gè)方案說起來簡單，卻也并不容易。針對(duì)Hive相關(guān)任務(wù)，針對(duì)由歷史任務(wù)產(chǎn)生大量小文件的作業(yè)，首先使用CombineHiveInputFormat，將多個(gè)小文件作為一個(gè)整體split，從而減少map數(shù)量，然后配置mapred.min.split.size.per.node和mapred.max.split.size增加map處理的文件大小。這個(gè)方案我們已經(jīng)做成可配置化，用定時(shí)任務(wù)合并用戶歷史作業(yè)產(chǎn)生的數(shù)據(jù)。其次orcfile格式的Hive表，推薦使用CONCATENATE語義，orcfile的合并是stripe級(jí)別，節(jié)省了解壓和格式化數(shù)據(jù)的開銷，增加效率。

?

經(jīng)過一段時(shí)間的努力小文件數(shù)量得到有效改善，如下圖所示:

?

2. 未來終極解決方案：Hadoop Ozone?

Hadoop Ozone是基于 HDFS 實(shí)現(xiàn)的對(duì)象存儲(chǔ)服務(wù)，支持更大規(guī)模數(shù)據(jù)對(duì)象存儲(chǔ)，支持各種對(duì)象大小并且擁有 HDFS 的可靠性、一致性和可用性。Ozone的一大目標(biāo)就是擴(kuò)展 HDFS，使其支持?jǐn)?shù)十億個(gè)對(duì)象的存儲(chǔ)。目前這個(gè)項(xiàng)目已經(jīng)成為 Apache Hadoop 的子項(xiàng)目,我們也會(huì)持續(xù)關(guān)注。

?

本文摘自：維技術(shù)

總結(jié)

以上是生活随笔為你收集整理的唯品会 1000+ 台 Hadoop 集群优化经验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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