数据采集与计量：把资源消耗算清楚

好，咱们进入第二章。上一章聊了为什么要做账单精细化管理，这一章就得落地了——数据怎么来？怎么算？

说白了，你要给业务部门出账单，首先得知道每个任务、每个用户到底用了多少资源。CPU用了多少秒？内存占了多少GB？HDFS存了多少TB？网络流量走了多少？这些数据采集不到，后面的分摊、定价全是空谈。

我刚开始做数据平台的时候，就吃过这个亏。当时觉得“资源用量大概估一下就行”，结果月底对账，业务部门拿着监控数据来找我——差了30%以上。嗯，从那以后，我再也不敢在计量模型上马虎了。

计算资源计量模型：CPU和内存怎么算

计算资源，主要是CPU和内存。在YARN、Kubernetes这类资源调度系统里，每个任务都会申请一定量的资源。但申请量不等于实际使用量，这里就有两种计量思路。

CPU计量：核心秒数

CPU的计量单位，我建议用核心秒数（Core-Seconds）。为什么？因为一个任务可能跑1小时，也可能跑10分钟，单纯看“几个核”不够精确。

公式很简单：

CPU用量 = 分配的CPU核心数 × 运行时长（秒）

举个例子：一个Spark任务申请了10个CPU核心，跑了30分钟（1800秒），那它的CPU用量就是：

10 core × 1800 s = 18000 core-seconds

但这里有个坑——实际使用率。我记得有一次排查账单异常，发现某个任务申请了20个核，但实际CPU利用率只有15%。如果按分配量计费，这个用户就亏大了。

内存计量：GB-小时

内存的计量逻辑类似，单位用GB-小时（GB-Hours）。公式：

内存用量 = 分配的内存（GB） × 运行时长（小时）

比如一个任务申请了8GB内存，跑了2小时：

8 GB × 2 h = 16 GB-hours

这里要注意：内存不像CPU那样可以“共享”，分配了就是独占的。所以内存计量一般按分配量来算，比较公平。

资源类型	计量单位	推荐计量方式	采集频率
CPU	Core-Seconds	分配量 / 实际使用量	每5秒
内存	GB-Hours	分配量	每5秒
GPU	Card-Hours	分配量	每10秒

存储资源计量模型：HDFS和OSS

存储资源的计量，比计算资源复杂一些。因为存储有容量和时间两个维度，还要考虑副本数、存储类型（冷热数据）。

HDFS计量：文件大小 × 副本数 × 存储时长

HDFS的计量公式：

HDFS存储量 = 文件逻辑大小 × 副本因子 × 存储时长（天）

举个例子：一个用户上传了100GB的数据，HDFS默认3副本，存了30天：

100 GB × 3 × 30 天 = 9000 GB-天

这里有个容易忽略的点——小文件问题。我曾经遇到一个用户，存了100万个1KB的小文件，每个文件占一个Block（128MB），实际物理存储是逻辑大小的1000倍以上。这种场景下，按逻辑大小计费，平台就亏了。

OSS计量：按实际存储量 + 请求次数

对象存储（OSS/S3）的计量模型更细，通常包含三部分：

• 存储量：按实际存储的字节数 × 存储时长，单位GB-月
• 请求次数：GET/PUT/LIST等操作次数
• 流量：外网下行流量（内网一般免费）

我建议内部账单可以简化——只计存储量，请求次数和流量可以打包在基础费用里。但如果是给外部客户出账单，那就得按云厂商的标准来。

网络流量计量：别小看这笔钱

网络流量，在很多公司是被忽略的。觉得“带宽又不贵”，但等你真正算起来，会发现网络成本可能占到总成本的10%-20%。

网络流量的计量模型，核心是区分方向和路径：

• 方向：入站（Ingress）vs 出站（Egress）
• 路径：内网 vs 外网 vs 跨AZ/跨Region

一般规则：入站免费，出站收费。内网流量免费，跨AZ/跨Region流量收费。

举个例子：一个数据同步任务，从北京Region拉到上海Region，每天100GB：

跨Region流量 = 100 GB/天 × 30 天 = 3000 GB

按云厂商0.5元/GB算，一个月就是1500元。如果这种任务有几十个，成本就上来了。

整体计量模型架构

说了这么多，咱们用一张图把整体架构串起来。下面这张SVG图，展示了从数据采集到计量的完整链路。

数据采集的工程实践

模型定好了，怎么落地？我分享几个关键点。

采集频率：别太密，也别太疏

计算资源建议每5秒采集一次，存储资源可以放宽到每小时。为什么？CPU和内存变化快，5秒能捕捉到峰值；存储变化慢，小时级就够了。

数据链路：端到端延迟

从采集到入库，延迟控制在1分钟以内。我见过一个系统，采集延迟30分钟，用户跑完任务半小时后才能看到用量——体验很差。

数据质量：去重和校验

采集数据可能会有重复或丢失。我建议在计量引擎层做幂等处理——同一个任务ID的同一时间段，只保留一条记录。另外，每天跑一次对账任务，把计量数据和调度系统的日志做交叉验证。