Databricks 云数仓成本预算与告警设置

每个分析团队都经历过这样的时刻：月底账单来了，一个 SQL 仓库已经花超了预算，也许是算力整夜开着没关，也许是一次临时查询在季度评审期间自动扩容去服务 80 个 Tableau 用户。成本是真实存在的，但更让人沮丧的是：直到为时已晚，谁都不知道。

主动式成本管理颠覆了这一模式。与其在事后做取证式的账单分析，不如在一分钱花出去之前就设好护栏——预算与仓库、团队或 BI 工作负载绑定。在你选定的阈值上触发警报，用仪表板实时呈现使用趋势，这一切都在 Databricks 数据与 AI 平台上完成。如果你正从本地系统或其他云数据仓库迁移，现在正是把这种治理机制落地的时机。

为什么反应式成本管理会失败？

数据仓库工作负载带来了独特的成本挑战。SQL 仓库服务于交互式、由人驱动的工作负载（BI 仪表板、临时分析、嵌入式分析），其需求不可预测且呈突发式。一场高管全员大会触发 200 个仪表板同时刷新，就能在几分钟内让成本飙升。大多数组织开启 FinOps 之旅的方式如出一辙：有人下载上个月的使用量 CSV，打开数据透视表，然后开始提问。这种做法会在四个方面失灵：

• 你无法看到是谁在花钱。使用量汇总到平台层面，而不是归因到造成它的团队或查询，因此没有人需要为某个数字负责。
• 没有人对预算负责。如果没有与仓库或团队挂钩的支出目标，那个对 2 TB 表跑 SELECT * 的分析师永远感受不到成本。平台团队默默地把这笔账吸收了。
• 你发现得太晚了。等到上个月的 Excel 报告暴露出超支时，它已经过去两个计费周期了，而引发它的那个决策已经无从查起。
• 人工审查无法扩展。五个仓库也许还能通过每月的数据透视表审查。但是一旦扩展到几十个，要支撑 Tableau、Power BI 和 Looker 上的数百名分析师，就变得无法管理了。

主动式成本管理——归因、预算、警报、仪表板和优化——能解决全部五个问题。

从 Serverless 开始：第一个成本决策。

在设置预算之前，先选对仓库类型。SQL Serverless 仓库是 Databricks 对大多数工作负载的推荐选项。它们能在几秒内启动，在查询结束的那一刻缩容，并让智能工作负载管理为你分配算力，因此你只为实际的查询执行付费，而不是为闲置的待命状态付费。

如果你正从传统云数据仓库迁移，这是一次重大转变。大多数传统平台按常开算力收费，或要求人工做扩缩容决策。Serverless 消除了整整一类成本错误。

Lumen Technologies亲身验证了这一点：将两个关键电信系统从本地数据仓库迁移到 SQL Serverless，使算力成本降低了 30-40%，查询速度提升了 90%。该系统现在能自动扩缩容，每 10 分钟处理约 7 GB 数据，Serverless 消除了通常与突发式、实时工作负载相关的“常开税”。

主动式成本管理的五大支柱

该框架由五大支柱组成。前四个让你的支出变得可见；第五个才是真正把支出降下来的那个：

• 成本归因。给一切打上标签，这样你就知道谁在哪个仓库上花了多少钱。
• 预算。在账户、工作区或团队层面定义月度支出目标。
• 警报。在支出接近或超过阈值的那一刻收到通知。
• 仪表板。可视化仓库趋势，让成本成为一等运营指标。
• 优化。从源头上降低工作本身的成本。

支柱 1：两个层面的成本归因

你无法管理你无法归因的东西，而对于仓库来说，这意味着两个层面：仓库本身和单个查询。一个告诉你哪个仓库花了钱；另一个告诉你仓库内部是谁花的。

第 1 层：给仓库打标签

SQL 仓库支持以 key:value 对形式存在的自定义标签，这些标签会传播到 system.billing.usage，把消耗的每一个 DBU 关联到某个团队、项目或成本中心。打标签对所有仓库类型的工作方式都相同——Classic、Pro 和 Serverless 都在仓库层面打标签，所以你学一种模式就能处处应用。

在 UI 中的 SQL Warehouses > 你的仓库 > Edit > Tags 下设置标签，或通过 REST API 创建仓库：

通过 REST API 打标签

至少应用三个维度：团队（谁拥有它）、成本中心（谁付钱）和用例（BI 服务、临时查询、计划刷新）。

目前还没有一种原生策略能强制仓库标签，所以任何人都可以创建一个没有标签的仓库。改为把强制执行构建到你的供给流程中——用 Terraform、Declarative Automation Bundles 或 REST API 创建仓库，并把标签写进定义里，把 UI 视为例外。本文后面的归因缺口查询会抓住任何漏网之鱼。

第 2 层：给查询打标签

仓库标签告诉你某个仓库上个月花了 4,000 美元。它们不会告诉你其中 60% 来自一个每 15 分钟刷新一次的 Power BI 仪表板。这个缺口很重要，因为仓库是共享的——一个 BI 仓库要服务几十个仪表板、几个 dbt 模型和一连串临时查询。

查询标签（公开预览版）通过把业务上下文附加到单个 SQL 语句上来弥补这个缺口：

这些标签会落到 system.query.history（公开预览版）的 query_tags 列中，与 executed_by 和 statement_id 并列，这样你就可以按仪表板、模型或成本中心来分组支出，而不是按仓库。有些工具会帮你设置这些：从 dbt-databricks 1.11.0 开始，模型查询会自动打上 dbt 模型名称的标签，而 Power BI 会通过 ADBC 驱动传递工作区和数据集标识符。

有两个注意事项：查询标签仅适用于 SQL 仓库查询；而且由于它们存在于查询历史而非计费数据中，你需要自己把两者关联起来才能得到按查询计算的成本。

在编写任何 SQL 之前，请检查 Governance Hub（Beta）中的 Cost 页面——这是一个账户级别的支出、成本驱动因素、预算和标签覆盖情况视图，也是查看你的用量究竟有多少可归因的最快方式。账户管理员可以从账户控制台的 Previews 页面启用它。

支柱 2：在账户控制台中设置预算

创建预算

在账户控制台中，转到 Usage > Budgets，点击 Add budget，然后配置：

• Name: 描述性名称（例如，"Analytics SQL Warehouses, Monthly"）
• Amount: 以美元计的月度目标
• Scope: 按工作区和/或标签筛选（例如 Team:Analytics）
• Email notifications: 当支出达到预算金额时收到通知的收件人

预算配置示例

关键模式是分层预算：团队级预算用于问责，再加上账户级预算作为安全网，用以捕获任何漏网之鱼。

请记住，预算是一种监控机制，而不是硬性上限。它们不会停止用量或阻止收费，因此你的账单仍可能超过该金额。其目标是提高认知并快速响应，而不是可能导致生产仪表板在刷新中途中断的关停。

GetYourGuide直接测试了这一点：将其所有 Looker 工作负载整合到 SQL Serverless 上，使 BI 服务成本降低了约 20%，查询速度提升了 35%，尽管该团队此前一直认为 Classic 集群会更便宜。仓库类型的选择是一个值得重新验证的预算决策，而不是一次性的决定。

解读你的消耗速率

点击任意预算即可查看当前支出与目标的对比、剩余预算，以及逐日消耗速率可视化。对于数据仓库而言，此图表尤其能说明问题：

• 线性每日消耗 意味着稳定的 BI 服务成本。
• 周一/周五出现峰值的锯齿形表明即席探索集中在工作日。
• 月中突然阶跃上升意味着部署了一个新的仪表板而没有进行成本审查。
• 逐渐向上漂移意味着自然采用速度超过了你的预算假设。

支柱 3：警报，成本治理的神经系统

预算告诉你你处于什么位置。警报告诉你何时该行动。

预算电子邮件警报

创建预算时，添加电子邮件收件人，当支出超过预算金额时会通知他们。无需任何代码。

对于基于阈值的警报，请创建 Databricks SQL Alerts，直接查询 `system.billing.usage`。以下是最重要的模式：

当每日 SQL 仓库支出超过阈值时发出警报

节奏警报：预计月末支出将超过预算

这是团队获得最大价值的模式。它不是等到超支之后才发出警报，而是预测月末支出，并在该预测越过你的预算之前触发，此时你仍有时间采取行动：

每四小时调度一次，并路由到 Slack 或电子邮件。它为团队争取数天时间来应对（调整仓库规模、优化昂贵查询、推迟批处理），以免预算被突破。

检测物化视图刷新带来的隐藏成本

物化视图刷新成本是团队最常忽略的成本，因为它们按无服务器管道用量而不是仓库用量计费。一个设置为每 15 分钟刷新一次、而源数据每天只更新两次的视图，会白白消耗这部分差异。将刷新计划与底层数据实际变化的频率相匹配，然后直接监控管道支出：

支柱 4：仪表板和持续监控

警报是时间点触发器。仪表板提供持续的背景信息。Databricks 提供 预构建的用量仪表板，账户管理员可以将其导入任何启用了 Unity Catalog 的工作区。这些仪表板涵盖支出趋势、Top-N 分析、标签筛选和按仓库下钻。对于自定义监控，有两个查询特别有用：

按团队划分的 SQL 仓库成本

未归因的 SQL 用量（归因缺口）

未打标签的 SQL 用量就是你的归因缺口，即无法追溯到任何团队的仓库支出。将其降至零。

Raiffeisen Bank International直接在 Databricks 系统表上构建了自己的成本监控和预测平台，具备按仓库、按用户和按工作负载的可见性。其回报既是技术上的也是文化上的：工作负载提速 3-4 倍，更重要的是，当团队能够看到自己的支出并被要求解释它时，行为会在没有强制要求的情况下发生改变。

支柱 5：优化，真正改变账单的支柱

前四个支柱关乎看清你的支出。这一个关乎降低支出，也是大多数团队会跳过的支柱。从两项可同时改善成本和性能的更改开始。

为 Unity Catalog 托管表开启预测性优化。Databricks 会根据每张表的实际查询方式为你运行 OPTIMIZE、VACUUM 和 ANALYZE，并且通过 CLUSTER BY AUTO，它会在查询模式变化时调整聚簇键。扫描的数据更少意味着查询更快、DBU 消耗更少，而且无需维护计划。对于 2024 年 11 月 11 日或之后创建的账户，它默认开启，并将在 2026 年前逐步覆盖较旧的账户。

默认使用无服务器仓库，以获得前面所述的启动和空闲经济学优势——对大多数团队来说，这占节省的大部分，且无需持续投入。

在此基础上，有几个设置值得调优：

• 收紧自动停止。Pro 和 Classic 默认在空闲 45 分钟后停止；无服务器默认 10 分钟，你可以在 UI 中降至 5 分钟，或通过 API 降至 1 分钟。BI 仓库在最后一个仪表板关闭后的每一分钟空闲都是浪费。
• 设置语句超时（Beta——启用预览，然后通过 API 按仓库设置）。一个失控查询不应烧掉一个周末的计算资源；在 BI 仓库上保持较短，在 ETL 上保持较长。
• 指定一个默认仓库（管理员设置 > 计算），这样快速查看十行数据就不会唤醒一个 ETL 规模的集群，并且从 Small 或 Medium 开始，而不是过度配置。
• 有目的地纵向扩展或横向扩展。纵向扩展——更大的规格，现在可达 5X-Large（公共预览版）——使单个重查询更快；横向扩展（更高的最大集群数）服务更多并发用户。选错方向是一个常见且代价高昂的错误。

数据层也很重要：OPTIMIZE、VACUUM 和 liquid clustering 各自都能减少查询所需的计算量，而这在每天数千次 BI 查询中会不断累积。

在这一切之下，大多数成本问题其实是查询问题。缺失连接键或对宽表执行 SELECT * 的成本，无论仓库如何调优都一样——而第一支柱中的归因才能告诉你该去修复哪些查询和仪表板。

关键要点

1. 从第一天起就将无服务器和归因融入平台。 默认使用 SQL Serverless 仓库以实现即时启动、自动扩缩容和零空闲时间成本，并从一开始就强制执行自定义标签，因为未归因的使用是不可见的，而不可见的使用总会增长。

2. 主动在多个层级设置预算和告警。 将用于问责的团队级预算与用于异常检测的账户级预算配对，并基于消耗速度而非仅阈值设置告警，这样你就能在超支发生前有足够时间采取行动，而不是在突破之后才知道。

3. 让支出可见，并使其成为文化。 最持久的节省来自透明度，而非限制，因此将成本仪表板放在团队工作的地方。正如 RBI 所发现的，当团队能看到自己的支出时，行为会在没有强制要求的情况下改变。

开始使用

这是你最快的入门路径，能在账单爆炸之前掌握情况：

• 创建你的第一个预算 在账户控制台中。
• 通过为 SQL 仓库和查询打标签来归因使用量
• 使用系统表监控成本，查询 system.billing.usage 获取仓库特定洞察
• SQL 仓库规格和扩缩容行为，了解 IWM 和无服务器经济学
• 成本优化最佳实践，仓库规格、Photon 和 Delta Lake 优化
• 从混乱到控制：与 Databricks 的成本成熟度之旅，FinOps 成熟度的爬行-行走-奔跑框架

准备好掌控你的云数据仓库成本了吗？设置一个 Databricks 免费试用账户，创建你的第一个 SQL Serverless 仓库，并在账户控制台中配置带电子邮件告警的预算。只需五分钟，且不花一分钱。

如需更深入地了解成本可观测性，请探索 计费系统表文档 并导入 预构建的使用仪表板 以从第一天起开始监控支出。