大数据公司业务高速发展过程中数据业务需求越来越复杂，所需要的算力也越来越大，进一步导致集群的规模越来越大，承担的产品也越来越多，集群面临资源负载过高、资源抢占严重、RPC请求负载过高等问题，存储系统也面临空文件过多、垃圾文件过多、小文件过多、平均文件大小过小、文件数持续增长等一系列问题，存储系统稳定性面临很大隐患，作业又面临执行耗时过长、耗资源大、数据倾斜严重等问题，直接导致数据加工异常率过高、数据具备时间有延迟风险、产品交付面临很多风险。
一、问题
1.集群资源&存储不够用了，你们去优化
1）没看到
2）你在说我吗
3）你怎么证明我的程序有问题
4）我知道我的程序有问题，但我太忙没时间优化
5）我知道我的程序有问题，我就是不愿意改
6）我只知道我部分程序需要优化，我也优化了，我的任务完成了
二、解决方案
1.作业TOP
1) 耗内存TOP100
2) 耗CPU TOP100
3) 耗时TOP100
4) 读数据量TOP100
5) 写数据量TOP100
2.待优化作业
1) map平均读取的数据量小于200M
2) reduce平均写入数据量小于300M
3.小文件
1) 空文件
2) 小于10M的文件比例、小于50M的文件比例、小于100M的文件比例、小于200M的文件比例、小于1G的文件比例
3) 小文件和空文件所属用户、所属数据库、所属表、所属分区、所属其他目录
4) 小文件增长根因
4.存储
1) 半年内无访问的数据库目录、表目录、分区目录、其他目录
2) 存储增长根因
5.数据血缘
1) 近3个月、近6个月、近9个月没有被select的表
2) 近3个月、近6个月、近9个月没有被insert的表
3) 近3个月、近6个月、近9个月既没有被select又没有被insert的表
4) 近3个月、近6个月、近9个月在数层面没有被读过的表
注：没有被select和insert过的表不代表没有被访问，比如表的数据被原生MapReduce访问、被Spark/Flink访问、也有可以直接用hdfs命令读过