数据治理-存储资源治理

存储资源治理背景

对于存储资源治理来说，由于早期数仓在存储资源充足情况下，未考虑到后续扩容和存储格式问题导致后续存储资源紧张，从而需要整体治理。

语兴作为数仓开发，在之前工作经历中也经常收到存储水位线告警信息，但遇到这类问题很多数仓同学可能想到的都是加资源，这个想法其实在数仓扩张期适用（全面做中间层、应用层），但到业务缓慢变化，基建完善后回过头来看需要做大面积降本。

存储资源治理思路

梳理出长期未被使用/引用模型，及生命周期不符合当前标准数据模型，未分区，空表，文件数，文件格式，长期全量存储等（通过元数据模型或平台捞出）。

优化方案，可以从这几点优先入手。用最少的人力成本和时间成本，达到显著的优化。下线无用数据表节省存储->存储格式及压缩格式配置->分区生命周期优化->根据业务情景实现节省存储即数据模型优化。

存储资源问题识别及治理

1.获取存储资源元数据及数据血缘元数据

通过采集的元数据信息，进行元数据表梳理及建设（元数据来源可以通过开源工具、数据平台自带元数据、工具二次开发等方式进行获取，这里展示是数据平台进行元数据采集）

存储计算资源治理需要存储资源元数据、数据血缘即可分析存储现状，元数据表DDL如下：

--数据血缘元数据DDL
CREATE TABLE `yx_dwd`.`dwd_meta_table_lineage_detail_df`(
`join_name` string COMMENT '关联用表名', 
`table_layer` string COMMENT '表分层', 
`relation_table_id` string COMMENT '血缘表id', 
`relation_type` bigint COMMENT '血缘类型：-1-上游 1-下游', 
`relation_cata_log` string COMMENT '血缘集群or数据源', 
`relation_db_name` string COMMENT '血缘库名', 
`relation_table_name` string COMMENT '血缘表名', 
`relation_layer` string COMMENT '血缘分层', 
`lineage_update_time` string COMMENT '血缘同步时间', 
`relation_join_name` string COMMENT '血缘表关联用表名，库名.表名')

CREATE TABLE `yx_dwd`.`dwd_meta_table_detail_df`(
  `cata_log` string COMMENT '集群or数据源', 
  `db_name` string COMMENT '库名', 
  `table_name` string COMMENT '表名', 
  `layer` string COMMENT '分层', 
  `creator` string COMMENT '表创建人id', 
  `creator_name` string COMMENT '表创建人姓名', 
  `comments` string COMMENT '表描述', 
  `tbl_type` string COMMENT '内部/外部/视图', 
  `tbl_loc` string COMMENT '表的存储位置', 
  `file_total_fromfile` bigint COMMENT '文件总数: 计算方法为根据表所在的路径的文件信息统计得到', 
  `size_total_fromfile` double COMMENT '存储量:这里是逻辑存储量，未考虑副本，单位为MB；计算方法为根据表所在的路径的文件信息统计得到', 
  `tbl_create_time` string COMMENT '创建时间', 
  `tbl_creator` string COMMENT '文件的创建人', 
  `partition_tbl` string COMMENT '是否是分区表', 
  `tbl_ref_num` bigint COMMENT 'job，query引用的job个数（注意开发模式和任务模式的job算两个）', 
  `tbl_visit_num` bigint COMMENT 'job,query的访问次数', 
  `refer_count` bigint COMMENT '引用次数(元数据中心)', 
  `read_count` bigint COMMENT '读取次数(元数据中心)', 
  `storage_type` string COMMENT '存储格式', 
  `last_modified_time` bigint COMMENT '变更时间', 
  `lifecycle` string COMMENT '表生命周期', 
  `partition_lifecycle` string COMMENT '分区生命周期', 
  `changetimes` bigint COMMENT '修改次数', 
  `file_average_size` double COMMENT '文件平均大小', 
  `tbl_owner_email` string COMMENT '表owner email', 
  `reference_tbl_num` bigint COMMENT '被表引用次数', 
  `has_lifecycle` string COMMENT '是否已设置生命周期', 
  `par_num` bigint COMMENT '分区数量', 
  `little_file_count` bigint COMMENT '小文件数量', 
  `little_file_par_num` bigint COMMENT '小文件分区数量', 
  `lifecycle_whitelist` string COMMENT '是否加入生命周期永久保存'
  )

2.无用/临时数据表下线评估临时表治理

临时表治理

对于临时表治理可以使用正则及rlike从数据表元数据匹配开头为tmp、temp表，同时集合数据血缘元数据进行扫描找到上下游独立节点表进行下线，切记不能对tmp表直接下线，有的tmp表下游仍有依赖（一般都是大家在开发指标时方便用于临时存放）。

select
from `yx_dwd`.`dwd_meta_table_detail_df`
where ds='2024-06-21'
and table_name rlike 'tmp_'
--这里只是一个案例，对于tmp命名位置需要去like匹配，也可以正则匹配

无用表治理

这里我们能看到最后ads是具备数据血缘的，有血缘并不代表有效，而是需要看数据表被使用情况，以及被数据看板使用情况，如看板长期未使用数据表长期未访问，可与业务确认并下线，其次还有一些非临时表的数据表简称空表，可能命名没问题，但无数据存放，也比较好筛选。

可以通过存储资源元数据表可定位最近30天/60天数据表被检索次数（数据地图中搜索次数）、引用次数（被下游使用）、读取次数（查询表次数），这里检索次数获取比较难，可以先用引用次数、读取次数为标准，从而评估数据表是否

3.表存储格式+压缩治理

对压缩格式和存储格式重新定规范

存储选择orc 或parquet，如果平时用spark3跑任务更建议用parquet，使用Parquet作为存储格式时，Spark SQL可以更有效地进行数据的调度和执行。例如，Spark SQL可以优化执行路径，减少stage的执行消耗，并降低CPU的消耗，还可以利用下推过滤器等技术来进一步减少磁盘I/O和内存的占用。

压缩格式选择snappy or gzip，snappy 适用于需要快速压缩和解压的场景，在处理数据时消耗的CPU资源相对较少，gzip偏向于高压缩率，压缩速度慢消耗大，适用于存储归档或传输大量数据以节省存储空间或带宽。

这里更推荐parquet+snappy，因此对于早期text不规范任务，以及大量小文件任务都可以做集体整治，可通过动态分区刷数办法完成表迁移及小文件处理。

这里重点需要识别text表数量，并对整体表存储和压缩格式进行切换，但大体看来切换部分还是较少（目前2024基本都orc or parquet了吧）

4.分区生命周期治理

通过数据表分区生命周期字段去查看，1要确认表分区是否永久，2要确认表分区范围是否合理，因此需要结合当前现状重新指标表分区（分区标准只是概念，通用数据表可参考，但对于di表及部分ads应用表需要因地制宜）

分区生命周期范围：

层级	生命周期
ODS层	1年 or 永久
DIM层	5年（非用户维）
DWD层	3年，部分5年
DWM层	3年，部分5年
DWS层	5年
ADS层	5年

网易easy data 数据地图-生命周期设置

通过制定的数据表标准对原有数据表分区进行整改，但整改之前需要跟表负责人以及下游业务确认，不可直接放弃历史分区（即使是全量分区），可优先梳理出问题分区数据表再进行排期整改。

5.分区优化及增全量修改

对于分区优化，如果只有日期分区可以直接进行分区裁剪如第四点讲到的内容，这里特指二级分区，二级分区例如我们之前课程中讲到的日期+场景、日期+规则，由于二级分区+日期不断增多导致数据查询过慢，分区量暴涨，导致数据模型极为难用，甚至部分表分区超过3w，对于这种情况1.直接拆表按照二级分区内容再做归类。

举例按照之前金融风险名单规则来看，目前二级分区包括最大预期天数、失信人、坏账、多头坏账等等规则，目前规则数量达到500+，所以每天生成分区则是500个，对于这种情况可以按照规则进行拆解，例如金融风险名单-金融负面、金融风险名单-司法负面、金融风险名单-企业负面等等，拆解规则提升模型易用能力，同时也降低了耦合（例如某个规则无法产出）。

增全量分区，可以从订单或其他视角来看，如之前存储采用全量分区存放，虽然提升便捷但分区不能这么支撑，所以需要全改增，对于历史完成的订单我们放到2099-01-01分区形成关单，对于t-1分区则通过create_time及update_time获取t-1对应新增或修改数据存放。