考察点
成本题是近年高频题，背后是各公司降本的大背景。面试官想看你能不能把「省钱」讲成一套有方法论的工程动作：先盘点清楚有什么，再按热度分层治理，最后建机制防止反弹。追问会落在具体数字怎么算、下线表怎么推动、成本怎么分摊到团队。
参考答案
为什么先盘点再治理
成本治理最大的障碍不是技术，是「不知道有什么」。集群里几万张表，多少在用、谁建的、归谁负责，没人说得清。所以第一步永远是资产盘点，而盘点的抓手是元数据：把表的技术元数据（大小、分区、格式）、操作元数据（最近访问时间、访问次数、下游依赖）、责任元数据（owner、所属团队）三合一，形成资产清单。没有访问记录就先补埋点——查询引擎的审计日志接进来，这是盘点的基础设施。
盘点的产出：给每张表画个像
按访问热度把表分四档：高频（周内有访问）、低频（月内有）、冷（三个月无人碰）、僵尸（半年以上零访问且无下游依赖）。再叠加存储大小，二维交叉一画，治理优先级就出来了——又冷又大的表是第一批处理对象，又热又大的表是优化对象（检查分区设计、文件格式、是否有大 SQL 全表扫）。冷而小的表先放着，治理它省不出几个钱。
存储治理的组合拳
- 生命周期分层：热数据标准存储，30/90 天转低频，历史数据转归档（S3 Glacier/OSS 归档存储单价只有标准存储的几分之一）。对象存储原生支持生命周期规则，配置即可。
- 僵尸表下线：流程比技术难。标准动作是「公示→降权→删除」：先给 owner 发下线通知，无人认领的表先 rename 加下划线前缀（禁读观察期两周），有报错就能秒回滚，无异议再删。直接删迟早出事故。
- 文件治理：小文件合并（bin-pack compaction）、TEXT 格式转 Parquet/ORC（压缩率差好几倍）、快照过期和孤儿文件清理例行化。
- 压缩算法：ZSTD 换 Snappy 通常能再省一截，CPU 代价可接受。
计算治理：大头往往在算不在存
存储是固定支出，计算是弹性黑洞。抓手：扫描量 Top N 的 SQL 定期晾晒优化（很多是全表扫没加分区过滤）；大任务错峰调度，避开凌晨资源高峰；资源队列按团队配额隔离，防止一个团队的失控任务拖垮集群；Flink/Spark 常驻任务的资源利用率审计（很多任务申请了 8 核实际用 1 核）。更进一步是账单分摊：按团队/项目把存储和计算成本拆出来出账单，成本有了归属，治理才有动力——这是 FinOps 思路在数据平台的落地。
防反弹：机制比运动重要
专项治理省下来的钱，三个月就能涨回去。防反弹靠三条：新建表必须带 owner 和生命周期标签（DDL 层强制）、存储配额按团队限制（超了要申请）、成本指标进周报（环比涨幅超阈值要解释）。把成本从「运维的事」变成「每个数据开发的事」，治理才算闭环。
怎么向面试官收尾
成本治理最好的收尾是量化：盘点了多少张表、下线了多少 PB、账单降了百分之几。哪怕是估算口径也要给数字，治理工作的价值本来就是用数字说话的。
可能的追问
- 怎么判断一张表能不能下线？ 答零访问记录（看审计日志，观察期至少覆盖月结/季结报表周期）+ 无下游依赖（血缘）+ owner 确认或失联，三者齐备才进下线流程。
- 归档存储取回慢的问题怎么处理？ 答归档前评估取回概率，合规要求的备份数据归档，可能回查的历史数据放低频层；归档取回有小时级延迟和取回费用，要算总账。
- 计算成本怎么拆到具体 SQL？ 答引擎侧的查询审计日志记录扫描量/CPU 时长，按用户和团队聚合；云厂商（MaxCompute/EMR）一般有现成账单 API，自建集群要自己算。