历经大半年的大数据上云也算在近期告一段落。数据上云也是为了更稳定，减少维护成本，增缩容更方便。
数据上云过程中，我又主导了新的一期数据治理。以下记录下存储治理的一个问题排查过程。
问题
现阶段业务并没有爆发增长，但是每日新增存储 GAP （每日新增 0.4%）还挺大，结合 80%的总存储水位线，整体集群存储可用时间只剩 100 天！结合业务知识背景，这显然不合理。
排查
现阶段生命周期设置
主要耗费存储的地方在数仓分层底层部分
占用量前 1% 的表占比 90% 的存储。
占用量 千分之一的表占比 52% 的存储。
数据量也呈现较大的马太效应。
分析各层新增存储的GAP较大的表。发现都是单日数据量都比较大的，且业务相对稳定的表。（问题就在这儿，假如生命周期稳定，那么这些表的存储资源消耗应该是稳定的）
发现
怀疑生命周期服务失效。
所以分析生命周期服务代码，其逻辑是从生命周期配置表中获取这个表的生命周期，然后通过 hive 元数据中分区对比，把多余的分区删除掉。
- 生命周期服务没问题
- 获取的分区有问题
措施
- 批量修复 hive 元数据 （"msck repair table {}.{};".format(db, table)）
- 定时批量修复逻辑加入到生命周期服务中
- 重新评估不合理的默认生命周期设置
效果
存储占用以下从 40% 降为 35%左右，日新增约 0.0006% 存储总量
