存储治理一则插曲

中台 数据  收藏
0 / 300

历经大半年的大数据上云也算在近期告一段落。数据上云也是为了更稳定,减少维护成本,增缩容更方便。

数据上云过程中,我又主导了新的一期数据治理。以下记录下存储治理的一个问题排查过程。

问题

现阶段业务并没有爆发增长,但是每日新增存储 GAP (每日新增 0.4%)还挺大,结合 80%的总存储水位线,整体集群存储可用时间只剩 100 天!结合业务知识背景,这显然不合理。

排查

现阶段生命周期设置

主要耗费存储的地方在数仓分层底层部分 image.png

占用量前 1% 的表占比 90% 的存储。

占用量 千分之一的表占比 52% 的存储。

数据量也呈现较大的马太效应。

image.png

分析各层新增存储的GAP较大的表。发现都是单日数据量都比较大的,且业务相对稳定的表。(问题就在这儿,假如生命周期稳定,那么这些表的存储资源消耗应该是稳定的)

发现

怀疑生命周期服务失效。

所以分析生命周期服务代码,其逻辑是从生命周期配置表中获取这个表的生命周期,然后通过 hive 元数据中分区对比,把多余的分区删除掉。

  1. 生命周期服务没问题
  2. 获取的分区有问题

措施

  1. 批量修复 hive 元数据 ("msck repair table {}.{};".format(db, table))
  2. 定时批量修复逻辑加入到生命周期服务中
  3. 重新评估不合理的默认生命周期设置

效果

存储占用以下从 40% 降为 35%左右,日新增约 0.0006% 存储总量

image.png

dataown