原文：http://michaelkang.blog.51cto.com/1553154/1382816 <!--Thu Aug 15 20:47:13 2013-->  <configuration>    <property>    <name>mapreduce.task.timeout</name>    <value>600000</value>  </pro

既起到了一批新机器，安装了不少服务后，运行Sqoop，发现报错。 2019-05-24 10:46:40,798 FATAL [main] org.apache.hadoop.mapred.YarnChild: Error running child : java.lang.UnsupportedClassVersionError: QueryResult : Unsupported major

Hive配置中有个参数hive.mapred.mode，分为nonstrict，strict，默认是nonstrict 如果设置为strict，会对三种情况的语句在compile环节做过滤： 1. 笛卡尔积Join。这种情况由于没有指定reduce join key，所以只会启用一个reducer，数据量大时会造成性能瓶颈     // Use only 1 reducer in ca

接上一篇，jt在offerService方法中执行作业recovery操作，需要注意的是，下面介绍的recovery操作是在jt的rpc server启动之前，即jt对外提供服务之前。 记得十一节前排查发现ecomon集群堆积4000个待恢复作业时还搞不清楚为啥有问题，通过下面的介绍就可以发现，恢复那么多的作业，jt启动之后很长时间将不能提供服务。 recovery的过程其实也不复杂，简单来讲

Hadoop1.0.3版本 一直知道jobtracker有任务恢复、作业重跑功能等，那么jobtracker是如何实现的呢？ 今天通过对jobtracker启动过程的跟踪，来一探究竟。 jobtracker有一个内部类叫做RecoveryManager ，同时jobtracker有个私有成员： RecoveryManager recoveryManager; 在初始化的时候，对其构造： r

用hadoop也算有一段时间了，一直没有注意过hadoop运行过程中，产生的数据日志，比如说System打印的日志，或者是log4j，slf4j等记录的日志，存放在哪里，日志信息的重要性，在这里散仙就不用多说了，调试任何程序基本上都得需要分析日志。 hadoop的日志主要是MapReduce程序，运行过程中，产生的一些数据日志，除了系统的日志外，还包含一些我们自己在测试时候，或者线上环境输出的日

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="configuration.xsl"?><configuration><!-- 指定MapReduce程序运行在Yarn上 --><property><name>mapreduce.framework.name</name><value>yar

mapred.output.compression.codec控制着输出文件的压缩格式