淘寶主搜索離線集群完成Hadoop 2.0升級(jí)
搜索離線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í)代：
通過(guò)升級(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)問(wèn)題，集群容量和擴(kuò)展性得到大大提升。
通過(guò)升級(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í)過(guò)程也遇到了很多問(wèn)題和困難
第一階段升級(jí)過(guò)程中遇到的主要問(wèn)題：
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中將原來(lái)的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不支持密碼訪問(wèn)，后來(lái)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í)如果沒(méi)有權(quán)限會(huì)將本地的datanode作為deadnode處理，然后數(shù)據(jù)通過(guò)遠(yuǎn)程讀取。又因?yàn)閔base中dfs.client.read.shortcircuit.buffer.size設(shè)置的值不合適導(dǎo)致多讀了很多無(wú)謂的數(shù)據(jù)，導(dǎo)致整個(gè)集群I/O升高。
解決方案：
設(shè)置dfs.client.read.shortcircuit.buffer.size=16K與hbase的block的大小相匹配。
詳細(xì)的分析過(guò)程見(jiàn)：
http://www.atatech.org/article/detail/2733/193
http://www.atatech.org/article/detail/7207/193
第二階段升級(jí)遇到的主要問(wèn)題：
1、升級(jí)到y(tǒng)arn后，Capacity Schedule進(jìn)行了更新，job提交只需要指定葉子queue名字即可，指定全路徑會(huì)報(bào)錯(cuò)；
2、沒(méi)有了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，之前通過(guò)將該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)致,通過(guò)調(diào)大yarn.app.mapreduce.am.resource.mb解決
7、c2c_merge任務(wù)在yarn上運(yùn)行緩慢
經(jīng)過(guò)排查分析是因使用的mmap文件在pagecache中頻繁換進(jìn)換出導(dǎo)致,根本原因還是18與32內(nèi)核的差異，因?yàn)榧荷?jí)過(guò)程中也對(duì)內(nèi)核進(jìn)行了升級(jí)，通過(guò)修改應(yīng)用代碼。
去除madvise設(shè)置的MADV_SEQUENTIA后問(wèn)題解決，參考：
http://baike.corp.taobao.com/index.php/Kbuild在32內(nèi)核上性能退化問(wèn)題
8、IPV4和IPV6差異引起的長(zhǎng)短機(jī)器名問(wèn)題及job data local比例低的問(wèn)題
在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)過(guò)分析是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ī)架配置，通過(guò)rack匹配繞開(kāi)任意匹配，在http://www.atatech.org/article/detail/10731/193 中有詳細(xì)分析
9、由于我們當(dāng)時(shí)在方案1還未得出結(jié)論前臨時(shí)采用方案2快速解決線上data local低的問(wèn)題后發(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ì)超過(guò)集群的默認(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中超過(guò)配置值拋異常為打印警告日志，與升級(jí)前一致。
詳情見(jiàn):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ù)上述問(wèn)題的過(guò)程中，發(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資源的過(guò)程。
解決方案：
- 不同queue的大任務(wù)盡量避開(kāi)運(yùn)行
- 后續(xù)patch修改在root滿時(shí)觸發(fā)搶占
詳細(xì)分析過(guò)程見(jiàn)：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í)無(wú)線等待，而鎖無(wú)法釋放
解決方案：在hbase client的代碼里設(shè)置超時(shí)時(shí)間。
具體原因分析見(jiàn)：http://www.atatech.org/article/detail/9061/193
13、集群有節(jié)點(diǎn)出現(xiàn)問(wèn)題，上面的任務(wù)一直失敗，后續(xù)別的任務(wù)起來(lái)后還會(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中是沒(méi)有這個(gè)信息的，所以還是會(huì)分配任務(wù)上去。
解決方案：等待NM將節(jié)點(diǎn)健康信息匯報(bào)給RM,RM將節(jié)點(diǎn)從集群摘除
如果一直無(wú)法匯報(bào)，可以通過(guò)yarn支持的外圍用戶腳本來(lái)做健康檢查和匯報(bào)(需要在yarn配置中配置該腳本)
詳細(xì)分析見(jiàn)：http://www.atatech.org/article/detail/11266/193
hive相關(guān)：
1、out join被拆成多個(gè)job
問(wèn)題發(fā)現(xiàn)：loader在做多表join的過(guò)程時(shí)原來(lái)的一個(gè)job被hive拆成了8個(gè)job，耗時(shí)由原來(lái)的3分鐘變成30分鐘。
通過(guò)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的問(wèn)題。
如InputFormat設(shè)置為org.apache.hadoop.hive.ql.io.CombineHiveInputFormat，需要設(shè)置mapreduce.input.fileinputformat.split.maxsize來(lái)控制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;
仍然存在待解決的問(wèn)題：
1)有部分job會(huì)導(dǎo)致單disk io到100%,拖慢這個(gè)任務(wù)；
2)機(jī)器出現(xiàn)異常問(wèn)題，task全部都在localizing，job一直pending,只能kill掉重新提交；
3)job或者task被kill掉后，日志也被刪除，history中看不到該job的信息，排查問(wèn)題困難；
集群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ù)開(kāi)發(fā)，同時(shí)支持快速響應(yīng)各條業(yè)務(wù)線新需求的全新平臺(tái)ADUMP將在3月底左右上線，緊跟集群升級(jí)的節(jié)奏，離線DUMP也將馬上進(jìn)入2.0時(shí)代，敬請(qǐng)期待!
