mapreduce的优化

Job的运行过程中会有一系列的sort 的操作，并且reduce input groups的counter变量的值远远要小于reduce input records counter。
Job在mapper完成以后，shuffle过程中传输了大量的中间结果文件（例如：每个slave上的map output bytes都好几个GB）
在job 的webui上的counter中看到，job的spilled records的数量远远要大于map output records的数量。
如果job的算法中涉及到许多的排序操作，可以尝试写一个Combiner来提高job性能。hadoop的mapreduce框架中提供了Combiner来减少中间结果对磁盘的写入和减少中间结果在mapper和reducer之间的传输，通常这两个方面都是非常影响作业性能的两个方面。
性能对比:
修改wordcount程序，将setCombinerClass去掉，或者不去掉，两种方式对比运行。去掉的结果是，让每一个mapper的运行时间由原先的33s变成了平均48s，并且shuffle过程中的中间数据也由1G变成1.4GB，整个的job由原先的8分30秒变成了15分42秒，将近两倍了。而且，这个测试还是在enable了map的output 压缩的情况下进行的，如果disable这个特性，性能的影响可能会更加大。

---

　　首先，一个job具体启动多少个map，是由你配置的inputformat来决定的。inputformat在分配任务之前会对输入进行切片。最终启动的map数目，就是切片的结果数目。具体来看 一、如果使用是自定义的inputformat，那么启动多少个map
需要获取mapreduce的运行信息,比如运行状态,map,reduce的执行进度. hadoop 50030端口提供web ui服务,没找到提供json或者xml的服务方式. 于是,查找hadoop 50030的加载