成本数据采集：计算、存储与网络资源的计量实践
数据平台成本归因，第一步就是要把账算清楚。怎么算？得先把各个资源的消耗数据采回来。这一章，我重点聊聊计算资源、存储资源和网络带宽这三类核心成本的采集方法。说白了，就是搞清楚你的钱到底花在了哪些机器、哪些盘、哪些流量上。
核心观点：成本数据采集的精度，直接决定了后续归因分析的可靠性。采得不准，后面全是白搭。
2.1 计算资源成本数据采集
计算资源，主要指 CPU 和内存。在大数据平台里，这些资源通常被 YARN、Kubernetes 这样的资源管理器统一调度。我个人习惯，采集计算资源成本，核心是抓两个维度：资源使用量和资源单价。
2.1.1 资源使用量采集
资源使用量，不能只看申请量，要看实际占用量。为什么？因为很多任务申请了资源但用不满，你按申请量算成本，对实际执行的任务不公平。
我建议从以下几个层面采集：
- YARN 层面：通过 YARN ResourceManager 的 REST API 或 Timeline Server，获取每个 Application 的 vcore-seconds 和 memory-mb-seconds。这是最直接的计量单位。
- Kubernetes 层面：通过 Metrics Server 或 Prometheus，采集每个 Pod 的 CPU 和内存实际使用量（而非 request/limit）。
- 节点层面：通过 Node Exporter 或 Ganglia，采集物理机或虚拟机的 CPU 利用率和内存使用率，用于分摊基础资源成本。
小技巧：我曾经在采集 YARN 任务数据时，发现很多短任务（几秒就结束）的日志根本来不及写入 Timeline Server。后来我改用直接解析 YARN 的审计日志（audit log），才把数据补全。嗯，这里要注意，审计日志的格式每个版本可能不一样，得定期检查。
2.1.2 资源单价计算
资源单价，说白了就是每单位资源每小时多少钱。这个单价怎么定？我见过两种主流做法：
| 定价方式 | 计算方法 | 适用场景 |
|---|---|---|
| 固定单价法 | 总硬件成本（采购+运维）÷ 总可用资源量 ÷ 时间 | 私有云、自建机房，资源类型单一 |
| 动态单价法 | 根据云厂商实时价格或竞价实例价格动态调整 | 公有云、混合云，资源价格波动大 |
我个人更推荐固定单价法，因为它简单、稳定，适合做长期趋势分析。但如果你用的是公有云，动态单价法更贴近实际账单。
2.1.3 采集架构示例
下面这张图，是我在一个项目中实际用过的采集架构，你可以参考一下：
2.2 存储资源成本数据采集
存储资源，主要包括 HDFS 和对象存储（比如 S3、OSS、COS）。存储成本的计算，比计算资源复杂一些，因为它涉及容量和访问频率两个维度。
2.2.1 HDFS 成本采集
HDFS 的成本，主要来自磁盘空间占用。我建议按目录粒度采集，因为这样可以精确归因到每个业务线或每个任务。
具体做法：
- 通过
hdfs dfs -du -s -h命令，定期扫描每个目录的占用空间。 - 通过 HDFS 的 NameNode JMX 接口，获取每个 DataNode 的磁盘使用情况。
- 结合副本因子（默认 3 副本），计算实际物理存储成本。
避坑指南：我曾经遇到过一个坑——HDFS 的 du 命令在目录数量巨大时（比如上亿个文件），执行一次要跑好几个小时。后来我改用 HDFS 的 fsimage 解析工具，离线分析元数据，才把采集时间从小时级降到分钟级。
2.2.2 对象存储成本采集
对象存储的成本，除了存储容量，还有 API 请求次数和数据传输费用。公有云的对象存储，账单通常按以下维度计费：
| 计费维度 | 采集方式 | 注意事项 |
|---|---|---|
| 存储容量 | 云厂商 API（如 S3 ListObjects） | 区分标准存储、低频存储、归档存储 |
| API 请求次数 | 云厂商账单明细或日志分析 | GET/PUT/DELETE 请求单价不同 |
| 数据传输 | 云厂商流量日志 | 内网流量免费，外网流量收费 |
我个人习惯，把对象存储的成本数据直接拉取云厂商的账单 CSV，然后解析入库。这样最准确，也最省事。
2.2.3 存储成本分摊模型
存储成本怎么分摊到具体业务？我常用的模型是：
存储成本 = 目录占用空间(GB) × 存储单价(元/GB/天) × 存储天数其中，存储单价 = (磁盘采购成本 + 运维成本 + 电费) ÷ 总可用存储容量 ÷ 365 天。
小提示：如果你用的是 HDFS，别忘了把副本因子算进去。比如 3 副本，实际物理存储成本就是逻辑存储成本的 3 倍。这个很多人会忽略。
2.3 网络与带宽成本数据采集
网络成本，在大数据平台里往往被忽视。但如果你用的是公有云，跨可用区、跨地域的数据传输，费用可能高得吓人。
2.3.1 网络流量采集
网络流量，主要采集两个方向：入站流量和出站流量。我建议按以下方式采集：
- 节点层面：通过
sar -n DEV或nload命令，采集每台机器的网卡流量。 - 任务层面：通过 Shuffle 阶段的日志，采集 Spark/Flink 任务的数据传输量。
- 服务层面：通过云厂商的流量日志或 VPC 流日志，采集服务间的网络流量。
2.3.2 带宽成本计算
带宽成本，通常按峰值带宽或总流量计费。我见过两种主流计费模式：
| 计费模式 | 采集指标 | 适用场景 |
|---|---|---|
| 按峰值带宽 | 每 5 分钟采样，取月峰值 | 自建机房、专线 |
| 按总流量 | 累计出站流量（GB） | 公有云、CDN |
我个人更推荐按总流量计费，因为它更公平，也更容易分摊到具体业务。
2.3.3 网络成本归因难点
网络成本归因，最难的是流量溯源。比如，一个 Spark 任务从 HDFS 读数据，然后 shuffle 到另一个节点，最后写入对象存储。这中间的流量，到底算谁的？
我的做法是：
- 在任务层面，通过 Spark 的
taskMetrics采集 shuffle 读写量。 - 在服务层面，通过云厂商的流量日志，按源 IP 和目标 IP 进行流量拆分。
- 最后，按任务 ID 或业务标签，把流量成本分摊到具体业务线。
避坑指南：我曾经踩过一个坑——云厂商的流量日志默认只记录公网流量，内网流量不记录。但跨可用区的内网流量其实也是收费的。后来我专门找云厂商开了内网流量日志，才把数据补全。嗯，这里要注意，内网流量日志通常需要额外付费开启。
2.4 本章小结
成本数据采集，是成本归因体系的地基。计算资源要抓实际使用量，存储资源要区分容量和访问频率，网络资源要关注流量溯源。你想想看，如果这些数据采得不准，后面的分析再花哨也是空中楼阁。