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