hadoop & hive任务优化之map个数的影响因子

 很早就想写hadoop任务优化的系列博客，趁今晚有闲暇，就以经常难住应聘hadoop研发工程师相关岗位人员经典题目为例说起吧。由于hive是架接在hadoop之上，故两者在这个问题上是一致的，故合并在一起讲解。因为目前hadoop主流版本已为hadoop2.x，故以下讲解均以hadoop2.x为基础。
      见到大多数的研发人员都认为hadoop很历害，放上个任务就去集群上跑，快慢他们并不在乎，只是关心能否跑出结果。这样的hadoop用法确实太过粗浅，用hive之类的工具可以在10分钟内教给一个懂sql的人学会应用hadoop。这远不是一个专业的hadoop应用开发工程师所应要求的，而应是深入hadoop运行原理、参数详解、任务过程剖析等方面，使hadoop真正成为大数据处理平台。下面言归正传。
       1、集群的container总大小
            这个是最外层的因素，集群一般会做设置，当job产生的map数大于某一阀值时候，直接禁止提交。
            但由于hadoop2.x已是动态分配container,往往只限制内存+CPU，并没有明确的个数限制。但当超过分配的CPU或是内存其一的大小时候，将直接禁止提交。
       2、分配到用户所属调度队列的资源总大小
            与1中相似，由于目前hadoop2.x集群多采用公平调度的多队列资源分配管理。只要当前用户所提交任务不超过当前所属队列的总资源大小，即可被提交。
       3、当前任务的输入数据的文件个数
             这是最复杂的情况，
            3.1 当输入的每个文件的大小均小于集群设置的块大小，则有多少个输入文件，则会产生多少个map任务。
            3.2 当输入的文件中，有大于一个block size的时候，且该文件的格式可拆分，如lzo,textfile等，则该文件会被拆分成两个map，其它的类似文件也是如是处理。
                  当有大于blocksize的时候，但该文件格式不可拆分，如gzip,deflate等，则该文件依然不会被拆分，即有多少个文件就产生多少个map任务。
       4、输入数据文件的格式
             当输入文件的格式不可拆分时，如gzip ,deflate时候，则产生的map任务个数均为文件的数量。
             当输入文件的格式可拆分时候，如lzo,textfile的时候，则产生的文件个数可以通过以下参数来动态协调优化：
             如： set mapred.max.split.size=256000000;  #每个Map最大输入大小 ，单位字节，该大小为256M
            假设blocksize为128M，当某文件大小大于该数值时候，按该数值大小处理，不再拆分成多个blocksize分开处理。
                           
        5、人工设置map task个数mapred.map.tasks
             该因子会间接影响map的产生个数，其计算公式和方法，链接如下
             http://blog.sina.com.cn/s/blog ... .html，讲解的比较具体和细致，我就不赘述了。
        6、map输入端合并
           set mapred.max.split.size=256000000;  #每个Map最大输入大小 ，单位字节
           set mapred.min.split.size.per.node=100000000; #一个节点上split的至少的大小 ,单位字节
           set mapred.min.split.size.per.rack=100000000; #一个交换机下split的至少的大小 ,单位字节
           set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;  #执行Map前进行小文件合并 的执行类;
其中，mapred.max.split.size决定多个文件合并后，最大可以形成一个多大的数据块，即决定多少个小文件可以参与合并。
mapred.min.split.size.per.node决定跨data node节点的小文件是否可以合并，
mapred.min.split.size.per.rack决定跨交换机上的小文件是否可以合并。
最后由类org.apache.hadoop.hive.ql.io.CombineHiveInputFormat来执行以输入数据合并操作，
并将输出作为真正计算的map的输入。

总结：
        hadoop任务优化的核心是，合理的job任务产生合适 的map/reduce个数，每个map/reduce处理合适的数据条数。
 最大的障碍在于job产生木桶效应，某个map或是某个reduce处理时间过长，直接决定了job的运行时间。
        故解决此问题有5点，a、对数据本身的大小、条目数清楚，
                                       b、业务逻辑代码的合理性
                                       c、系统参数设置合理
                                       d、合理的map生成
                                       e、合理的reduce生成
有以上5点，才可以真正成为hadoop开发的优秀开发人员。    

更多学习讨论，          请加入官方QQ技术群320349384,
                                 官方天亮论坛:http://bbs.yuqing36524.com/
                                 天亮教育视频链接：http://pan.baidu.com/s/1pJJrcqJ