数仓成本治理与表生命周期：钱花在哪儿、怎么省下来

考察点

降本是近几年数据团队绕不开的考核项，这道题考你有没有算过数仓的账。面试官想听到：成本结构拆解（存储 vs 计算）、生命周期怎么分层设定、冷表怎么识别和下线、以及成本分摊机制。追问常落在「历史数据不能删怎么办」和「怎么推动业务方配合治理」。

参考答案

先拆账：钱花在哪

数仓成本就两块。存储：表的物理占用，重点看增长曲线——很多团队的存储每年翻一倍，因为数据只进不出。计算：任务消耗的 CPU/内存时长，重点是找出「每天全量扫一张大表只为算个日活」这类浪费。治理第一步是把账单拆到表和任务粒度，按团队、按业务域排名，找出 top 消耗者——成本分布极度不均，治理 top 20 的表和任务通常能省下一半的钱。

生命周期：让数据有保质期

表生命周期（TTL）是存储治理的主抓手，核心原则是按分层差异化设置，不能一刀切：

落地方式：建表 DDL 强制带 lifecycle 属性（MaxCompute 原生支持，Hive 体系自研分区清理任务），新表评审时必须声明保留策略；元数据平台定期扫无 TTL 的表催办。

执行删除前要过两道闸：血缘确认无下游依赖，以及合规与重算需求豁免——金融类数据有监管保留要求，核心链路的可重算性依赖 DWD 完整性，这类数据不能为了省钱删掉。舍不得删又少访问的，归档到廉价冷存储（对象存储低频/归档档），成本能降一个数量级。

冷表下线与存储优化

冷表识别用两个信号：血缘出度为零（没有下游任务依赖）+ 查询日志长时间无人访问（比如近 90 天无扫描）。满足条件的表走下线流程：通知负责人 → 确认 → 备份 → 删除。临时表、测试表是大头——很多数仓里 tmp_、test_ 前缀的表能占到一两成存储，定个规则（创建 30 天自动清理）就能回收。

存储格式层面的优化是白捡的钱：统一转列存（ORC/Parquet）并开高压缩比编码（ZSTD 替代默认压缩，通常再省 20-40%）；小文件合并（凌晨跑 merge 任务，避免几 KB 的文件拖垮 NameNode 和查询性能）；分区设计检查，杜绝拿全表当单分区存的表。

计算侧治理

大头在全量扫描：每天全量重算一张几年历史的表，改成增量处理（只算变化分区 + merge）能砍掉九成计算量。其余常见浪费：数据倾斜导致的长尾任务（资源申请了但大部分节点闲着）、失败重试风暴（上游没就绪就空跑重试，加依赖检查和指数退避）、资源超配（任务申请 32G 实际用 4G，按历史用量自动推荐规格）。扫描量也要管：强制分区裁剪，禁止 select * 扫全表的即席查询，在引擎入口做代价预估拦截。

机制比技术重要

技术上都不难，难的是持续有人做。有效的机制是成本分摊：账单拆到每个团队甚至每张表的负责人，进团队的预算考核，配合治理看板（存储水位、环比、待治理清单）。没有分摊，公共存储就是公地悲剧；有了分摊，业务方自己会来问「这张表能不能删」。再加一条：新增要审核，存量要考核——新表立项评估存储增长预估，避免治理速度赶不上新增速度。

可能的追问

• 业务方不肯删历史数据怎么办？ 给替代方案而不是硬删：归档到冷存储保留可查能力（查询慢一点但都在），或者只保留年度快照分区。多数「不能删」其实是「怕以后要用」，归档方案能覆盖这个心理。
• 生命周期设置错了把在用的数据删了怎么办？ 删除动作必须可恢复：先移到回收站保留 N 天再物理删除，元数据里记录删除操作日志；分区清理任务先 dry-run 输出待删清单，人工确认核心表。
• 压缩率提升有什么坑？ ZSTD 等高压缩比算法解压 CPU 开销更高，对高频查询的热表可能得不偿失；冷数据用高压缩、热数据用平衡型压缩，按访问频率分档。