数仓成本治理从哪里入手
成本治理从三处入手：存储（列存压缩格式、生命周期与归档、清理无引用表）、计算（分区裁剪、减少重复扫描与重复加工、复用公共层）、调度（错峰执行、限制并行度、按优先级分级队列）。有效做法是先度量再优化：结合用量账单按表与任务统计存储与计算消耗排名，优先处理高消耗长尾，并把治理项落到责任人与时间点——只出报告不跟进，成本很快会回到原位。
基本信息
| 存储侧 | 列存压缩（ORC、Parquet）、分层保留、清理无引用表与小文件 |
|---|---|
| 计算侧 | 分区裁剪、减少重复扫描、复用公共层结果 |
| 调度侧 | 错峰执行、限制并行度、任务队列分级 |
| 度量方式 | 按表与任务统计存储与计算消耗排名 |
| 落地要求 | 每一项治理有负责人与完成时间 |
典型使用场景
- 季度成本复盘：按表列出存储与计算消耗排名，确认优化对象
- 小文件治理：合并大量小文件，降低元数据压力与查询开销
- 重复加工排查：多张表算同一个指标，合并到公共层
- 调度错峰：把非紧急任务挪出高峰，缓解资源争抢
- 僵尸表下线：长期无查询、无下游引用的表确认后删除或归档
低成本排查清单
低成本排查清单
-- 找出占用存储较大的表，结合查询日志判断是否可清理
SELECT table_name, SUM(file_size) AS size_bytes
FROM table_storage_meta
GROUP BY table_name
ORDER BY size_bytes DESC
LIMIT 20;
-- 小文件检查：文件数远大于分区数通常说明写入产生大量小文件
SELECT table_name, dt, COUNT(1) AS file_cnt, SUM(file_size) AS bytes
FROM table_storage_meta
GROUP BY table_name, dt
HAVING COUNT(1) > 1000
ORDER BY file_cnt DESC LIMIT 20;
-- 说明：先看账单与查询日志再动手，避免优化到无人使用的表上治理动作对照
| 动作 | 预期收益 | 风险 | 前置确认 |
|---|---|---|---|
| 合并小文件 | 查询更快、元数据更轻 | 合并期间写入需错峰 | 是否有实时写入 |
| 压缩格式改造 | 存储显著下降 | 需重写历史数据 | 重写窗口与资源 |
| 生命周期清理 | 存储持续下降 | 误删影响回溯 | 血缘影响面与备份 |
| 公共层复用 | 计算与人力双降 | 需业务口径确认 | 口径一致性检查 |
治理要落到责任人与时间点：只出报告不跟进时，成本会在两三个月内回到原位，下一次复盘还是同一批表。
为省成本删掉明细层是不可逆的选择：一旦需要回溯或重建，成本往往高于当初节省的存储，通常建议改为压缩或转低频存储。
先看账单再优化：按消耗排名做，避免把时间花在消耗很低但结构复杂的表上，投入产出比会好很多。