对hadoop task进行profiling的几种方法整理

便民

　　对hadoop task进行profiling的几种方法整理
　　http://blog.csdn.net/AE86_FC/archive/2010/10/22/5957793.aspx
 在hadoop中，当一个job的调试完成，执行成功后，job的开发者接下来该思考的问题通常就是：如何将job跑的更快，更加高效，更节省资源呢？这个话题其实是一个老生常谈的话题了，很多有经验的工程师，开发人员和机构都分享过类似的经验。通常来说，应用程序千变万化，程序逻辑也不尽相同，程序的执行瓶颈通常也不尽相同，有的job是IO密集型的作业，那么优化其算法效率意义就不大，而有的job是CPU密集型的，那么对其中间结果压缩，或者调整类似io.sort.mb,io.sort.factor等参数也就没有什么太大作用，优化程序算法肯定会有更大收益。
    所以在大多数情况下，写job，调试job，测试，上线运行，这套开发mapreduce应用程序的流程通常很多开发团队都走的很顺。但这并不是最难的，事情到这里也还远远不算完，程序哪里不高效，哪里消耗过多资源，哪里是瓶颈，如何优化，这一系列的问题，根据在下的经验，是开发团队考虑的相对不多的地方。
    通常应用程序的开发者发现自己的hadoop job跑的不够高效，不够快的时候，第一时间想到的，是给hadoop平台的开发团队写邮件，说你hadoop平台又怎么怎么样，害的我的job跑的不够高效，然后在邮件的最后还附加上一句：“请hadoop平台开发团队多多考虑用户的建议和用户体验，优化hadoop，满足我这个什么什么job的需求，不然我就 @#￥%#￥%#”。而其实大部分情况下，只要稍微关注一下自己的程序，稍微进行一些优化，作业的执行效率就会高很多。说到这里内心又开始有些激动，还是言归正传吧……
     刚才说到作业效率和瓶颈的问题，怎么发现作业的瓶颈呢？用户怎么知道他的作业的在哪个阶段最耗时，哪个地方最耗内存呢？其实hadoop提供了用户tunning自己job的方法，其中profiling tasks就是其中一种。
     和debug task一样，profiling一个运行在分布式hadoop环境下的mapredeuce job是比较困难的。但在hadoop中，是可以让用户针对某些tasks进行profiling采集的，当这些task执行完后，将这些profiling日志保存的文件发送到作业的提交client机器上，然后用户就可以用自己熟悉的工具来分析这些profiling日志，进行tasks执行瓶颈的分析。
使用方法：
  在JobConf中，有几个配置选项是可以用来控制task profiling行为的。比如对一个job，想要开启对其tasks的profiling功能，并设置profiling相应的HPROF参数，可以按如下方式：
conf.setProfileEnabled(true);
conf.setProfileParams("-agentlib:hprof=cpu=samples,heap=sites,depth=6," +
"force=n,thread=y,verbose=n,file=%s");
conf.setProfileTaskRange(true, "0-2");
第一行表示打开profiling task的功能，该功能默认情况下是关闭的。调用该接口相当于设置配置选项 mapred.task.profile=true，可以利用这种方式在hadoop job提交命令行上动态指定。
第二行是通过conf接口来设置对tasks进行HPROF 的profiling的采集参数，采用profiling enable的方式运行的tasks，会采用每个task一个独立的JVM的运行方式运行（即使enable了job的jvm reuse功能）。HPROF相关的采集参数设置，可以见其他资料。该选项也可以通过设置 mapred.task.profile.params 选项来指定。
第三行表示对job的哪些tasks需要进行profiling采集，第一true参数表示采集的是map tasks的性能数据，false的话表示采集reduce的性能数据，第二个参数表示只采集编号为0,1,2的tasks的数据，（默认为0-2）。如果想要采集除2,3,5编号的tasks，可以设置该参数为: 0-1,4,6-
Example
   还是拿wordcount来举例，提交job命令如下：
bin/hadoop jar hadoop-examples-0.20.2-luoli.jar wordcount \
  -D mapred.reduce.tasks=10 \
  -D keep.failed.task.files=fales \
  -D mapred.task.profile=true \
  -D mapred.task.profile.params="-agentlib:hprof=cpu=samples,heap=sites,depth=6,force=n,thread=y,verbose=n,file=%s" \
  $input \
  $output
这样，当job运行时，就会对前三个task进行profiling的采集，采集信息包括cpu的采样信息，内存分配的信息数据，stack trace 6层的堆栈信息。这里需要注意的是，由于前三个tasks被进行了HPROF的性能采样，所以这几个tasks的执行效率会受到一定的影响，profiling的信息越详细，性能影响就越大。如下图，前三个map就明显比其他的map运行的要慢很多。

不过这种运行方式通常都不是线上运行方式，而是用来进行优化调试，所以关系不大。
而当job运行完成后，这三个tasks对应的profiling日志也会会传到提交机器上，供用户分析判断。如下图：

与此同时，tasks在tasktracker上也将这些profiling日志信息记录到了一个profile.out的日志文件中，该文件通常位于tasktracker机器上的上${HADOOP_HOME}/logs/userlogs/${attempt_id}下，和该task的stderr，stdout，syslog保存在同一个目录下，如下图：

该文件中的内容，还可以通过taskdetails.jsp的页面查看到。如下图：

有了这些信息，相信对于任何一位hadoop应用程序的开发者来说，就拥有了足够的定位job瓶颈的信息了。MR的应用程序开发同学，请优化您的job吧~~