记一次HDFS空间清理：Non DFS Used

文章中记录了问题发现和解决的过程，单纯为了解决问题的伙伴请到最后一段。

发现问题

什么是Non DFS Used

解决

发现问题

入职到公司后，维护集群时有一项日常不是很频繁的任务就是清理集群数据。我们公司的Hadoop（CDH 5.x）集群大概不到50台的样子，总DN容量在450T左右。这个数据量对于大的互联网公司可能不算什么，但我之前一直也没遇到过如此多的数据，百T级别的容量都要清理空间，感觉公司的数据量实在是庞大。

但随着入职时间的增加，在进行日常运维的时候发现了一些不太合乎逻辑的问题。比如我们看到的告警信息如下

机器的总容量是7.8T，已经使用的空间是4T，但空间部分居然是黄色的告警标识。进入该DN后发现了问题

告警中提示可用空间只有1T了。以我二十多年10以内加减法的经验，这里肯定有什么环节出了问题。于是登录这台机器，通过Linux，命令查看实际情况。

[root@hostname ~]# df -lh
文件系统                容量   已用  可用    已用% 挂载点
/dev/sde               1.1T  658G  388G   63% /u04
/dev/sdc               1.1T  647G  398G   62% /u02
/dev/sdb               1.1T  658G  387G   63% /u01
/dev/sda               1.1T  649G  396G   63% /data
/dev/sdd               1.1T  658G  387G   63% /u03
/dev/sdg               2.2T  553G  1.7T   25% /u05

为了能看得更清楚，我把其他非数据磁盘的信息删除掉了。这台机器有6块盘，最后一块2.2T的是因为一直报空间不足扩容添加的。从这些信息来看

已用空间 = 658 + 647 + 658 + 649 + 658 + 553 = 3823 G ≈ 4T

总空间= 1.1 * 5 + 2.2 = 7.7 T

linux查看的信息同第一张图片CDH机器信息中截图的数据基本是吻合的。我们所剩的空间应该还剩下3.7T左右，但集群的告警也不应该是无故出来的，剩下的2.7T去哪了呢。只能去查看DataNode的信息

到一台机器上执行hdfs dfsadmin -report可以列举出所有的DataNode的信息。这台机器的报告信息如下，同样去掉了一些无用数据

Name: IP:50010 (机器名)
Hostname: 机器名
Configured Capacity: 8241232003072 (7.50 TB)
DFS Used: 4066627752645 (3.70 TB)
Non DFS Used: 3020135345763 (2.75 TB)
DFS Remaining: 1154468904664 (1.05 TB)

可以看到，这个Non DFS Used的空间跟我们丢掉的空间是基本吻合的。那这个Non DFS Used是什么呢？

什么是Non DFS Used

从名字上来看，应该是"不是HDFS使用的空间"，我们知道HDFS是建立在服务器文件系统之上的虚拟文件系统，也就是说服务器的磁盘HDFS可以使用，那其他程序同样可以使用。我们在HDFS中设置了数据盘是/u01 ~ /u05, 那这五块盘中其他程序存储文件所占用的空间应该就是Non DFS Used。

后边的地址详细的讲解了什么是Non DFS Used，感兴趣的同学可以阅读。什么是Non DFS Used

值得一提的是，文章中指出的Non DFS Used 公式中

Non DFS used = ( Total Disk Space - Reserved Space) - Remaining Space - DFS Used

这里的Reserved Space指的是配置项(dfs.datanode.du.reserved)所配置的内容，是HDFS自己预留的，一般为30G，这30G是不算在Non DFS Used中的。但应用程序在HDFS数据盘预留的空间都要归类到Non DFS Used的空间中。(此处为个人粗浅理解)

我们公司集群设置的是10G，截图如下

排除是该值设置过大。

言归正传，集群的这个告警会是其他应用程序占用数据磁盘导致的吗？经过我实际查看，数据磁盘上除了HDFS的文件，并没有其他内容。

所以导致Non DFS Used 过高的还另有原因。

解决

经过我坚持不懈的努(bai)力(du),终于发现了这么一篇文章Reserved RBW space is not released if client terminates while writing block

文章的大概内容是：在客户端向HDFS写入数据时，首先要将自己需要的空间保留住，防止自己写着写着空间不足了。这些被保留的空间会随着数据的写入慢慢释放掉。但是，如果在写入的过程中，写入程序被中断了，那这些被保留的空间只能等到DN被重启后才会释放。

我们集群每天在跑的azkaban任务有几千个，每天都会有任务因为各种原因失败重跑或者直接kill。我觉得上边这个应该就是Non DFS Used过高的根本原因了。So~ 挑一台机器重启试试，测试结果是Non DFS Used从2.7T+变成了300G+,重启有效。

PS ：重启后要等一段时间再执行report命令查看。让子弹飞一会。

因为告警的机器还是挺多的，所以选择滚动重启。那最终我会为集群释放多少空间出来呢？

[hdfs@hostname ~]$ hdfs dfsadmin -report > hdfs_report
[hdfs@hostname ~]$ cat hdfs_report | grep Non | awk 'BEGIN{sum=0}{sum+=$4}END{print sum}'
92336932414662

大概是90T，按照京东上磁盘的价钱，这一波为公司省下了14w+。