遇到hadoop 集群挂掉情况处理情况分析

 

 早上起来发现我们的spark调度任务挂掉（spark运行报错日志报错是数据块丢失），当时查看hadoop集群节点状态，发现bd-node01节点是Down状态（当时是挂掉了）。但是节点挂掉不应该导致任务运行不了，因为正常情况下hadoop集群数据都是有备份的，至少得是2份，即使bd-node01挂掉，也会在其它节点找bd-node01上数据的备份数据就行读取。于是带着疑问看了下overview页面发现确实是有块丢失。

 于是查看hadoop集群相关数据的副本数：

hive ods库副本数是2

 

dwd库 副本数是1：

没想到hive dwd层数据副本数竟然是1，这就说通了为啥hadoop 一台datanode节点管掉，导致spark任务运行不了，因为我们跑的spark任务读取的是dwd层的数据，dwd层数据副本数是1，bd-node01挂掉，相应副本数为1的数据就会丢失，其它节点没有相应的备份数据，所以使用到bd-node01节点上的dwd层数据的spark任务都会运行不了。

当时疑惑为啥ods的副本数是2，而dwd层的副本数是1？我们ods层数据是来自mysql，通过sqoop拉取到ods库中的hive表；而dwd层是通过spark进行etl处理到hive库中的表。也就是说一个是通过sqoop,一个是通过spark,那肯定是spark导致副本数是1，于是在网上查看spark有关副本数的配置：conf/hdfs-site.xml

spark设置的副本数是1

而hadoop-2.6.0-cdh5.14.0/etc/hadoop/hdfs-site.xml 设置的副本数：

 

 hadoop 下的副本数是2

这就解释了为啥sqoop拉数据到hdfs数据副本数是2，而spark运行完后存到hdfs的副本数是1。

副本数设置成1其实是可以理解的，因为当时我们集群的存储空间很小（最上面图片是升级磁盘空间后的集群），如果dwd数据设置副本数为2的话，集群根本不能用啊，所以只保证了源数据ods是两个备份。

一、日志查找，分析原因

上面的分析都是hadoop集群一台节点挂掉后引出的疑问，是什么原因导致的集群节点挂掉还得看日志。在hadoop控制台是有节点bd-node01 挂掉的时间2021-11-01 00：17：23。找这个时间段内节点bd-node01日志：

vi  /hadoop-2.6.0-cdh5.14.0/logs/hadoop-hadoop-datanode-bd-node01.out

内存溢出oom了，导致这个节点挂掉了。 

凌晨开始的时候我们跑的是sqoop 任务，sqoop任务使用的内存量其实是很小的，最大的任务内存使用量可能是6-8g,我们服务器的内存是16g的，除去系统占有的和其它应用占有的至少还有10g可以使用。查看节点最大的使用内存yarn上的配置yarn-stie-xml：10240 (10g 下面图片是升级后的)

 内存我认为是可用的。以前跑sqoop任务的时候从没发生过这种情况，我们把集群节点内存由16g升级32g后第三天出现节点挂掉的情况,至于是什么原因导致的oom暂时没有分析出来，列出可能的原因：

1.sqoop拉任务由于数据倾斜导致的(因为我们mysql的业务数据主键id不是从1开始自增的，有中间跳id情况，而且跳的挺大的，比如id突然有小值跳到20多亿的值，这种情况下我们全量拉取数据肯定会数据倾斜；业务不允许我们增量拉取数据的！)，但我觉得这中情况只是导致sqoop任务运行慢不会导致oom

2.是网上查的大部分说：是和服务器max user processes 参数有关，我查了下我们集群节点max user processes 是4096，查看命令：ulimit -u 我把节点 max user processes 都设置为：8192了

设置方法参考：Linux - 修改系统的max open files、max user processes (附ulimit的使用方法) - 瘦风 - 博客园 (cnblogs.com)

虽然把 max user processes 设置成了 8192,目前集群良好，但原因不一定是它。

二、集群节点挂掉后，后续处理

1.由于bd-node01 是oom导致的datanode挂掉（服务器没有挂掉），磁盘存储的数据还在，只需要把bd-node01节点重新启动就行。进入到bd-node01服务器

启动命令：./hadoop-daemon.sh start datanode

2.现在存在另一个问题，因为bd-node01节点挂掉（不是服务器挂掉），导致hdfs数据存储不平衡，bd-node01使用存储空间相对较少，本该在它上面的数据分不到其它节点上了，当跑sqoop任务时，也就是map任务会把临时文件落地到磁盘，这就导致存储空间相对来说多的节点压力变大，这中情况在集群存储空间充足的条件下时不会发生的，集群会自动调节过来的。

 

处理方法：利用hadoop balancer 功能进行数据平衡功能（在没有任务跑的时候）

执行命令：sh start-balancer.sh

 hdfs dfsadmin -setBalancerBandwidth 20971520 (指定DataNode用于balancer的带宽单位byte)

nohup hdfs balancer -threshold 10 &    #10为各节点存储的浮动比例10%上下浮动

各个节点达到数据平衡后， start-balancer.sh这个进程会自己停掉。