关于集群小文件治理思路

背景：

遇到集群小文件的问题大概是2018年那会，当时我维护一个600多台节点的cdh集群，当时文件数大概不到一个亿，具体多少已经记不清楚了。

集群的日增原始数据大概30TB，当时业务90%都是离线数据加工，绝大多数job都是mr，刚接管的时候现象就是集群资源基本使用满了，而job基本不会动，后来就进行各种排查，发现集群的rpc超时严重，再后来就是和业务协商怎样去降低集群的文件数。

我在之前的博客里也有总结集群小文件处理的办法。

就是下面这篇文章。

关于较大hadoop集群小文件问题https://cloud.tencent.com/developer/article/1769788

今天我想说的呢是作为一个大数据运维，现在集群已经有很多小文件，那么我们怎样去处理，怎样揪出来这些小文件的具体目录。

下面我就说下我自己的实践经历。

思路：

1、分析小文件产生的原因

2、筛查出小文件具体位置

3、处理

内容：

1、小文件产生的原因：

无非就是job加工，文件较碎，job参数等等。

2、小文件的具体位置：

只要是文件，那么就一定存在hadoop系统中了，hive加工的数据都在hdfs上，那么hdfs信息最全的肯定是fsimage，所以只要我们反序列化了fsimage就可以了，之前有写过怎样反序列化fsimage。

地址是这一篇：

基于prometheus与grafana搭建fsimage解析监控https://cloud.tencent.com/developer/article/1799841

当然这个是我在实验环境进行做的，生产环境肯定不会这么来，这种操作会对namenode产生压力，生产环境怎么做，有兴趣的朋友可以加Aquarius-bob

3、处理小文件：

通过fsimage解析反序列化，我么可以统计出哪些目录的文件数较多，就可以通知业务处理，同时可以统计数据访问时间，发现一些时间久远不使用的数据。