Hadoop中TeraSort修改后輸出翻倍異常怎么辦

小編給大家分享一下Hadoop中TeraSort修改后輸出翻倍異常怎么辦，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

    簡(jiǎn)而言之，就是在修改了ＴeraInputFormat.java之后，運(yùn)行TeraSort所得到的輸出數(shù)據(jù)不同程度的翻倍，剛開始并沒有什么頭緒，并且把采樣的線程和Ｍap的讀入＜key, value＞搞混了，邏輯不清晰，導(dǎo)致很多時(shí)間都在無關(guān)緊要的地方反復(fù)調(diào)試．

    其實(shí)應(yīng)該可以想到一種辦法，就是在MapTask里設(shè)斷點(diǎn)觀察，但不知道是自己懶還是因?yàn)閷?duì)隱藏在深處的ＭapTask有一種畏懼心里，起初我并沒有仔細(xì)進(jìn)去看，后來在ＭapTask里ＲecordReader部分的nextKeyValue()方法里設(shè)置變量計(jì)數(shù)并輸出，來觀察每次split所獲取的記錄條數(shù)，結(jié)果發(fā)現(xiàn)，我的每個(gè)split都完整的獲取了整個(gè)（注意是整個(gè)輸入文件）而不是一個(gè)split大小的記錄，所以輸出也隨著翻倍了．

    那么關(guān)鍵點(diǎn)找出來了，問題出在哪里呢？ＭapTask部分是Ｈadoop默認(rèn)綁定的，TeraSort并沒有重寫，所以這部分不可能出錯(cuò)；TeraInputFormat的前半部分是取樣部分，問題不可能出在這里；后半部分的RecordReader的initialize部分和修改前基本無變化，那錯(cuò)誤的部分一定是在nextKeyValue()部分了，于是一行一行分析，最終鎖定了這一句：

newSize = in.readLine(record);

    很普通的讀取一行記錄，那有沒有可能是readLine()這個(gè)方法對(duì)長(zhǎng)度沒有限定呢？雖然nextKeyValue()方法是split對(duì)象調(diào)用的，但會(huì)不會(huì)readLine()并不理會(huì)你每個(gè)split塊的大小而是一股氣往下讀取直到讀到文件末尾呢？

    為了驗(yàn)證這個(gè)可能，我添加了全局變量:    

long recordLen;
//將下面這句加在nextKeyValue()中
recordLen += newSize;

    來記錄讀取記錄的總長(zhǎng)度,，并設(shè)定當(dāng)

if(recordLen ＞＝ split.getLength)｛
    return false;
}

    修改后打jar包放到節(jié)點(diǎn)上運(yùn)行，結(jié)果正確！?。?br/>

看完了這篇文章，相信你對(duì)“Hadoop中TeraSort修改后輸出翻倍異常怎么辦”有了一定的了解，如果想了解更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！