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

2013-04

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

2013-09，2013-12

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

至此，dump離線集群完全進入2.0時代：

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

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

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

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

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

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

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

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

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

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

解決方案：

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

詳細的分析過程見：

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

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

第二階段升級遇到的主要問題：

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

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

集群：

yarn.nodemanager.resource.memory-mb：                            一個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：            單個用戶提交job限制，可按queue設(shè)，單用戶如要搶占最大資源，需要設(shè)大

應(yīng)用：

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

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

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

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

6、客戶端向AM獲取job status報錯:IOException

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

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

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

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

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

8、IPV4和IPV6差異引起的長短機器名問題及job data local比例低的問題

在yarn resource manager下顯示部分機器是長機器名，部分機器是短機器名。

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

獲取機器名差異的根本原因經(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：給集群配置上機架感知，且讓一個機器一個rack的虛擬機架配置，通過rack匹配繞開任意匹配，在http://www.atatech.org/article/detail/10731/193 中有詳細分析

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

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

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

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

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

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

10、gcih不能正常工作

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

不能正常工作的原因有兩個：

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

解決方案：升級GCIH

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

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

當(dāng)集群root跑滿100%而下面的子queue未滿時（因為希望集群的資源共享競爭，queue的最大可用資源會進行適當(dāng)?shù)某?，不會觸發(fā)搶占reduce資源的過程。

解決方案：

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

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

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

原因是當(dāng)集群中有節(jié)點掛掉或者網(wǎng)絡(luò)等出現(xiàn)異常可能會導(dǎo)致hbaseclient在select時無線等待，而鎖無法釋放

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

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

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

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

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

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

hive相關(guān)：

1、out join被拆成多個job

問題發(fā)現(xiàn)：loader在做多表join的過程時原來的一個job被hive拆成了8個job，耗時由原來的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的個數(shù)；

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

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

3、寫redis的hive job拆成了兩個job

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

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

仍然存在待解決的問題：

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

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

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

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

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