2011-11-16 73 views
1

我正在管理多個用戶之間共享的Hadoop集羣。我們經常以非常緩慢的映射器運行作業。例如,我們可能有一個32 GB的句子文件(每行一句),我們想要NLP解析(這需要每句100毫秒)。如果塊大小爲128 MB,則爲250個映射器。這填補了我們相當小的集羣(每個節點有9個節點時間12個映射器是108個映射器),但每個映射器需要很長時間才能完成(小時)。Hadoop作業調度與緩存映射器中的作業一起在0.20.203

問題是,如果羣集爲空並且啓動了這樣的作業,它將使用羣集上的所有映射器。然後,如果其他人想要做一個短期工作,它會被封鎖幾個小時。我知道更新版本的Hadoop支持Fair Scheduler(我們正在使用容量調度程序)搶佔,但新版本也不穩定(我急於等待下一個版本)。

曾經有specifying the number of mappers的選項,但現在JobConf已被棄用(奇怪的是,它是not deprecated in 0.20.205)。這可以緩解這個問題,因爲使用更多映射器時,每個映射任務可以在較小的數據集上工作,從而更快完成。

0.20.203有什麼辦法解決這個問題嗎?我是否需要繼承我的InputFormat(在這種情況下是TextInputFormat)?如果是這樣,我需要指定什麼?

回答

1

我相信你應該能夠增加這些文件的塊大小:如果你這樣做,那麼自然,你的應用程序將使用更少的映射器。

還請記住作業配置中有map.input.length參數。這會增加分割,因此,實際上,較少輸入的映射器會更少。

+0

的說明操作即可,但這並不是我想要* more * mappers,所以mappers可以更快完成。 – schmmd

+0

鏈接到[關於在HDFS中更改文件的塊大小的問題](http://stackoverflow.com/questions/2669800/changing-the-block-size-of-a-dfs-file-in-hadoop)到支持你的答案。 – schmmd

+0

@ jayunit100 - 你可以指向指向map.input.length配置參數的Apache文檔。我沒有找到它。 –

1

如果缺少實際的物理資源(即羣集中的機器),更多映射器將無法解決您的問題。我會嘗試在較少的輸入文件中打包數據,以避免隨機硬盤尋找。

編輯:好的,如果你想要更多的映射器,然後嘗試將你的數據分割成幾個小文件或減少塊大小。

+0

目前有一個輸入文件。我不明白爲什麼更多的映射器不能解決我的問題 - 我的問題是調度問題,而不是資源問題。 – schmmd

+0

我並不是想讓自己的工作更快,我試圖讓其他工作有更多的機會在我的面前預定。 – schmmd

+0

@schmmd:現在我明白了。看看我的編輯是否有幫助。 – Tudor

1

不完全確定是否有更多的映射器可以解決您的問題。 JobConf#setNumMapTasks對每個作業產生的地圖任務上的#號沒有影響。即使該文件說這只是框架的暗示。生成的地圖任務數等於作業的輸入分割數。以下是減少InputSplit大小的不同選項,從而增加InputSplits#並增加map任務的數量。

  • 通過更改dfs.blocksize來減小HDFS塊的大小。但是,這會增加NameNode上的負載,因爲它必須保留更多的文件與塊映射,並且DataBlock報告的大小也會增加。另外,hadoop fs -D fs.local.block.size=134217728 -put local_name remote_location將更改放入HDFS的新文件的塊大小,舊文件將保持原樣。舊文件必須從HDFS中取出並放回所需的塊大小。

  • 使用NLineInputFormat來控制每個地圖的輸入線數。爲此,工作必須改變。 mapred.line.input.format.linespermap默認爲1必須定義。

  • 從0.21版本開始mapreduce.input.fileinputformat.split.minsizemapreduce.input.fileinputformat.split.maxsize已被定義,但它是與新的MR API。 InputSplit計算是在客戶端完成的,所以它不能強制執行到Job客戶端。

用於計算InputSplit大小的邏輯如下。

protected long computeSplitSize(long blockSize, long minSize, long maxSize) { 
    return Math.max(minSize, Math.min(maxSize, blockSize)); 
}