云上成本治理通用原则

难度与前置

难度：架构
前置：知道云上按存算、请求、流量计费；能区分「平台成本」与「业务作业成本」。
读完能做什么：建立可迁移的成本治理框架（计量、配额、回收、存储分层、查询治理），用账单与利用率指标验收，不绑定单一厂商控制台。

适用场景

• 云上数仓 / 湖仓费用季增，缺少负责人与配额
• 开发环境、废弃表、空跑作业吞预算
• 需要向业务解释「钱花在哪」并推动优化

不适用：

• 某一家云的点击级教程（原则可映射到各厂商）
• 未公开的公司项目账单与内部套餐细节
• 纯商务议价（工程侧先把利用率做上去）

真实场景（一条）

湖仓月度费用环比 +35%。拆分后：① 开发账号无关停的预计算集群日挂 24h；② 冷数据仍在热存储；③ 若干失败重试作业无上限。治理：分账标签强制；闲置关机策略；生命周期转冷；作业失败重试与并发配额。两月后费用回到基线 ±5%，且大促弹性仍在。

怎么做（步骤清单）

1. 先建立「能看见」——计量与分账

没有标签/项目空间就谈不上治理。

维度	要求
归属	每个资源有 team / product / env
作业	调度任务 ID 进账单或成本日志
存储	库表负责人 + 热度
环境	prod / staging / dev 分账

强制门禁示意：
- 创建集群/桶/项目：缺少 cost标签 → 拒绝
- 每日出「无主资源」清单

与平台落地原则一致时，参见 云上数仓通用原则。

2. 成本结构分层（通用模型）

总成本
├─ 计算：批作业 / 弹性引擎 / 常驻集群 / 在线查询
├─ 存储：热 / 温 / 冷 / 备份 / 跨区复制
├─ 网络：跨区、出网、流式吞吐
└─ 平台：元数据、调度、监控、日志保留

优化顺序经验：闲置回收 → 失败重试/空跑 → 存储分层 → 查询/作业调优 → 架构级弹性。

3. 闲置与生命周期回收

对象	策略
开发集群	下班/空闲自动停；定时启
无主表	通知 → 只读 → 归档 → 删除（保留审计）
临时路径	TTL 目录，到期清
快照/备份	保留策略（如 7/30/180 天）分级

# 示意：列出 N 天无访问对象（湖仓/对象存储工具替换）
# list-stale-objects --days 90 --prefix warehouse/
echo "object,last_access,size_gb,owner"

注意：删除策略要审批流；本知识库规范亦强调勿随意删文档——同理，生产表删除必须可追溯。

4. 计算侧：配额、重试、弹性

1. 队列配额：按团队 CPU/CU 上限，防一家挤垮
2. 重试上限：失败风暴是隐藏账单杀手
3. 并发：同作业多实例互斥
4. 弹性：高峰扩、低谷缩；常驻需利用率门槛
5. 规格权利：默认小规格，授权后升配

作业模板默认：
- max_retry = 2
- timeout 与 SLA 对齐
- 大扫描必须分区裁剪（代码扫描/EXPLAIN 门禁）

5. 存储分层与格式

手段	收益
热温冷分层	单价下降
压缩与列存	扫描量下降
小文件合并	降低请求与作业时长（见 Hive 小文件治理）
冗余副本策略	非必须数据降副本 / 降跨区

-- 示意：表体量与近 30 天查询热度（元数据仓）
SELECT
  db_name, table_name,
  size_gb,
  query_cnt_30d,
  CASE
    WHEN query_cnt_30d = 0 AND size_gb > 100 THEN 'cold_candidate'
    WHEN query_cnt_30d < 5 THEN 'warm_candidate'
    ELSE 'hot'
  END AS tier_hint
FROM meta_table_stats
ORDER BY size_gb DESC
LIMIT 100;

6. 查询与出口治理

• BI / ad-hoc：扫描量限额、大查询熔断
• 物化高频宽表（见 宽表 vs 星型）换重复重算
• 结果缓存与下推过滤
• 禁止 SELECT * 扫年分区上生产仪表盘

-- 坏：全历史扫描
-- SELECT COUNT(*) FROM dwd_order_di;
-- 好：强制分区
SELECT COUNT(*) FROM dwd_order_di WHERE dt = '${biz_date}';

7. 组织机制（比工具更重要）

机制	内容
月度成本评审	Top 资源 + Top 作业
预算与告警	团队预算 70%/90% 预警
优化积分	节省归团队可见，激励回收
架构门禁	新系统必须带成本模型

8. 落地路线图（90 天）

D0–30：标签/分账、无主清单、闲置关机
D31–60：存储分层、小文件、失败重试上限
D61–90：查询限额、队列配额、月度评审固化

常见坑（至少牢记这些）

1. 只砍计算不看存储
   冷数据长期热价存放，静静超过计算费。

2. 无标签的「共享池」
   人人可写，账单无法追责，优化无法闭环。

3. 为省钱关所有弹性
   大促打爆，业务损失大于云账单。

4. 删表当第一手段
   无审批与备份的删除制造更大事故成本。

5. 优化只靠「调参英雄」
   无门禁与模板，下周费用回归。

6. 把厂商折扣当治理完成
   议价后利用率依旧低，总成本仍会爬升。

如何验收（可量化）

• [ ] ≥ 95% 费用可归属到 team/product/env
• [ ] 闲置开发资源：非工作时段关机率达标
• [ ] 冷数据候选完成分层或归档，热存储增量受控
• [ ] 失败重试导致的计算占比下降
• [ ] 单位业务指标成本（如 /千单、/TB 扫描）趋势向下或持平
• [ ] 月度评审纪要与 Top10 优化项闭环

echo "month,total_cost,tagged_pct,compute,storage,retry_waste_est"
# 2026-08,100,72,60,30,12
# 2026-09,88,96,50,28,4

-- 单位成本示意
SELECT
  biz_date,
  cloud_compute_cost / NULLIF(order_cnt, 0) AS cost_per_order
FROM cost_kpi_daily
WHERE biz_date >= date_sub('${biz_date}', 30)
ORDER BY biz_date;

健康画像示例：
- tagged_pct >= 95%
- idle_dev_shutdown_rate >= 90%（约定窗口）
- retry_waste / compute <= 5%

相关面试题

占位：与题库小程序对齐后补链接（建议关联：云上成本治理、存算分离、配额与分账、存储分层）。

---

改写说明：结构与判断标准参考 Wood 原创数仓/面试文，已改写成可执行清单；仅通用原则，无厂商绑定与未公开公司细节。