由hbase.client.scanner.caching参数引发的血案（转）

转自：http://blog.csdn.net/rzhzhz/article/details/7536285

环境描述

Hadoop 0.20.203.0
Hbase 0.90.3
Hive 0.80.1

问题描述

     前几天，在HIVE执行SQL查询的时候出现了一个很奇怪的问题：就是每个SQL（涉及到MapReduce的SQL任务）在执行到某个百分比的时候，整个JOB会出现假死的情况。

[java] view plain copy
 
  1. 2012-04-28 18:22:33,661 Stage-1 map = 0%, reduce = 0%  
  2. 2012-04-28 18:22:59,760 Stage-1 map = 25%, reduce = 0%  
  3. 2012-04-28 18:23:04,782 Stage-1 map = 38%, reduce = 0%  
  4. 2012-04-28 18:23:07,796 Stage-1 map = 50%, reduce = 0%  
  5. 2012-04-28 18:23:08,801 Stage-1 map = 50%, reduce = 8%  
  6. 2012-04-28 18:23:17,839 Stage-1 map = 50%, reduce = 17%  
  7. 2012-04-28 18:23:19,848 Stage-1 map = 63%, reduce = 17%  
  8. 2012-04-28 18:23:32,909 Stage-1 map = 63%, reduce = 21%  
  9. 2012-04-28 18:23:57,017 Stage-1 map = 75%, reduce = 21%  
  10. 2012-04-28 18:24:09,075 Stage-1 map = 75%, reduce = 25%  
  11. 2012-04-28 18:25:09,397 Stage-1 map = 75%, reduce = 25%  
  12. 2012-04-28 18:26:09,688 Stage-1 map = 75%, reduce = 25%  
  13. 2012-04-28 18:27:09,980 Stage-1 map = 75%, reduce = 25%  
  14. 2012-04-28 18:28:10,262 Stage-1 map = 75%, reduce = 25%  
  15. 2012-04-28 18:29:10,522 Stage-1 map = 75%, reduce = 25%  
  16. 2012-04-28 18:30:10,742 Stage-1 map = 75%, reduce = 25%  
  17. 2012-04-28 18:31:10,985 Stage-1 map = 75%, reduce = 25%  
  18. 2012-04-28 18:32:11,238 Stage-1 map = 75%, reduce = 25%  
  19. 2012-04-28 18:33:11,467 Stage-1 map = 75%, reduce = 25%  
  20. 2012-04-28 18:34:11,731 Stage-1 map = 75%, reduce = 25%  
  21. 2012-04-28 18:35:11,968 Stage-1 map = 75%, reduce = 25%  
  22. 2012-04-28 18:36:12,213 Stage-1 map = 75%, reduce = 25%  
  23. 2012-04-28 18:37:12,508 Stage-1 map = 75%, reduce = 25%  
  24. 2012-04-28 18:38:12,747 Stage-1 map = 75%, reduce = 25%  
  25. 2012-04-28 18:39:12,970 Stage-1 map = 75%, reduce = 25%  
  26. 2012-04-28 18:40:13,205 Stage-1 map = 75%, reduce = 25%  

之前几天还跑得挺好的，没有出现这种情况，然后是偶尔出现，到最后变成是几乎每个JOB都这样。

很头疼，检查了所有的日志（包括hadoop，hbase和hive），日志却没有任何异常。唯一让人有点疑虑的日志就是TaskTracker中这样的提示

[java] view plain copy
 
  1. 2012-04-28 18:31:53,879 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  2. 2012-04-28 18:31:56,883 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  3. 2012-04-28 18:31:59,887 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  4. 2012-04-28 18:32:02,892 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  5. 2012-04-28 18:32:05,897 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  6. 2012-04-28 18:32:08,902 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  7. 2012-04-28 18:32:11,906 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  8. 2012-04-28 18:32:14,910 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  9. 2012-04-28 18:32:17,915 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  10. 2012-04-28 18:32:20,920 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  11. 2012-04-28 18:32:23,924 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  12. 2012-04-28 18:32:26,929 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  13. 2012-04-28 18:32:29,934 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  14. 2012-04-28 18:32:32,938 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  15. 2012-04-28 18:32:35,943 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  16. 2012-04-28 18:32:38,948 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  17. 2012-04-28 18:32:41,953 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  18. 2012-04-28 18:32:44,957 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  19. 2012-04-28 18:32:47,961 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  20. 2012-04-28 18:32:50,966 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  21. 2012-04-28 18:32:53,970 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  22. 2012-04-28 18:32:56,974 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  23. 2012-04-28 18:32:59,979 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  24. 2012-04-28 18:33:02,983 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  25. 2012-04-28 18:33:05,987 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  26. 2012-04-28 18:33:08,992 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  27. 2012-04-28 18:33:11,997 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  28. 2012-04-28 18:33:15,001 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  29. 2012-04-28 18:33:18,006 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  30. 2012-04-28 18:33:21,011 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  31. 2012-04-28 18:33:24,015 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  32. 2012-04-28 18:33:27,020 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  33. 2012-04-28 18:33:30,025 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  34. 2012-04-28 18:33:33,029 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  35. 2012-04-28 18:33:36,034 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  36. 2012-04-28 18:33:39,038 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  37. 2012-04-28 18:33:42,043 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  38. 2012-04-28 18:33:45,047 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  39. 2012-04-28 18:33:48,051 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  40. 2012-04-28 18:33:51,057 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  
  41. 2012-04-28 18:33:54,062 INFO org.apache.hadoop.mapred.TaskTracker: attempt_201204281725_0002_m_000002_0 0.0%  

查看日志无果，然后我很自然的想到了是不是网络或者内存、cpu的问题，查看系统参数，也没有出现异常的情况。

也怀疑过是否某个TT所在机器的性能问题，所以尝试停止了一些TT，但问题依旧存在。

继续纠结，完全不知道从何下手……

实在是没办法，只有在job监控页面查找锁定出现问题的task，记住其taskId，并追踪到相应的child进程（运行task的jvm）并kill掉，查看方法如下

jps -mvll |grep taskId

（此时JT检测到该task死亡并会重新分配该任务到其他TT）。最后奇迹发生了，该JOB顺利的执行完毕。

[java] view plain copy
 
  1. 2012-04-28 18:40:51,324 Stage-1 map = 88%, reduce = 25%  
  2. 2012-04-28 18:41:04,364 Stage-1 map = 88%, reduce = 29%  
  3. 2012-04-28 18:41:31,448 Stage-1 map = 100%, reduce = 29%  
  4. 2012-04-28 18:41:43,485 Stage-1 map = 100%, reduce = 100%  

很意外，而且每个JOB假死时这个方法都凑效。从job监控界面看到假死的task都有一个备用的task也在运行。当时想到是hadoop本身的Speculative Task调度策略，然后就以为是hadoop本身的bug，还傻乎乎的去提bug……

等待无果，就只能自己动手了，从最简单的hive-hbase-handler-0.8.1.jar（因为不需要分开部署，哈哈，我其实还是蛮懒的）开始，查源码，加log。然后发现其实假死的task并没有被挂起，其实它还一直在运作，只是运作速度很慢。而且瓶颈就在hbase scan数据的时候，每取一条数据需要70+ms，神啊几十万的数据，这么个速度不慢才怪。

此时问题又出现了，为什么其他task的读取速度这么快呢？难道是本地数据的原因？

然后写log才发现，出现假死情况的task所处理的数据所在的regionServer不是本地的regionServer，其实Speculative Task调度策略也起作用了，只是该task比较点背，第二个分配的task也不在数据所在的regionServer上。所以才出现了hbase读取速度慢的原因。

但令人奇怪的是我明明在hbase-site.xml文件中设置了hbase.client.scanner.caching参数，scan数据的时候不应该是会在client端会有cache吗？为什么log中提现的是每取一条数据都会消耗70+ms的时间？难道是参数没有生效？

查看了scan的整个流程，hbase.client.scanner.caching的设置没有任何问题。只能又拿hive-hbase-handler-0.8.1.jar开刀了，修改HiveHBaseTableInputFormat这个类，在实例化Scan的手动设置一个cache值，最后发布，运行！问题解决，cache生效了。

奇怪的说，callable在设置cache的时候明明是先看Scan是否设置了cache，如果没设置就取配置文件中设置的值。为什么明明配置文件中设置了却不生效呢？

郁闷的时候出去溜达了一圈，才恍然大悟，我光在server端设置了cache，client端并没有设置，这个参数的名字这么明显是client端的。脑残了……

最后修改hadoop  conf目录下的hbase-site.xml，问题解决。

结论

既然task所处理的数据所在的regionServer不是本地的regionServer时，取数据会比较慢，那就减少与非本地regionServer的交互次数。在保证内存足够的情况下适当的设置cache值对mapreduce的处理速度会提高不少。但这个参数是在client端参数，设置时请务必在client端设置。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/weizhxa/p/6563958.html