你好,游客 登录 注册 搜索
背景:
阅读新闻

hadoop JOB的性能优化实践

[日期:2014-07-25] 来源:代码农场  作者: [字体: ]

  使用了几个月的hadoopMR,对遇到过的性能问题做点笔记,这里只涉及job的性能优化,没有接触到

  hadoop集群,操作系统,任务调度策略这些方面的问题。

  hadoop MR在做大数据量分析时候有限的计算资源情况下只能不断的优化程序。

  优化可以从两个方面进行:

  1.hadoop配置

  2.程序代码

  程序代码包括的方面很多:job设计,算法,数据结构,代码编写。

  hadoop配置优化

  hadoop配置可分为mapp配置,reducer配置和hdfs配置。关于hadoop mapper和reducer阶段

  处理流程和参数意义可以看这个帖子,说的比较详细hadoop mr 参数意义。

  这里再补充几个配置:

  dfs.block.size

  这个配置项定义了在HDFS上每个block的大小,它的值是以字节为单位。

  可以在配置文件hadoop-site.xml(Hadoop 0.20 以前版本)定义,

  也可以在JobConf里定义。hdfs中block size定义是以文件为粒度的。

  hadoop的mapper数基本由输入文件的block数决定,如果输入的block

  size不够大,导致mapper处理时间很短(不到一分钟),大量这样的mapper

  会严重降低计算性能。但是如果输入文件都是小文件,就算blocksize再大,每个

  文件也会占一个block,这时候要通过合并小文件来减少mapper数,设置blocksize

  是没用的。命令行设置块大小可以加参数,0.20以后的用

  hadoop fs -D dfs.block.size=134217728 -put local_name remote_location

  之前的可以用fs.local.block.size 参数

  除了blocksize hadoop的inputformat也提供了在block的基础上更细粒度控制mapper

  输入块大小,比如当前输入块128M,设置了最大分割size为64,则原先一个块被切分

  成两个spliter了,也就产生了两个mapper。用这种方法可以有效增加mapper数,但对减少

  mapper数好像没用。

  FileInputFormat.setMaxInputSplitSize(job, size)

  FileInputFormat.setMinInputSplitSize(job, size)

  mapred.min.split.size这个参数也可以起到同样效果

  mapred.map.tasks.speculative.execution 和

  mapred.reduce.tasks.speculative.execution

  这两个选项是设置推测执行的任务,当所有task都开始运行之后,Job Tracker会统计所有任务的平均进度,

  如果某个task所在的task node机器配置比较低或者CPU load很高(原因很多),导致任务执行比总体任务的平均执行要慢,

  此时Job Tracker会启动一个新的任务(duplicate task),这个新任务就是推测任务,原有任务和新任务哪个先执行完就把另外一个kill掉,

  这也是我们经常在Job Tracker页面看到任务执行成功,但是总有些任务被kill,就是这个原因。推测任务也是要占用计算资源,

  因此计算资源紧张,任务执行本身很耗资源情况下可以考虑设置成false,禁止执行。

  io.sort.mb

  以MB为单位,默认100M,通常来看,这个值太小了,这个选项定义了map输出结果在内存占用buffer的大小,当buffer达到一定阈值,

  会启动一个后台线程来对buffer的内容进行排序,然后写入本地磁盘(一个spill文件)。可以观察hadoop的日志,如果spill次数比较多说明

  这个缓存大小设置太低,特别是那种mapper中处理数据会增多的逻辑尤其可以关注下。

  根据map输出数据量的大小,可以适当的调整buffer的大小,注意是适当的调整,不是越大越好,假设内存无限大,io.sort.mb=1024(1G),

  和io.sort.mb=300 (300M),前者未必比后者快,因为1G的数据排序一次和排序3次,每次300MB,一定是后者快(分而治之的思想)。

  io.sort.spill.percent

  这个值就是上述buffer的阈值,默认是0.8,既80%,当buffer中的数据达到这个阈值,后台线程会起来对buffer中已有的数据进行排序,

  然后写入磁盘,此时map输出的数据继续往剩余的20% buffer写数据,如果buffer的剩余20%写满,排序还没结束,map task被block等待。

  如果你确认map输出的数据基本有序(很少见),排序时间很短,可以将这个阈值适当调高,更理想的,如果你的map输出是有序的数据(基本不可能吧?),

  那么可以把buffer设的更大,阈值设置为1.

  Io.sort.factor

  同时打开磁盘spill进行并行合并的文件数,默认是10。

  当一个map task执行完之后,本地磁盘上(mapred.local.dir)有若干个spill文件,map task最后做的一件事就是执行merge sort,

  把这些spill文件合成一个文件(partition),有时候我们会自定义partition函数,就是在这个时候被调用的。

  执行merge sort的时候,每次同时打开多少个spill文件,就是由io.sort.factor决定的。打开的文件越多,不一定merge sort就越快,所以也要根据数据情况适当的调整。

  补充:merge排序的结果是两个文件,一个是index,另一个是数据文件,index文件记录了每个不同的key在数据文件中的偏移量(这就是partition)

  

  代码优化

  有空再写

  各种配置

  Mapper端配置

  1.Map逻辑处理后数据被展开,写磁盘次数剧增,可以观察日志中的spill次数,调整各个参数

  2.中间结果能不展开就不展开,尽量缩小Mapper和reducer之间的数据传递

  3.distribute cache中加载的数据能不用hashmap就尽量不要用,hashmap会使得内存占用量是原数据的5-10倍,其中

  引用占了大量空间

  4.distribute cache中加载的数据要尽可能简单,如果有复杂的处理逻辑可以单独开辟Mapper Reducer进行一轮处理,

  避免每次mapper都要处理一遍,尽可能减少distribute cache的数据量

  5.观察GC的情况,有时候是因为内存占用量高,频繁GC,严重影响处理速度

  6.当逻辑本身很简单,但是处理速度很慢时候首先要怀疑Mapper和Reducer之间传输数据量过大,其次是GC情况

  7.适当控制mapper的数量,特别是有distribute cache的场景





收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款