搜索離線dump集群(hadoop&hbase)2013進(jìn)行了幾次重大升級(jí)：

2013-04

第一階段，主要是升級(jí)hdfs為2.0版本，mapreduce仍舊是1.0;同時(shí)hbase也進(jìn)行了一次重大升級(jí)（0.94.5版本），hive升級(jí)到0.9.0；

2013-09，2013-12

第二階段，主要升級(jí)mapreduce到2.0版本即(YARN),hive升級(jí)到0.10.0,在13年年底的時(shí)候?qū)base進(jìn)行了一次小版本升級(jí)；

至此，dump離線集群完全進(jìn)入2.0時(shí)代：

通過升級(jí)hdfs 2.0優(yōu)化shortcircuit read,使用domain socket通信等等提升了效率，加快了任務(wù)運(yùn)行速度,同時(shí)支持成熟的NAMENODE HA，F(xiàn)ederation，解決了讓大家擔(dān)心的集群NN單點(diǎn)問題，集群容量和擴(kuò)展性得到大大提升。

通過升級(jí)yarn對(duì)集群資源進(jìn)行更有效的管理，摒棄了slots的物理劃分，采用內(nèi)存資源控制使集群資源被更有效的利用，從而提高整個(gè)集群的吞吐，同時(shí)支持豐富的計(jì)算框架，為后續(xù)DUMP應(yīng)用架構(gòu)優(yōu)化調(diào)整提供了廣闊的舞臺(tái)。

當(dāng)然集群的升級(jí)過程也遇到了很多問題和困難

第一階段升級(jí)過程中遇到的主要問題：

1、hdfs升級(jí)為2.0后,需要同時(shí)升級(jí)下hive版本(hive-0.9.0-cdh4.1),之前使用老版本hive jar編譯的任務(wù)需要使用新版本jar包重新編譯

2、mr1任務(wù)要運(yùn)行在hdfs 2.0上部分任務(wù)會(huì)運(yùn)行失敗，主要是2.0中將原來的class換成了interface,需要重新編譯即可，少量代碼需要添加下throws IOException，依賴的hadoop-core jar包也被拆分成了幾個(gè)(common,hdfs,mr1等)

3、hdfs shell命令差異，主要是針對(duì)mkdir或者touchz等中間如果有不存在的路徑不會(huì)自動(dòng)創(chuàng)建

4、從云梯distcp數(shù)據(jù)由于hdfs版本不兼容，必須使用hftp的方式,且因hftp不支持密碼訪問，后來patch解決

5、升級(jí)hdfs 2.0后集群整體讀I/O升高明顯，從而導(dǎo)致特別是I/O需求高的build任務(wù)延時(shí)

原因是2.0對(duì)dfs.client.read.shortcircuit的調(diào)整，在檢查是否有權(quán)限(dfs.block.local-path-access.user中配置的用戶名)進(jìn)行shortcircuit讀取時(shí)如果沒有權(quán)限會(huì)將本地的datanode作為deadnode處理，然后數(shù)據(jù)通過遠(yuǎn)程讀取。又因?yàn)閔base中dfs.client.read.shortcircuit.buffer.size設(shè)置的值不合適導(dǎo)致多讀了很多無謂的數(shù)據(jù)，導(dǎo)致整個(gè)集群I/O升高。

解決方案：

設(shè)置dfs.client.read.shortcircuit.buffer.size=16K與hbase的block的大小相匹配。

詳細(xì)的分析過程見：

http://www.atatech.org/article/detail/2733/193

http://www.atatech.org/article/detail/7207/193

第二階段升級(jí)遇到的主要問題：

1、升級(jí)到y(tǒng)arn后，Capacity Schedule進(jìn)行了更新，job提交只需要指定葉子queue名字即可，指定全路徑會(huì)報(bào)錯(cuò)；

2、沒有了map/reduce slots的概念，集群只需配置可用的內(nèi)存大小，主要的參數(shù)：

集群：

yarn.nodemanager.resource.memory-mb：                            一個(gè)nodemanager上可分配給container使用的物理內(nèi)存大小
yarn.scheduler.minimum-allocation-mb：                                  resource manage分配內(nèi)存的最小粒度，暫設(shè)成1024，job提交需要內(nèi)存必須為此參數(shù)的整數(shù)倍
yarn.scheduler.capacity.<queue>.maximum-am-resource-percent：   am所占資源比例，可按queue設(shè)，暫設(shè)成0.3
yarn.scheduler.capacity.<queue>.user-limit-factor：            單個(gè)用戶提交job限制，可按queue設(shè)，單用戶如要搶占最大資源，需要設(shè)大

應(yīng)用：

mapreduce.map.memory.mb,mapreduce.reduce.memory.mb：          map，reduce的內(nèi)存數(shù)，默認(rèn)是1024,2048，如需設(shè)大，必須是1024的整數(shù)倍,可以簡(jiǎn)單理解為之前的slots數(shù)配置
mapreduce.map.java.opts,mapreduce.reduce.java.opts：           java child進(jìn)程的jvm heap大小，比上面的值小些
mapreduce.job.reduce.slowstart.completedmaps：                      對(duì)于map數(shù)較多需要跑多輪，可以設(shè)大此值，延遲reduce啟動(dòng)避免占用資源

3、yarn中不在兼容commons-cli-2.0-SNAPSHOT.jar，之前通過將該jar文件copy到hadoop classpath中使用的應(yīng)用需要部署到各自應(yīng)用的相關(guān)目錄下，并在提交任務(wù)的時(shí)候引用

4、一些使用0.19等老版本的hadoop-streaming.jar需要更換為新版本

5、container內(nèi)存超配被kill掉,考慮到j(luò)ob內(nèi)存的自然增長(zhǎng)及一些使用共享內(nèi)存的任務(wù)，所以設(shè)置yarn.nodemanager.vmem-pmem-ratio=false關(guān)閉物理內(nèi)存檢查

6、客戶端向AM獲取job status報(bào)錯(cuò):IOException

原因是AM內(nèi)存設(shè)置太小，頻繁GC導(dǎo)致,通過調(diào)大yarn.app.mapreduce.am.resource.mb解決

7、c2c_merge任務(wù)在yarn上運(yùn)行緩慢

經(jīng)過排查分析是因使用的mmap文件在pagecache中頻繁換進(jìn)換出導(dǎo)致,根本原因還是18與32內(nèi)核的差異，因?yàn)榧荷?jí)過程中也對(duì)內(nèi)核進(jìn)行了升級(jí)，通過修改應(yīng)用代碼。

去除madvise設(shè)置的MADV_SEQUENTIA后問題解決，參考：

http://baike.corp.taobao.com/index.php/Kbuild在32內(nèi)核上性能退化問題

8、IPV4和IPV6差異引起的長(zhǎng)短機(jī)器名問題及job data local比例低的問題

在yarn resource manager下顯示部分機(jī)器是長(zhǎng)機(jī)器名，部分機(jī)器是短機(jī)器名。

hbase集群下顯示全是長(zhǎng)機(jī)器名,原因是yarn與hbase獲取機(jī)器名調(diào)用的方法不一樣，得到的結(jié)果也不一樣，導(dǎo)致resourcemanager在分配container時(shí)進(jìn)行優(yōu)先的host匹配是匹配不上，最后變成任意匹配導(dǎo)致。

獲取機(jī)器名差異的根本原因經(jīng)過分析是java處理ipv6有bug和yarn腳本bug共同導(dǎo)致。

http://bugs.sun.com/view_bug.do?bug_id=7166687

http://www.atatech.org/article/detail/10731/193

解決方案1：修改yarn腳本，并提交issue到社區(qū):https://issues.apache.org/jira/browse/YARN-1226

解決方案2：給集群配置上機(jī)架感知，且讓一個(gè)機(jī)器一個(gè)rack的虛擬機(jī)架配置，通過rack匹配繞開任意匹配，在http://www.atatech.org/article/detail/10731/193 中有詳細(xì)分析

9、由于我們當(dāng)時(shí)在方案1還未得出結(jié)論前臨時(shí)采用方案2快速解決線上data local低的問題后發(fā)現(xiàn)有部分任務(wù)提交失敗報(bào)錯(cuò): Max block location exceeded for split

原因是:配置了一個(gè)節(jié)點(diǎn)一個(gè)機(jī)架后CombineFileInputFormat獲取split的block localtion時(shí)會(huì)根據(jù)block分布在哪些rack上獲取locations信息，由于機(jī)架數(shù)等同于機(jī)器數(shù)，獲取到的localtions數(shù)會(huì)超過集群的默認(rèn)配置：

mapreduce.job.max.split.locations = 10，而yarn上修改了代碼會(huì)在超出這個(gè)配置值時(shí)拋出異常，所以任務(wù)提交失敗。

解決方案1：增大mapreduce.job.max.split.locations和集群節(jié)點(diǎn)數(shù)一致；

解決方案2：patch修改JobSplitWriter中超過配置值拋異常為打印警告日志，與升級(jí)前一致。

詳情見:http://www.atatech.org/article/detail/11707/193

10、gcih不能正常工作

GCIH：http://baike.corp.taobao.com/index.php/GCIH

不能正常工作的原因有兩個(gè)：

• 集群升級(jí)到y(tǒng)arn后，nm管理job臨時(shí)目錄和distribute file的方式與tt不同，導(dǎo)致GCIH會(huì)生成多個(gè)mmap文件gcih.dat
• 在修復(fù)上述問題的過程中，發(fā)現(xiàn)散列到不同磁盤上task，jvm classpath加載順序不一致，導(dǎo)致GCIH不能正常工作

解決方案：升級(jí)GCIH

將gcih.dat生成到gcih.jar軟連對(duì)應(yīng)的源目錄下，這樣一個(gè)job只會(huì)有一個(gè)，調(diào)整gcih.jar的加載順序，放到preload里。

11、集群資源使用100%,job一直hang住

當(dāng)集群root跑滿100%而下面的子queue未滿時(shí)（因?yàn)橄Ｍ旱馁Y源共享競(jìng)爭(zhēng)，queue的最大可用資源會(huì)進(jìn)行適當(dāng)?shù)某?，不會(huì)觸發(fā)搶占reduce資源的過程。

解決方案：

• 不同queue的大任務(wù)盡量避開運(yùn)行
• 后續(xù)patch修改在root滿時(shí)觸發(fā)搶占

詳細(xì)分析過程見：http://www.atatech.org/article/detail/10924/193

12、load任務(wù)寫hbase偶爾會(huì)卡住

原因是當(dāng)集群中有節(jié)點(diǎn)掛掉或者網(wǎng)絡(luò)等出現(xiàn)異?？赡軙?huì)導(dǎo)致hbaseclient在select時(shí)無線等待，而鎖無法釋放

解決方案：在hbase client的代碼里設(shè)置超時(shí)時(shí)間。

具體原因分析見：http://www.atatech.org/article/detail/9061/193

13、集群有節(jié)點(diǎn)出現(xiàn)問題，上面的任務(wù)一直失敗，后續(xù)別的任務(wù)起來后還會(huì)將container分配到這個(gè)節(jié)點(diǎn)。原因是yarn和之前mr1黑名單機(jī)制發(fā)生了改變，mr1是全局的黑名單，一旦被加入黑名單后續(xù)任務(wù)不會(huì)再分配，yarn的黑名單是在AM上的，也就是任務(wù)級(jí)別的，被AM加入黑名單后可以保證當(dāng)前任務(wù)不會(huì)被分配上去，但是其他任務(wù)的AM中是沒有這個(gè)信息的，所以還是會(huì)分配任務(wù)上去。

解決方案：等待NM將節(jié)點(diǎn)健康信息匯報(bào)給RM,RM將節(jié)點(diǎn)從集群摘除

如果一直無法匯報(bào)，可以通過yarn支持的外圍用戶腳本來做健康檢查和匯報(bào)(需要在yarn配置中配置該腳本)

詳細(xì)分析見：http://www.atatech.org/article/detail/11266/193

hive相關(guān)：

1、out join被拆成多個(gè)job

問題發(fā)現(xiàn)：loader在做多表join的過程時(shí)原來的一個(gè)job被hive拆成了8個(gè)job，耗時(shí)由原來的3分鐘變成30分鐘。

通過patch解決,參考：

http://mail-archives.apache.org/mod_mbox/hive-user/201305.mbox/+r2mdv_tsofa@mail.gmail.com>

https://issues.apache.org/jira/browse/HIVE-4611

2、設(shè)置mapreduce.map.tasks不生效

分析是Hive的InputFormat的問題。

如InputFormat設(shè)置為org.apache.hadoop.hive.ql.io.CombineHiveInputFormat，需要設(shè)置mapreduce.input.fileinputformat.split.maxsize來控制map的個(gè)數(shù)；

如InputFormat設(shè)置為org.apache.hadoop.hive.ql.io.HiveInputFormat，則此參數(shù)生效；

解決方案：將hive配置中默認(rèn)的InputFormat配置成org.apache.hadoop.hive.ql.io.HiveInputFormat

3、寫redis的hive job拆成了兩個(gè)job

hive默認(rèn)設(shè)置中，當(dāng)map輸出文件太小，會(huì)新起一個(gè)job合并小文件

解決方案：set hive.merge.mapfiles=false;

仍然存在待解決的問題：

1)有部分job會(huì)導(dǎo)致單disk io到100%,拖慢這個(gè)任務(wù)；

2)機(jī)器出現(xiàn)異常問題，task全部都在localizing，job一直pending,只能kill掉重新提交；

3)job或者task被kill掉后，日志也被刪除，history中看不到該job的信息，排查問題困難；

集群HADOOP 2.0的升級(jí)，在更好的支持現(xiàn)有業(yè)務(wù):主搜，商城，店鋪內(nèi)，PORA個(gè)性化，尼米茲平臺(tái)，中文站(offer,company,minisearch),國(guó)際站(ae,sc,p4p,aep4p,scp4p)的基礎(chǔ)上為后續(xù)離線dump平臺(tái)：ADUMP的建設(shè)夯實(shí)了基礎(chǔ)。

一個(gè)統(tǒng)一存儲(chǔ)，模塊插件化設(shè)計(jì)，減少各業(yè)務(wù)線之間數(shù)據(jù)冗余，避免重復(fù)開發(fā)，同時(shí)支持快速響應(yīng)各條業(yè)務(wù)線新需求的全新平臺(tái)ADUMP將在3月底左右上線，緊跟集群升級(jí)的節(jié)奏，離線DUMP也將馬上進(jìn)入2.0時(shí)代，敬請(qǐng)期待!