1. 成本盘点总览：为什么要做全链路成本盘点？
做数据平台的人，十有八九都遇到过这种场景：月底一看账单，存储涨了 30%，计算资源翻了一倍，但谁也说不清钱花在哪了。老板问起来，只能含糊地说「嗯…业务增长快，数据变多了」。
说实话，这种回答我自己都不信。数据量增长是事实，但浪费也是事实。我见过太多平台，明明 80% 的存储是冷数据，却跑在热存储上；明明同一个表被 5 个任务重复读取，却没人去复用中间结果。
所以，全链路成本盘点这件事，不是财务的活，是咱们数据平台团队自己的必修课。
1.1 为什么要做全链路成本盘点？
先讲个我自己的经历。几年前我负责一个中型数据平台，月成本大概 80 万。老板突然要求降本 20%，我当时就懵了——因为我不知道钱花在哪。只能凭感觉砍了几个看起来「不太重要」的任务，结果砍完第二天，核心报表延迟了 6 小时。
那次之后我明白了一个道理：没有盘点的降本，就是盲人摸象。
具体来说，做全链路成本盘点有这几个核心价值：
- 看清成本结构：存储、计算、网络、人力，到底哪块是大头？
- 找到浪费点：哪些资源被闲置了？哪些任务重复了？
- 建立成本基线：没有基线，你永远不知道降本是「真优化」还是「假动作」。
- 支撑决策：扩容、迁移、上云还是下云，都得靠数据说话。
核心观点：成本盘点的目标不是「省钱」，而是「让每一分钱都花得明白」。
1.2 盘点的目标与范围
目标其实很简单，就三个字：看得清、算得准、分得细。
- 看得清：所有资源都有归属，没有「孤儿资源」。
- 算得准：成本分摊逻辑合理，业务部门认账。
- 分得细：能拆到团队、项目、甚至单个任务级别。
范围这块，我建议不要一开始就追求「全」。全链路不是指所有系统，而是指数据从产生到销毁的完整路径。具体包括：
| 环节 | 典型资源 | 常见浪费 |
|---|---|---|
| 数据采集 | 日志服务器、Kafka 集群 | 采集频率过高、无用字段过多 |
| 数据存储 | HDFS、对象存储、数据库 | 冷热数据混存、冗余副本 |
| 数据计算 | Spark、Flink、Hive 任务 | 重复计算、数据倾斜、资源空转 |
| 数据传输 | 带宽、API 调用 | 无效拉取、未压缩传输 |
| 数据治理 | 元数据服务、调度系统 | 过期任务未清理、无效依赖 |
我的建议：第一次盘点，先聚焦「存储 + 计算」这两个大头。通常这两块占了总成本的 70% 以上。先把它们理清楚，再逐步扩展到其他环节。
1.3 整体方法论框架
做盘点不能拍脑袋，得有一套可复用的方法。我个人习惯用下面这个四步框架：
- 资源映射：把所有资源打上标签，明确归属。
- 成本归集：把账单拆到每个资源上。
- 效率评估：计算每个资源的利用率。
- 优化建议：基于数据给出可执行的方案。
这个框架看起来简单，但每一步都有坑。比如资源映射，我曾经遇到过一个集群，50% 的节点没有标签，根本不知道是谁的。后来花了整整两周才梳理清楚。
下面这张图可以帮你快速理解整个框架的流转关系：
1.4 避坑指南
做盘点最容易踩的坑，我列几个典型的：
我曾经犯过的错：
- 追求完美数据：非要等所有数据都准确了才开始盘点。结果等了三个月，什么都没做。其实 80% 的准确度就足够发现问题了。
- 忽略隐性成本：只盯着云厂商账单，忘了算运维人力、网络带宽、甚至电费。这些加起来可能占 20%-30%。
- 盘点完就结束：最怕的是盘点报告写完了，放在那里吃灰。成本优化是个持续过程，不是一次性项目。
1.5 什么时候该做盘点？
你可能会问：是不是每年做一次就够了？
我的经验是：季度盘点 + 月度监控。季度盘点用来做深度分析，月度监控用来快速发现异常。如果成本波动超过 10%，就得立刻拉响警报。
另外，这几个信号出现时，建议立刻启动一次全面盘点：
- 月度成本环比增长超过 15%
- 新业务上线后成本翻倍
- 云厂商账单出现看不懂的收费项
- 团队内部开始互相推诿「谁用多了资源」
一个小技巧：在调度系统里加一个成本告警规则。比如某个任务单次运行成本超过 100 元就自动通知。这样能第一时间发现「跑偏」的任务。
好了，这一章的核心就这些。记住一句话：盘点的本质，是把「黑盒」变成「白盒」。后面我们会一步步拆解每个环节怎么做，包括具体的 SQL 脚本、分摊模型、以及我踩过的那些坑。