背景：
遇到集群小文件的问题大概是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解析反序列化，我么可以统计出哪些目录的文件数较多，就可以通知业务处理，同时可以统计数据访问时间，发现一些时间久远不使用的数据。
