hadoop2升级的那点事情(详解)Flume+Kafka+Storm整合

前不久,该公司的Hadoop从hadoop1.02升级到hadoop2.4.1,记录了升级步骤和遇到的问题,与大家分享,希望别人能少走弯路。

[En]

Not long ago, the company’s hadoop upgraded from hadoop1.02 to hadoop2.4.1, recording the upgrade steps and problems encountered, sharing with you, hoping that others can take fewer detours.

技术选型

当前使用的版本:

[En]

Current version in use:

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的兼容问题。
在升级过程中,纱线的兼容性问题主要是资源配置不当,兼容性问题很少,而蜂巢升级遇到的兼容性问题更多,所以在升级过程中,需要测试更多蜂巢升级带来的问题。

[En]

In the process of upgrading, the compatibility problem of yarn is mainly the misconfiguration of resources, and there are few compatibility problems, while the upgrade of hive encounters more compatibility problems, so in the process of upgrading, we need to test more problems caused by hive upgrade.

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

如果升级失败,您可以随时回滚和回滚,数据将回滚到升级前的瞬间数据,升级后修改的所有数据都将失效。回档开始如下:

[En]

If the upgrade fails, you can roll back and roll back at any time, and the data will be rolled back to the data of the moment before the upgrade, and all the data modified after the upgrade will be invalidated. Rollback starts as follows:

  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.max.data.long属性,将该值设置为几百MB,并根据具体情况进行调整。

[En]

The solution is to modify the core-site.xml to add the ipc.maximum.data.length property, set the value to several hundred megabytes, and adjust it according to the specific situation.

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

解决方案是编写脚本并逐个启动DataNode。

[En]

The solution is to write scripts and start datanode one by one.

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的栈会自动关闭连接,SNN读取的数据可以正常退出,这并不是一个优雅的解决方案。

[En]

The final solution is that when the timeout of reading data in snn is changed from the default 1 minute to 20 minutes, the jetty of NameNode will automatically close the connection, and the data read by snn can exit normally, which is not an elegant solution.

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

因为在接口机器上启动了DataNode,并且在注册时,NameNode无法获得该意外DataNode的主机名。最致命的情况是,在注册时,NameNode的底层系统类获取写锁。写完锁后,IP的反域名解析可能需要10秒。

[En]

Because a DataNode is started on the interface machine, and when registering, NameNode cannot get the hostname of this unexpected DataNode. The deadliest thing is that when registering, the underlying system class of NameNode acquires the write lock. After writing the lock, it may take 10 seconds to do the anti-domain name resolution of ip.

而DataNode的注册加入了重试机制,即使出错,也会不断重试,导致NameNode的服务相当缓慢。

最终的解决方案是KILL接口机的DataNode,但问题的根本原因是HDFS的错误,需要修复以下代码:

[En]

The final solution is the DataNode of the kill interface machine, but the root cause of the problem is the bug of hdfs, and this code needs to be fixed:

如果怀疑到NameNode的非法DataNode连接导致集群运行缓慢,您可以查看日志中的关键字:未解析的DataNode注册

[En]

If it is suspected that an illegal DataNode connection to NameNode caused the cluster to be slow, you can check log for the keyword: 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

更多优化请参考org.apache.hadoop.hdfs.server.balancer.Balancer进行优化。

[En]

For more optimization, please refer to org.apache.hadoop.hdfs.server.balancer.Balancer for optimization.

经过优化,一天只能均衡12TB-20TB左右,但勉强满足要求。

[En]

After optimization, it can only balancer 12TB-20TB about a day, but barely meet the requirements.

继续优化,优化均衡器的根本问题,提高DataNode均衡器每次迭代的吞吐量,均衡器速度太慢,是BUG,请修改以下代码

[En]

Continue to optimize, optimize the fundamental problem of balancer, improve the throughput of datanode balancer in each iteration of balancer, balancer is too slow, it is from bug, please modify the following code

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

还有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升级步骤

由于蜂巢用于任务计算,所以纱线的升级很简单,只需开始纱线。唯一需要注意的是,从MapReduce升级到纱线时,资源分配方式发生了变化,需要根据自己的生产环境来修改相关的资源配置。纱线兼容性问题很少遇到。

[En]

Since hive is used for task computing, the upgrade of yarn is simple, just start yarn. The only thing to note is that the way of resource allocation has changed when upgrading from mapreduce to yarn, so you have to modify the relevant resource configuration according to your own production environment. Yarn compatibility problems are rarely encountered.

相反,任务计算中遇到的问题是HIVE,HIVE从0.10升级到HIVE 0.13,语法要求更高、要求更严格,所以在升级之前,尽量测试HIVE的兼容性。Hive0.13可以在hadoop1.02上运行,所以在升级到hadoop2之前,请将hive升级到hive0.13或更高版本,并且没有很好的方法来更改hive SQL和hive参数。

[En]

On the contrary, the problem encountered in the task calculation is that hive,hive is upgraded from 0.10 to hive0.13, and the syntax is more demanding and strict, so before upgrading, test the compatibility of hive as much as possible. Hive0.13 can run on hadoop1.02, so before upgrading to hadoop2, upgrade hive to hive0.13 or above, and there is no good way to change hive sql and hive parameters.

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

Original: https://www.cnblogs.com/ggjucheng/p/3977185.html
Author: Hongten
Title: hadoop2升级的那点事情(详解)Flume+Kafka+Storm整合

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/7166/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

发表回复

登录后才能评论
免费咨询
免费咨询
扫码关注
扫码关注
联系站长

站长Johngo!

大数据和算法重度研究者!

持续产出大数据、算法、LeetCode干货,以及业界好资源!

2022012703491714

微信来撩,免费咨询:xiaozhu_tec

分享本页
返回顶部