提高hadoop的mapreduce job效率筆記—–修改mapper和reducer數量
hadoop 的mapreduce 的作業在運行過程中常常碰到一些這樣的情況：
每一個map或者reduce只有30-40秒鐘就結束
超大規模的job 時，通常會需要大量的map和reduce的slots 支持，但是job運行起來后，running的map和reduce并沒有沾滿集群的可用slots
當幾乎所有的map和 reducers都在調度系統 中運行著，此時卻有 一個或者兩個pending的map或者reduce，一直不跑，使得job一直無法正常結束。
對一 個job的map數和reduce數的設定對一個job的運行是非常重要的，并且非常簡單。以下是一些設置這幾個值的經驗總結：
1.如果job的每個map或者 reduce task的運行時間都只有30-40秒鐘，那么就減少該job的map或者reduce數，每一個task(map|reduce)的setup和加入到 調度器中進行調度，這個中間的過程可能都要花費幾秒鐘，所以如果每個task都非常快就跑完了，就會在task的開始和結束的時候浪費太多的時間。JVM 的reuse方式也可以解決 這個問題。
2.如果某個input的文件 非常的大，比如 1TB，可以考慮將hdfs上的每個block size設大，比如設成256MB或者512MB，這樣map和reduce的數據 可以減小。而且用戶還可以通過命令 ：hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式來將已經存在咋hdfs上的數據進行大塊化。然后刪除掉原先的文件。
3.只要每個task都運行至少30-40秒鐘，就可以考慮將mapper數擴大，比如集群的map slots為100個，那么就不要將一個job的mapper設成101，這樣前100個map能夠并行完成，而最后一個map要在前100個 mapper結束后才開始，因此在reduce開始運行前，map階段的時間幾乎就要翻倍。
4.盡量不要運行太多的reduce task。對大多數job來說，最好rduce的個數最多和集群中的reduce持平，或者比集群的 reduce slots小。這個對于小集群而言，尤其重要。