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