📚 存储资源治理

聚焦存储资源治理，衔接前期计算资源、数据表、小文件、数据质量治理内容，后续将延伸至安全治理，整体覆盖数据治理核心领域。本内容更适配互联网行业，传统行业（国企、金融保险等）因有自身标准，需结合实际调整。

一、存储资源治理背景与触发因素

存储与计算的本质都是资源消耗，存储治理并非主动开展，通常由以下场景触发，属于“问题驱动型”工作：

• ⚠️ 告警触发：存储磁盘负载高于水位线（如 70%），收到系统告警或邮件通知，需紧急整治。

• 📈 管理需求：老板为体现“降本增效”价值，用于向上汇报，推动治理工作开展。

• 🔄 阶段需求：数仓建设后期，业务拓展放缓、团队绩效压力大，需通过治理挖掘价值；早期扩张期多专注中间层 / 应用层建设，常忽略存储规划与冷备热备设计。

二、存储治理核心思路与前提

1. 核心逻辑：围绕数据表展开，依赖源数据支撑

存储资源与数据表强绑定，所有治理动作均需以“源数据”为基础，核心覆盖：数据表元数据、数据血缘、存储格式、压缩方式、分区生命周期、数据模型等维度。

2. 对业务的影响：友好且可控

多数治理动作不影响下游协作，仅两类操作需重点关注：

• 🔴 高影响：分区生命周期优化（若业务方需回溯历史数据，修改周期可能导致数据丢失）、数据模型重构（需协调下游适配）。

• 🟢 低影响：存储格式优化、压缩方式调整、无用表下线（确认无引用后）等，均不干扰下游使用。

3. 实施优先级：按“影响小、易操作”排序

排期依据：业务影响程度（优先选无影响项）→ 操作复杂度（优先选简单易落地项）→ 见效速度（优先选短期可出成果项）。

三、核心步骤：从源数据获取到治理落地

第一步：获取源数据——治理的“基石”

🔍 源数据分类：存储治理核心依赖两类源数据，无需过度发散：

• 数据表元数据：表名、库名、集群、存储量、文件数、创建人、生命周期、访问次数、存储格式等。

• 数据血缘数据：表的上游依赖、下游引用关系，明确数据流转链路。

• 补充：其他源数据（计算任务时长、质量监控数据等）可作为辅助参考。

📌 源数据采集方法：

• 开源工具：早期可使用 enberry 等工具采集。

• 企业平台：主流方式，通过内部数据平台采集，或基于 222K 等工具二次开发实现。

• 关键要求：需支持实时采集，否则数据地图中无法及时查询表信息，影响治理效率。

📊 源数据核心字段示例：

• 血缘数据：表名、上游表、下游表、所属集群、库名。

• 数据表元数据：表类型（内部 / 外部）、存储量、文件数、生命周期、压缩格式、读取次数、检索次数、创建时间、comment 说明。

第二步：识别待治理表——精准定位问题

基于源数据，重点排查三类问题表：临时表、无用表、空表，需结合血缘与访问情况综合判断。

1. 临时表：命名随意，需结合血缘判断

• 🔍 特征：通常以 TMP 开头 / 中间 / 结尾，或用姓名命名，创建目的多为临时取数、数据校验、数据比对。

• ⚠️ 判断误区：仅靠正则匹配命名无法 100% 识别，需结合血缘——若临时表在上下游链路中（如作为指标计算的中间表），则不可下线；仅当“无血缘关联 + 命名符合临时特征”时，可安全删除。

• 📝 产生原因：业务方临时需求后遗忘删除，是存储浪费的常见来源。

2. 无用表：有血缘但无实际使用价值

• 🔍 特征：存在完整血缘链路（如 ODS→DWD→ADS），但下游无实际使用场景，典型如“服务的报表 / 看板已无人访问”。

• ✅ 排查方法：

• - 看板访问量：统计下游看板近 7/30 天 UV（优先 UV 而非 PV，避免自身操作干扰），无访问则标记为可疑。

• - 表访问数据：查看“检索次数”（数据地图中搜索并点击的次数）、“读取次数”（select 查询次数），无数据则确认为无用表。

3. 空表：有结构但无数据

• 🔍 特征：命名可能正规（如 DWD_XXX），但长期无数据写入，或仅依赖历史静态数据，无实际业务价值。

• 📌 处理原则：无论是否有血缘，均需下线，避免空占存储资源。

第三步：存储格式与压缩优化——降本核心手段

通过优化存储格式与压缩方式，在不影响性能的前提下减少存储占用，是性价比最高的治理动作。

1. 推荐组合：Parquet+Snappy

• 📊 格式选择：优先 Parquet（Spark3 环境下），其次 ORC，拒绝使用 Text 格式（无压缩，存储占用极大）。Parquet 优势：列存储，减少查询时的 IO 与 CPU 消耗，支持减少 Stage 数量。

• 🗜️ 压缩方式：优先 Snappy（压缩速度快，适配业务场景），Gzip 虽压缩率高但速度慢，仅在非高频访问场景使用。

2. 改造方法：动态分区回刷

• 📝 操作逻辑：将历史数据从老格式（如 Text）迁移至新表（Parquet+Snappy），通过动态分区一次性刷写所有历史数据。

• ⚠️ 注意事项：存储格式无法直接修改，需通过建新表迁移数据实现；操作不影响下游业务，可放心执行。

第四步：分区生命周期治理——平衡存储与需求

区分“表生命周期”与“分区生命周期”，前者控制表是否存在，后者控制历史分区是否保留，核心是“按需保留，避免过度存储”。

1. 基础规则

• 📅 表生命周期：线上业务表默认设为“永久”，仅临时表设为短期（如 7-15 天）自动删除。

• 📆 分区生命周期：按分层设置保留时长，核心原则“越上层（应用层）保留越短，基础层保留越长”。

2. 各分层推荐保留周期

• 🔸 ODS 层：DI（增量）表永久保留；DF（全量）表保留 1-3 年。

• 🔸 维度表：日期、地区等小数据量维度表可永久 /5-10 年；用户维度表若为全量存储，保留 30 天 -1 年（结合拉链表记录历史变更）。

• 🔸 DWD 层：保留 3-5 年，作为明细数据层支撑后续分析。

• 🔸 DWS/ADS 层：指标 / 标签表保留 5-10 年；若数据量极大（如用户画像），可按需裁剪至 3-5 年。

3. 实施注意事项

• ⚠️ 避免盲目修改：修改前需与域负责人、下游业务方确认，是否有历史数据回溯需求，防止分区删除导致数据丢失。

• 📋 规范流程：列出待修改表清单，制定排期，逐一沟通后执行，不可批量操作。

• 平台差异：EZ Data 支持修改生命周期，DataWorks 需通过语句调整，部分平台无界面修改功能。

第五步：二级分区优化与全量改增量

1. 二级分区优化：解决“分区爆炸”问题

• 🔍 痛点：二级分区（如日期 + 规则、日期 + 场景）随场景增多导致分区数暴涨（如超 3 万），查询性能急剧下降，叠加小文件问题更严重。

• ✅ 解决思路：分而治之，从模型层面拆表解耦。

• � example：金融风控场景中，二级分区存储 200+ 规则（逾期、失信、坏账等），可按“域”拆分子表——金融负面域（逾期、坏账）、司法负面域（失信、诉讼），每个子表二级分区仅保留对应场景，减少分区数量。

2. 全量改增量：减少重复存储

• 🔍 适用场景：订单、交易等高频更新数据，原全量存储导致每日数据重复。

• ✅ 实施方法：

• - 增量同步：基于 create_time/update_time，仅同步 T-1 的新增 / 变更数据。

• - 历史归档：将状态稳定的历史数据（如完成的订单）归档至固定分区（如 2099 年），不再参与每日增量更新。

四、治理效果评估与长期维护

1. 评估指标：用“老板听得懂”的语言呈现

• 📊 核心指标：

• - 量化成果：下线临时表 / 无用表数量、释放存储容量（如 XX TB）。

• - 效率提升：压缩比提升百分比、查询性能改善情况。

• - 降本价值：转化为费用节省（最直观，便于向上汇报），结合公司集群存储计费标准计算。

2. 打分体系：量化表的合规性

基于源数据构建打分模型，对每张表进行合规性评估，项目与个人绩效分开核算：

• ❌ 扣分项：空表（严重扣分项）、临时表无短期生命周期、使用 Text 格式、分区数超 3 万、生命周期设置不合理。

• ✅ 加分项：使用 Parquet/ORC 格式 +Snappy 压缩、生命周期符合分层标准、访问频率与存储周期匹配。

3. 长期维护：无平台也能落地

• 🔄 监控方式：定期扫描源数据，生成存储分析报表（存储总量、每日增量、合规率等）。

• 🛠️ 无平台解决方案：基于源数据编写自定义规则与指标，判断表的合规性，手动生成看板或打分结果，核心是“有源数据就能治理”。

五、核心总结 📝

• 1. 核心前提：源数据是存储治理的基础，需覆盖表元数据与数据血缘。

• 2. 治理逻辑：先识别问题表（临时 / 无用 / 空表），再通过格式优化、生命周期调整、分区优化等手段落地，优先选对业务影响小的动作。

• 3. 关键原则：分而治之（拆表解决分区爆炸）、按需保留（生命周期匹配业务需求）、量化成果（聚焦降本价值）。

• 4. 落地保障：沟通优先（修改生命周期前确认需求）、流程规范（排期执行）、长期监控（基于源数据持续优化）。