单纯从map的速度而言，如果不是大多数文件size都大大小于dfs.block.size，如果输出的文件数目能够接受且不会产生异常的情况下，当然是每个block对应一个mapper的效率最高了。如果是文件数目过多（即便每个文件都大于dbf.block.size），整个过程中没有reduce操作，那么每个block对应一个mapper会导致输出大量文件，撑爆hdfs的name space。在实际中应该本着不会产生异常的情况下，使得本地执行job的比例尽量高的目标去设置maxCombineSplitSize。
在使用Pig处理大批量数据时，通常是T级别及以上的情况下，你会发现当pig job被提交后，起初执行速度还挺不错，但是到了90％之后，job的执行就如同蜗牛在爬行。打开job tracker的页面，点开running链接，看看正在执行的task是什么时候启动的，你就会发现，原来这些拖后腿的task原来大多数很早就被启动执行了。就是因为这些task导致整个job在后期执行非常缓慢。那么这种情况下，你需要打开mapred的speculative开关为true，Map-Reduce框架就会侦测执行缓慢的task，启动新的task做相同的事情，最终把拖后腿的task都kill掉，从而有效的提高了pig job的执行速度。
SET mapred.map.tasks.speculative.execution true; SET mapred.reduce.tasks.speculative.execution true;
参考资料文献：
https://issues.apache.org/jira/browse/PIG-1518