关闭

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

405人阅读 评论(0) 收藏 举报
分类:

 很早就想写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




0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:65139次
    • 积分:1574
    • 等级:
    • 排名:千里之外
    • 原创:98篇
    • 转载:0篇
    • 译文:0篇
    • 评论:10条
    最新评论