hadoop2升级的那点事情(详解) – ggjucheng – 博客园

前言

前阵子,公司的hadoop从hadoop1.02升级到hadoop2.4.1,记录下升级的步骤和遇到的问题,和大家分享,希望别人可以少走一些弯路

技术选型

  当前使用版本:
     apache hadoop 1.0.2
      hive 0.10
  升级目标版本
     Apache hadoop 2.4.1
     Hive 0.13

 

升级风险点

Hdfs的升级
Hadoop升级最主要是hdfs的升级,hdfs的升级是否成功,才是升级的关键,如果升级出现数据丢失,则其他升级就变的毫无意义。
解决方法:
1. 备份hdfs的namenode元数据,升级后,对比升级前后的文件信息。
2. 单台升级datanode,观察升级前后的block数。
备注:文件数和block数不是完全一样,hadoop1和hadoop2的计数方式不一样,可能相差2%左右。

Yarn的升级
Yarn的升级,它相对hdfs的升级,升级压力没有那么大,但是由于以前hive使用mapred,而现在直接使用yarn,所以兼容问题,就比hdfs多不少,所幸我们的任务基本是使用hive,所以我们更多的是面临hive0.13和hive0.10的兼容问题。
而我们升级过程中,yarn的兼容问题,主要是资源的错误配置,兼容问题不多,而hive的升级,遇到更多的兼容问题,所以升级过程中,更多要测试的是hive升级导致的问题。

 

hdfs升级步骤

1.下载hadoop2.4.1,${HADOOP_HOMOE}/etc/hadoop/hdfs-site.xml中dfs.namenode.name.dir和dfs.datanode.data.dir属性的值分别指向Hadoop1.x的${HADOOP_HOME}/conf/hdfs-site.xml中dfs.name.dir和dfs.data.dir的值。

2.升级namenode:/usr/local/hadoop 2.4.1/sbin/hadoop-daemon.sh start namenode –upgrade

3.升级datanode:/usr/local/hadoop 2.4.1/sbin/hadoop-daemon.sh start datanode

升级hdfs花费的时间不长,就是和启动集群的时间要多2-3倍的时间,升级丢失数据的风险几乎没有。具体可以参考代码:

namenode升级: org.apache.hadoop.hdfs.server.namenode.FSImage.doUpgrade(如果想查看你的apache hadoop版本是否可以升级到hadoop2.4.1,可以在这里查阅代码判断,apache hadoop 0.20 以上的都可以升级到apache hadoop 2.4.1)

datanode升级: org.apache.hadoop.hdfs.server.datanode.DataStorage.doUpgrade

                     org.apache.hadoop.hdfs.server.datanode.BlockSender

 如果升级失败,可以随时回滚,回滚,数据会回滚到升级前那一刻的数据,升级后的数据修改,全部失效,回滚启动步骤如下:

1. 启动namenode: /usr/local/hadoop1.0.2/bin/hadoop-daemon.sh start namenode –rollback
2. 启动datanode: /usr/local/hadoop1.0.2/bin/hadoop-daemon.sh start datanode –rollback

 

hdfs升级遇到的问题

1.datanode block数过多,导致启动的时候做block report时,由于rpc调用的字节数限制,导致block report失败。

   解决方法是修改core-site.xml加入ipc.maximum.data.length属性,值设置为几百兆,根据具体情况调整。

2.同时启动一百多台datanode时,namenode会卡死,这个问题,应该是hadoop的bug。

   解决方法是,写脚本,一台台启动datanode。

3.Namenode Full GC过多,每次GC,系统停顿3-4分钟

  由于namenode保存元数据在内存,所以对老生代的压力比较大,每次full gc时,系统就会卡死几分钟,解决方法如下:
  (1). 使用cms gc算法
  (2). 修改新生代和老生代比例为1:2,如果是1:4,会造成大对象在做ygc时,大对象直接进入老生代,造成老生代内存快速增长,full gc更加频繁。

4.Namenode checkpoint超时
   使用jdk1.6,在snn做checkpoin时,会超时,导致出错,但是换jdk1.7,不超时,不出错。
  问题定位到snn请求namenode的jetty服务器的servlet时,文件传输完毕,但是NameNode的jetty没有关闭连接,导致snn这边读数据超时退出。

  最后的解决方式,是在snn的读取数据的超时时间,从默认的1分钟修改为20分钟,NameNode的jetty会自动关闭连接,snn读取数据可以正常退出,该方式并不是一个优雅的解决方式。

5.NameNode突然运行的很慢,每几秒,rpc服务器就卡死10秒

  由于在接口机启动了一个DataNode,而注册的时候,NameNode无法获取这个意外的DataNode的hostname,最致命的是,注册的时候,NameNode的底层系统类,获取了写锁,在写锁   后,做ip的反域名解析这种可能出现耗时10s的操作。
   而DataNode的注册加入了重试机制,即使出错,也会不断重试,导致NameNode的服务相当缓慢。

  最后的解决方案是kill掉接口机的DataNode,但是该问题的根本原因是hdfs的bug,需要修复这块代码:

  

<span style="color: #000000;">    org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode</p><p>       org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode</p><p>       </span><span style="color: #0000ff;">final</span> String message = "hostname cannot be resolved (ip="</p><p>          + ip + ", hostname=" + hostname + ")"<span style="color: #000000;">;</p><p>       LOG.warn(</span>"Unresolved datanode registration: " + message);

   如果怀疑是非法DataNode连接NameNode导致集群缓慢,可以查log,找关键字: Unresolved datanode registration

 

6.HDFS做balancer很慢,一天居然只能balancer 2TB数据,导致集群的机器的存储,个别机器存储100%,大部分机器存储却很空闲

   balancer代码被重写,以很保守的方式做balancer,而且参数根本无法配置优化,只能改代码。

   修改org.apache.hadoop.hdfs.server.balancer.Balancer.blockMoveWaitTime从30s修改为1s,这个可以提升很大的balancer的速度,在我负责的生产环境一般一次迭代只需要5s完成,它却等了30s再检测,真是无力吐槽。

   修改org.apache.hadoop.hdfs.server.balancer.Balancer.run(Collection<URI> namenodes, Parameters p, Configuration conf) ,注释掉以下代码

<span style="color: #0000ff;">if</span> (!<span style="color: #000000;">done) {</p><p>    Thread.sleep(sleeptime);</p><p>}</span>

    更多优化,请查阅org.apache.hadoop.hdfs.server.balancer.Balancer做优化。

    优化后,一天也只能balancer 12TB-20TB左右,只是勉强满足要求。

    继续优化,优化balancer的根本问题,提高balancer每次迭代中,datanode balancer的吞吐量,balancer过慢,是bug来的,请修改以下代码

org.apache.hadoop.hdfs.server.balancer.Balancer.Source.dispatchBlocks

复制代码

 (!srcBlockList.isEmpty() || blocksToReceive&gt;0<span style="color: #000000;">)) {</p><p>         PendingBlockMove pendingBlock </span>=<span style="color: #000000;"> chooseNextBlockToMove();</p><p>         </span><span style="color: #0000ff;">if</span> (pendingBlock != <span style="color: #0000ff;">null</span><span style="color: #000000;">) {</p><p></span>+          noPendingBlockIteration=0;<span style="color: #008000;">//</span><span style="color: #008000;">添加这行代码,resetnoPendingBlockIteration,修复bug</p><p>           </span><span style="color: #008000;">//</span><span style="color: #008000;"> move the block</span></p><p><span style="color: #000000;">           pendingBlock.scheduleBlockMove();</p><p>           </span><span style="color: #0000ff;">continue</span>;

复制代码

bug参考 https://issues.apache.org/jira/browse/HDFS-6621

还有final private static long MAX_BLOCKS_SIZE_TO_FETCH从2GB修改为300MB(重要,patch没有这个参数,但是不加,依然无法提高吞吐量)

优化后,balancer的吞吐量可以达到一天64TB。

 

7.高可用环境,standby namenode会间歇性卡死,而hdfs客户端偶尔会连接standby namenode,导致hdfs服务偶尔缓慢,经过排查,确定standby namenode每一分钟会做editlog的合并,合并的时候,会锁死FSNamenodeSystem的所有服务,导致standby namenode会间歇性出现3s的卡死,甚至10s的卡死。

代码问题在org.apache.hadoop.hdfs.server.namenode.ha.EditLogTailer.doTailEdits

bug修复参考 https://issues.apache.org/jira/browse/HDFS-6763

 

 

yarn升级步骤

由于任务计算都是使用hive,所以yarn的升级很简单,只是启动yarn就行了。唯一要注意的是,从mapreduce升级到yarn,资源分配方式变化了,所以要根据自己的生产环境修改相关的资源配置,yarn的兼容问题,遇到的很少。

反而在任务计算中遇到更多问题的是hive,hive从0.10升级到hive0.13,语法更加苛刻,严格,所以升级前,尽可能测试hive的兼容性,hive0.13可以运行在hadoop1.02,所以升级到hadoop2之前,先升级hive到hive0.13以上,遇到问题,也没什么好办法,就是改hive sql,改hive参数。

 

1yarn任务无故缓慢,经常一个简单任务本来需要30秒,经常会出现5分钟都无法跑成功。经过跟踪,发现是nodemanager启动container时,初始化container(下载jar包,下载job描述文件)代码是同步,修改代码,把初始化container的操作修改为并发,解决该问题。

代码问题在 org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor.startLocalize(该方法是synchronized)

bug修改参考 https://issues.apache.org/jira/browse/YARN-2730

来源URL:http://www.cnblogs.com/ggjucheng/p/3977185.html