Hadoop HBASE集群运维相关笔记 及hdfs参数设置调优等

[toc]

本篇博客将持续更新一些遇到过的Hadoop大数据集群的问题，包括HBASE HDFS的常见问题及相关的解决方案

## 1. HDFS

### 1.1 DataNode服务经常僵死

#### 描述

集群一共设置了8个DataNode，经常不知道什么原因会导致其中3 4 个一直处于僵死状态，重启可以恢复单身过一段时间又会有同样的问题。如果长时间不管，甚至还会namenode服务挂掉。

#### 分析

通过查看/data/var/log/hadoop/hdfs/目录下面DataNode的log日志可以看到:

java. io. IOException: Premature EOF from inputstream

文件操作超租期，实际上就是data stream操作过程中文件被删掉了。通常是因为Mapred多个task操作同一个文件，一个task完成后删掉文件导致。这个错误跟`dfs.datanode.max.transfer.threads`参数到达上限有关。这个是datanode同时处理请求的任务上限，指定用于在DataNode间传输block数据的最大线程数，老版本的对应参数为`dfs.datanode.max.xcievers`

若集群中需要运行HBASE则需要设置更多，网上建议设置为16k。

#### 解决

将`dfs.datanode.max.transfer.threads` 原本为1024调大至10240之后灰度重启DataNode所有节点，隔一定时间后查看服务正常。

### 1.2 DataNode因数据盘损坏重启失败

#### 描述

DataNode单点离线，且一直尝试重启DataNode失败

#### 分析

查看该节点DataNode日志，可以看到

Invalid dfs.datanode.data.dir /data4/hadoop/hdfs/data :

java.io.FileNotFoundException: File file:/data4/hadoop/hdfs/data does not exist

初步判断是有个数据盘坏了，读取不到相应数据，导致每次重启都会失败。

#### 解决

因为需要保障线上服务，需要立刻启动DataNode服务。

hdfs有一个配置`dfs.datanode.failed.volumes.tolerated`可以指定datanode可以容忍多少个失败的目录，默认是0，表示只要失败一个datanode就无法启动。

将该配置修改为1之后再灰度重启DataNode服务，成功。

后续操作则为更换坏盘：

尝试新建文件报错如下

touch 111

touch: cannot touch `111': Read-only file system

硬盘的健康状况

smartctl -H /dev/sdd

result后边的结果：PASSED，这表示硬盘健康状态良好

如果这里显示Failure，那么最好立刻给服务器更换硬盘

可以肯定是这块sdd硬盘出现问题，可以将此节点服务器，从hadoop群集中排除，

umount这块硬盘，之后更换个新的，重新格式化mount，再将服务器重新加入到hadoop群集中即可。

网上有些朋友说进行linux修复模式，fsck下硬盘，但是为了避免再出现问题，还是直接换个新的。

### 1.3 优化Hadoop Balancer平衡的速度

Hadoop的HDFS集群在使用一段时间后，各个DataNode节点的磁盘使用率肯定会出现不平衡的情况，也就是数据量层面的数据倾斜。

我们都知道当HDFS出现数据不平衡的时候，就会造成MapReduce或Spark等应用程序无法很好的利用本地计算的优势，而且Datanode节点之间也没有更好的网络带宽利用率，某些Datanode节点的磁盘无法使用等等问题。

可以参考 https://blog.51cto.com/xiaoxiaozhou/2139249

## 2. HBASE

### 2.1 master服务无法启动error or interrupt while splitting logs

#### 描述

集群因为网络问题，几个节点几小时处理网络孤立状态，导致hbase master服务与几个region server服务挂掉。

网络恢复之后，尝试启动master，频繁拉起失败

#### 分析

查看master日志，有以下报错

> org.apache.hadoop.hbase.master.MasterFileSystem: Failed splitting of [inc-dp-hbase-02,60020,1335429401869, inc-dp-hbase-03,60020,1335429401847]

java.io.IOException: error or interrupt while splitting logs in [hdfs://inc-dp-hbase-01.hst.bjc.kfc.alidc.net:9000/hbase/.logs/inc-dp-hbase-02,60020,1335429401869-splitting, hdfs://inc-dp-hbase-01.hst.bjc.kfc.alidc.net:9000/hbase/.logs/inc-dp-hbase-03,60020,1335429401847-splitting] Task = installed = 1 done = 0 error = 0

at org.apache.hadoop.hbase.master.SplitLogManager.splitLogDistributed(SplitLogManager.java:268)

at org.apache.hadoop.hbase.master.MasterFileSystem.splitLog(MasterFileSystem.java:276)

at org.apache.hadoop.hbase.master.MasterFileSystem.splitLogAfterStartup(MasterFileSystem.java:216)

at org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:487)

at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:326)

at java.lang.Thread.run(Thread.java:662)

在尝试分割WAL目录文件的时候出错，导致HMaster服务异常终止

#### 解决

有两种解决方法，这里采取了第一种

1. 将wals下文件备份到其他地方；

2. 在hdfs-site.xml配置中设置`hbase.master.distributed.log.splitting`参数value为false

> 原理

>

>在之前的博客[hbase技术细节](https://blog.csdn.net/asd136912/article/details/101168177)第三节RegionServer的故障恢复中，讲述了Distributed Log Splitting 分布式日志切分的实现，分布式就不是master单独在恢复了，而是充分使用各个RegionServer上的资源，利用多个RegionServer来并行切分Hlog，提高切分的效率。

>

>但是这种方式有个弊端是会产生很多小文件（切分的Hlog数 宕机的RegionServer上的Region数）。比如一个RegionServer有20个Region，有50个Hlog，那么产生的小文件数量为2050=1000个。如果集群中有多台RegionServer宕机的情况，小文件更是会成倍增加，恢复的过程还是会比较慢。

>

>master服务启动失败原因应该是因为集群region数量较多，生产的小文件数量太多，导致处理失败。

### Ref

1. https://community.cloudera.com/t5/Support-Questions/Is-there-any-recommendation-for-dfs-datanode-max-transfer/td-p/120288

2. https://blog.csdn.net/levy_cui/article/details/51143058

3. https://blog.csdn.net/jiangheng0535/article/details/19114415