3. 成本可观测性数据源接入

成本治理的第一道门槛不是优化，而是“看得见”。在 Databricks 中，成本信息天然分散在多个平面：云厂商账单记录的是资源实际扣费，Databricks 系统表记录的是用量与作业归属，审计日志记录的是“谁在什么时候做了什么”，集群指标记录的是资源利用效率，而标签体系则决定这些数据能否被拼接到同一个业务维度上。本节的目标，是把这五类数据源接入到同一套可查询、可关联、可下钻的成本数据底座中。

五类数据源各自回答什么问题

先明确每类数据源的定位，避免重复采集或错误归因：

• 账单导出（Billing Export）：云厂商侧的最终扣费事实，回答“实际花了多少钱”，包含 SKU、用量、折扣、信用抵扣等，是成本核算的最终口径。
• 系统表（System Tables）：Databricks 侧的用量事实，如 system.billing.usage、system.billing.list_prices、system.compute.clusters，回答“哪个工作区、哪个作业、哪个集群消耗了多少 DBU”。
• 审计日志（Audit Logs）：操作与主体事实，回答“谁创建了集群、谁提交了作业、谁改了配置”，用于责任归属与异常行为定位。
• 集群指标（Cluster Metrics）：资源效率事实，回答“集群开了多久、CPU/内存利用率如何、是否存在长期空转”。
• 标签体系（Tags）：维度事实，回答“这笔成本属于哪个业务线、项目、环境、成本中心”。

这五类数据源的关系可以用下面的数据底座结构图表示。图中展示了从原始数据源到统一成本事实表的汇聚路径，以及标签体系作为公共维度贯穿其中的作用。

账单导出：拿到最终扣费口径

以 AWS 为例，需要在 Billing 控制台开启 Cost and Usage Report（CUR），将报告投递到 S3 路径，例如 s3://company-billing/cur/databricks/，格式选择 Parquet，并勾选“包含资源 ID”。随后在 Databricks 中创建外部表或使用 Lakeflow 连接器读取该路径。关键字段包括 line_item_usage_account_id、line_item_product_code、line_item_unblended_cost、resource_id 与 line_item_usage_start_date。其中 resource_id 是后续与 Databricks 集群 ID 关联的桥梁。

需要注意：CUR 存在约 24 小时的延迟，且可能因折扣、信用抵扣出现负值行。在建模时应保留原始金额字段，同时派生 net_cost 与 list_cost 两列，避免后续口径混淆。

系统表：DBU 用量与价格

Databricks 系统表是成本可观测性的核心。启用后可直接查询：

SELECT
  usage_date,
  workspace_id,
  cluster_id,
  sku_name,
  usage_quantity AS dbu,
  usage_unit
FROM system.billing.usage
WHERE usage_date >= current_date() - INTERVAL 30 DAYS;

价格信息来自 system.billing.list_prices，通过 sku_name 与 usage_unit 关联即可把 DBU 换算为金额。集群元数据来自 system.compute.clusters，可获取集群名称、创建者、标签与自动终止配置。这三张表构成了 Databricks 侧成本事实的主干。

审计日志：把成本落到人

审计日志通过诊断日志投递到 S3 或事件中心，再以外部表方式接入。典型事件包括 clusters.create、jobs.submitRun、cluster.resize。将审计日志中的 user_identity.email 与 cluster_id 关联到系统表，就能回答“这个集群是谁创建的、谁在用它跑作业”。这一步是成本归因从“资源”走向“责任人”的关键。

集群指标：识别空转与低效

集群指标可通过 Ganglia 或云监控导出，核心字段为 cluster_id、timestamp、cpu_utilization、memory_utilization、uptime_seconds。判断空转的常用规则是：连续 30 分钟 CPU 利用率低于 5% 且无活跃作业，即标记为疑似空转。这类规则应写入成本事实表的派生列，供下游看板直接筛选。

标签体系：让成本可归因

标签是跨源关联的公共键。建议在集群、作业、SQL 仓库三个层面统一打标，至少包含以下字段：

标签必须在资源创建时注入，事后补标会丢失历史成本。对于已存在的资源，可通过系统表 system.compute.clusters 的 tags 字段批量回填，但需接受历史数据不完整的现实。

构建统一成本事实表

五类数据源接入后，用一条按天调度的作业将其汇聚为 cost_fact 表。核心逻辑是：以系统表 usage 为主表，左关联 list_prices 得到金额，左关联 clusters 得到标签，左关联审计日志得到责任人，左关联集群指标得到利用率，最后用 resource_id 与账单导出做对账。对账差异超过 5% 时应触发告警，因为这意味着存在未被系统表覆盖的资源消耗。

完成这一步后，成本数据底座即具备三个能力：按任意标签维度下钻、按责任人追溯、按资源效率识别浪费。后续的预算监控、异常检测与优化建议，都建立在这张事实表之上。