Databricks 为 Serverless 计算推出成本管控功能

在 Databricks，我们的无服务器计算使用量在过去一年中增长了 3 倍以上，如今已有数千家客户在其上运行关键任务笔记本、作业和管道。随着采用率攀升，每个平台团队首先提出的问题只会越来越响亮：我们如何更好地了解无服务器成本，并将成本控制在预算之内？

运行无服务器 SQL 和模型服务的 Databricks 客户已经能够归因支出、治理访问权限并监控消耗，而无需触碰任何集群配置。我们现在将同样的功能引入用于笔记本、作业和管道的无服务器计算。我们正在让无服务器成本控制按照平台团队已经预期的方式运作。

无服务器将成本控制上移了一层

在经典计算上，成本控制存在于基础设施之中。你通过限制机器来限制支出：节点数量、实例类型、自动扩缩范围，以及限制用户可预置资源的集群策略。这些控制是必需的，因为你必须自行管理基础设施。

无服务器有意移除了这些配置项。预置、扩缩和合理配置基础设施现在是平台的负担，由 Databricks 处理，这是其价值的重要部分。但成本控制必须存在于某处，因此它上移了一层。它不再附着于机器，而是附着于人员和工作负载。谁被允许运行无服务器、一个工作负载被允许以多快的速度支出，以及成本落在哪里，是现在重要的问题。

平台团队以三种方式描述他们的需求：

失控支出：单次无限制的笔记本运行一天可能花费数千美元，因为没有集群大小或自动扩缩上限来约束它。
落入错误之手：无服务器默认对所有人可用，包括不应预置它的用户，且没有权限来限制谁可以运行它。
缺乏问责：如果没有他们在经典计算上拥有的标签强制机制，团队不会采用无服务器。

经典计算用三种工具回答了这些问题：用于归因成本的标签、用于控制访问的权限，以及用于限制支出的集群大小限制。无服务器需要同样的三种工具。其中两种已经存在，第三种即将推出。

无服务器成本控制的三个目标

归因成本：了解一个无服务器 DBU 属于哪个团队、项目或用户。
控制访问：决定谁可以首先运行无服务器，以及在什么上运行。
限制支出：在工作负载或团队支出之前，而非之后，限制其支出多少/多快。

我们将依次深入探讨这些内容。

归因成本

归因从标签开始。在经典计算上，你给集群打标签；在无服务器上，你给计算打标签，该计算运行的每个 DBU 都会将该标签带入计费。

无服务器计算标签：给一个无服务器计算对象打一次标签，在其上运行的工作负载就会归因到正确的团队、项目或成本中心，无需维护单独的策略对象。
系统表：每个无服务器 DBU 都会进入 system.billing.usage，按用户、按产品和按标签细分。一个可供领导层使用的“按团队成本”视图只需一次查询，而账户控制台的成本仪表板会为你呈现它，完全无需编写任何 SQL。

同一张表还能回答你在更改任何人的访问权限之前会想了解的审计问题：今天究竟是谁在使用无服务器，他们花了多少钱？这只需再执行一次查询，按消耗量排序，完整示例见系统表文档。

可用性：用于归因的无服务器计算标签目前处于Beta阶段。

可观测性已经可用，客户已经可以通过AWS、Azure和Google Cloud上的系统表监控无服务器成本。

随支出变化进行监控：预算、告警和仪表板

用于归因成本的同一批系统表也能让你跟踪成本。当无服务器支出超过阈值时，账户控制台预算会发出电子邮件告警，成本管理仪表板则让你按产品、工作区和标签跟踪消耗量。针对昨日无服务器支出的 SQL 告警可在数小时内完成闭环。

不过监控是被动的：它要到第二天早上才报告昂贵的那一天，而不是提前阻止它。这一缺口正是接下来两个目标存在的原因。

可用性：监控现已正式可用。在AWS、Azure和Google Cloud上设置预算和支出告警。

控制访问

第一项主动控制是决定谁可以运行无服务器。该授权是一项权益：它定义哪些用户或组可以访问无服务器，就像现有权益控制谁可以创建集群或连接到 SQL 仓库一样。无服务器计算访问控制现已正式可用，让你用该模型治理无服务器：权限作用于计算对象，而不是把策略硬加到每个工作负载上。

无服务器计算对象是无服务器的权限边界。每个工作区默认获得两个：

默认无服务器交互式计算：笔记本和 Databricks Connect。
默认无服务器自动化计算：作业和 Spark 声明式管道。

这些对象上的权限就是你已经从仓库中熟悉的两种：可使用和可管理。如果你能推断谁可以连接到 SQL 仓库，你就能推断谁可以运行无服务器。

该模型默认安全。每个用户一开始都拥有“可使用”权限，因此启用该功能不会带来任何变化，直到管理员采取行动。当管理员确实采取行动时，流程符合预期：打开“计算”页面，进入“无服务器”选项卡，打开一个默认计算对象，移除“所有用户”，然后添加特定组。该组之外的用户现在会在笔记本计算选择器中看到无服务器选项呈灰色，且已在运行的内容不会中断。

可用性：现已正式可用。请参阅AWS、Azure和Google Cloud的文档。

设置支出限制

访问控制决定工作负载是否运行，而不决定它一旦运行能花多少钱。填补这一缺口是第三项工作——速率限制——它作用于你刚刚看到的同一批计算对象。

自动化工作负载的速率限制：按计算对象设置的限制，以 T 恤尺码（S、M、L、XL）表示，约束作业或管道能花多少钱或多快花钱，而不仅仅是能否运行。管理员将创建自定义计算对象并按团队共享，让每个团队拥有自己的限制。这是经典的集群策略模式，移植到了无服务器上。
交互式工作负载的共享预算（即将推出）：仅靠单会话上限无法保护团队预算，因为许多“Medium”会话仍会累积超支。我们的方向是为团队设置共享限额，并以单会话上限作为其下方的护栏。

归因能力同时得到提升。serverless_compute_id 中新增的 system.billing.usage 可按计算对象归因支出，因此“按计算对象查看成本”变得和“按团队查看成本”一样简单。

对于熟悉 DBSQL t-shirt 规格的人需要澄清一点：对于 notebook 和 job，该规格是自动扩缩的上限，而非固定的集群规格。为一个只需要 Medium 的 job 选择 XL，它仍会被分配 Medium。

可用性：速率限制现已推出 Beta 版。通过 Databricks 预览设置启用速率限制；请参阅 AWS、Azure 和 Google Cloud 的文档。

全貌

把这三项工作合在一起看：

归因成本：无服务器计算上的原生标签，加上系统表中的 serverless_compute_id，可用于预算和仪表板。
控制访问：无服务器计算对象上的权限。
限制支出：速率限制，在团队内共享并按工作负载设上限。

立即开始

你今天就可以开始实施无服务器成本控制。以下是上手方法：

开启标签强制：为无服务器计算打上标签，以便在其他工作之前先落实归因。
建立监控：在 system.billing.usage 上添加成本仪表板，并为无服务器支出添加预算告警。
审计当前谁在运行无服务器：以便在更改访问权限之前了解影响范围。
确定你的访问策略：谁应能运行无服务器交互式工作负载，谁应运行自动化工作负载？
开启 Serverless Compute Access Controls：为你选择的团队启用快速、全托管的计算。

Serverless Compute Access Controls 现已正式可用。若要深入了解当前的归因和监控，系统表（AWS | Azure| GCP）和无服务器标签（AWS | Azure | GCP）文档是很好的起点。