hadoop2升级的那点事情(详解)

前言

前阵子，公司的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，需要修复这块代码：

  

    org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode

       org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode
       final String message = "hostname cannot be resolved (ip="
          + ip + ", hostname=" + hostname + ")";
       LOG.warn("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) ，注释掉以下代码

if (!done) {
    Thread.sleep(sleeptime);
}

    更多优化，请查阅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>0)) {
         PendingBlockMove pendingBlock = chooseNextBlockToMove();
         if (pendingBlock != null) {
+          noPendingBlockIteration=0;//添加这行代码，resetnoPendingBlockIteration,修复bug
           // move the block
           pendingBlock.scheduleBlockMove();
           continue;

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