3. 成本数据采集与账单结构
在 Databricks 上做 FinOps，第一步不是“省钱”，而是“看清钱花在哪里”。如果账单数据本身是断裂的、口径不一致的，后续的预算、归因、优化都会变成猜测。本节围绕四个数据来源展开：账单导出（Billing Export）、系统表（System Tables）、标签（Tags）与每日成本快照，并说明它们如何组合成一条可追溯的成本分配链路。
一、账单导出：最权威的“财务口径”
Databricks 的账单导出会把账户级用量与费用明细以 Parquet 或 Delta 形式投递到云存储（如 S3、ADLS、GCS），通常按小时或按天分区。它是财务对账的权威来源，字段一般包括：billing_origin_product（产品来源，如 JOBS、SQL、ALL_PURPOSE）、workspace_id、sku_name、usage_unit、usage_quantity、cloud、usage_start_time、usage_end_time，以及 custom_tags 和 identity_metadata 等归因字段。
账单导出的关键价值在于“可审计”：金额、用量、折扣、承诺消费（Commit）都在这里体现。但它有两个天然短板：一是延迟，通常 T+1 甚至更久；二是粒度粗，很多运行时细节（谁提交的、哪个集群、哪个 Notebook）并不直接可见。因此账单导出适合做月度对账与总账，不适合做实时归因。
二、系统表：最细的“运行口径”
系统表位于 system.billing.usage、system.billing.list_prices、system.compute.clusters、system.compute.warehouses、system.lakeflow.jobs 等 schema 下，通过 Unity Catalog 直接以 SQL 查询。它比账单导出更细：能拿到 cluster_id、warehouse_id、job_id、run_as、owned_by、usage_metadata 等运行维度。
典型做法是把用量与价格关联，算出“估算成本”：
SELECT
u.usage_date,
u.workspace_id,
u.sku_name,
u.usage_unit,
SUM(u.usage_quantity) AS qty,
SUM(u.usage_quantity * p.pricing.default) AS est_cost
FROM system.billing.usage u
LEFT JOIN system.billing.list_prices p
ON u.sku_name = p.sku_name
AND u.cloud = p.cloud
AND u.usage_unit = p.usage_unit
AND u.usage_end_time >= p.price_start_time
AND (p.price_end_time IS NULL OR u.usage_end_time < p.price_end_time)
WHERE u.usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY 1,2,3,4;注意：系统表算出来的是估算成本，与账单导出可能存在差异，原因包括折扣、承诺消费分摊、税费、跨云汇率等。FinOps 的正确姿势是：用系统表做日常归因与优化，用账单导出做月度校准，并记录两者的差异率。
三、标签：把成本“挂”到业务上
标签是成本分配的灵魂。Databricks 支持集群、SQL 仓库、Job、Pipeline 等对象上的自定义标签，并会随用量进入账单导出与系统表。建议至少定义三类标签：
- 成本中心：
cost_center = data-platform，用于财务分摊。 - 业务域：
domain = marketing，用于业务归因。 - 环境：
env = prod / staging / dev，用于区分可优化空间。
标签治理的难点不在“打”，而在“持续打”。建议通过集群策略（Cluster Policy）和 Job 模板强制注入标签，避免依赖人工。对于无法打标签的共享资源（如共享 SQL 仓库），则需要用分摊规则处理，例如按查询次数、按 DBU 消耗比例、或按业务方约定比例分摊。
四、每日成本快照：把“流水”变成“可对比的曲线”
账单导出和系统表都是“流水”，每天新增一批数据。要观察趋势、做异常检测、支撑预算，需要把它们加工成每日成本快照表。快照表通常按 usage_date + workspace_id + sku_name + cost_center + domain + env 聚合，字段包括：当日用量、当日估算成本、当日账单成本、7 日均值、环比变化率、是否超阈值等。
快照表的价值在于“可对比”：今天和昨天比、本周和上周比、实际和预算比。当某天成本突然上升 40%，可以立刻下钻到 workspace、SKU、cluster、job，定位是哪个作业、哪个集群、哪次运行导致的。这就是从“看账单”到“管成本”的关键一步。
五、把四者串成一条可执行链路
一个可落地的采集与分配链路通常这样组织：
- 接入：开启账单导出到云存储，同时确认 Unity Catalog 已启用系统表。
- 标准化：把账单导出与系统表分别落到 Delta 表，统一字段命名与时间口径（建议统一用 UTC）。
- 打标：通过集群策略、Job 模板、SQL 仓库配置强制注入 cost_center、domain、env 三类标签。
- 分摊：对共享资源按 DBU 消耗比例或查询次数分摊到业务域。
- 快照：每日调度生成成本快照表，计算 7 日均值、环比、超阈值标记。
- 校准：每月对比账单导出与系统表的差异率，若差异超过 5%，排查折扣、承诺消费、汇率或标签缺失。