数据采集与清洗：账单数据源接入、任务日志解析、数据标准化处理
做成本分析，最怕什么？
不是数据量大，也不是计算复杂。而是——数据源乱七八糟，格式五花八门，字段对不上号。
我见过太多团队，花了两周搭好分析模型，结果数据一灌进去，账单金额和任务资源对不上。查了三天，发现是时间戳差了8小时。这种坑，踩一次就够了。
所以这一章，咱们就聊聊数据采集和清洗。说白了，就是把云厂商的账单、集群的任务日志，变成一套干净、对齐、可计算的数据集。
2.1 账单数据源接入
先看账单。不同云厂商的账单格式差异很大，但核心字段是相通的。
| 字段类别 | 典型字段 | 说明 |
|---|---|---|
| 时间维度 | 账单日期、计费周期 | 按小时或按天粒度 |
| 资源维度 | 实例ID、存储桶名、卷ID | 关联到具体资源 |
| 费用维度 | 原价、折扣、实付、单价 | 区分定价与折扣 |
| 用量维度 | 存储量、请求次数、流量 | 按量计费的基础 |
| 标签维度 | 项目标签、环境标签 | 用于成本分摊 |
我个人习惯，先把账单拉成一张宽表。不管云厂商给的是CSV、JSON还是Parquet，统一转成DataFrame结构。字段名也统一——比如AWS的LineItemType，阿里云的账单类型，我都映射成bill_type。
raw_bill_type。排查问题时，能快速对比映射是否正确。
2.2 任务日志解析
账单有了，接下来是任务日志。这里说的任务，可能是Spark作业、MapReduce任务，也可能是容器Pod。
任务日志里藏着真正的资源消耗。比如一个Spark任务，跑了3小时，用了200个vCore和500GB内存。这些信息，账单里看不到，但日志里有。
我常用的解析流程是这样的：
- 日志采集：从YARN ResourceManager或Kubernetes API拉取任务事件。
- 字段提取：解析出任务ID、提交时间、结束时间、申请资源量、实际使用量。
- 状态过滤：只保留
FINISHED或SUCCEEDED状态的任务。失败任务不计入成本。 - 资源归一：把vCore·小时、GB·小时算出来。这是后续成本分摊的基础。
核心公式：
资源消耗量 = 资源规格 × 运行时长
例如：200 vCore × 3小时 = 600 vCore·小时
嗯，这里要注意。任务日志里的时间，通常是UTC。而账单里的时间，可能是本地时区。我曾经因为这个问题，对账对了一整天。后来我定了个规矩：所有时间字段，统一转成UTC+0，再存库。
2.3 数据标准化处理
数据接进来了，但还没完。标准化这一步，决定了后续分析的成败。
我把它拆成四个步骤：
- 字段对齐：账单和日志里，都有的字段——比如时间、资源ID、项目标签——要统一命名和类型。
- 单位统一：账单里存储单位是GB，日志里可能是MB。不统一，算出来全是错的。
- 缺失值处理：有些任务没有打标签，或者账单里缺少实例规格。我一般用
UNKNOWN填充，而不是直接丢弃。丢了数据，成本就漏了。 - 关联键构建：这是最关键的一步。用
资源ID + 时间窗口作为关联键，把账单和任务日志连起来。
时间范围匹配，才解决了这个问题。
标准化之后的数据，长什么样？我给你看个例子：
| task_id | resource_id | start_time | end_time | vcore_hours | mem_gb_hours | cost_usd | project_tag |
|---------|-------------|---------------------|---------------------|-------------|--------------|----------|-------------|
| job_001 | i-abc123 | 2025-03-01 10:00:00 | 2025-03-01 13:00:00 | 600 | 1500 | 12.50 | data_platform |
| job_002 | i-def456 | 2025-03-01 14:00:00 | 2025-03-01 16:00:00 | 400 | 800 | 8.20 | ml_training |
你看，每一行就是一个任务，资源消耗和成本都对齐了。后续做成本分摊、趋势分析，直接拿这张表算就行。
2.4 整体流程框架
说了这么多，我画了一张图，把整个数据采集与清洗的流程串起来。你一看就明白了。
你看，流程不复杂。但每一步都有细节。数据采集与清洗，占整个成本分析工作量的60%以上。前面做扎实了，后面的分析就是水到渠成的事。
我个人建议，把清洗逻辑写成可复用的脚本，每次接入新数据源，改改配置就行。别每次都从头写一遍，那是给自己挖坑。