- Serverless 成本控制如今已超越基础设施设置，延伸到谁可以运行工作负载、成本如何归属以及他们可以花费多少。
- 团队今天已经可以通过使用策略标签、账单系统表、访问控制和预算告警采取行动。
- 现已可用的速率限制，以及即将推出的共享预算，有助于防止工作负载失控，并将团队支出控制在合理范围内。
在 Databricks，我们的 serverless 计算用量在过去一年增长了 3 倍以上，如今有数千名客户在其上运行关键任务的笔记本、作业和管道。随着采用率攀升，每个平台团队首先提出的问题只会越来越响亮：我们如何更好地了解 serverless 成本，并将成本控制在预算之内？
运行 serverless SQL 和模型服务的 Databricks 客户已经能够归属支出、治理访问并监控消耗，而无需调整任何集群参数。我们现在将同样的功能引入用于笔记本、作业和管道的 serverless 计算。我们让 serverless 成本控制按照平台团队已经预期的方式运作。
Serverless 将成本控制提升了一个层级
在经典计算上，成本控制存在于基础设施之中。你通过限制机器来限制支出：节点数量、实例类型、自动扩缩范围，以及限制用户可配置内容的集群策略。这些控制之所以必要，是因为你必须自行管理基础设施。
Serverless 有意把这些旋钮拿走。配置、扩缩容和合理配置基础设施如今是平台的负担，由 Databricks 负责处理，而这正是其价值的重要部分。但成本控制必须存在于某处，因此它上移了一层。它不再附着于机器，而是附着于人员和工作负载。谁被允许运行 serverless、一个工作负载被允许以多快的速度花钱，以及成本落在哪里，才是现在重要的问题。
平台团队以三种方式描述他们的需求：
- 失控支出： 单次无限制的笔记本运行一天就可能花掉数千美元，因为没有集群规模或自动扩缩上限来约束它。
- 落入错误之手： serverless 默认对所有人可用，包括本不应配置它的用户，且没有权限来限制谁可以运行它。
- 缺乏问责： 如果没有他们在经典计算上拥有的标签强制，团队就不会采用 serverless。
经典计算用三种工具来应对这些问题：用标签归属成本，用权限控制访问，用集群规模上限来限制支出。Serverless 也需要同样的三种工具。其中两种如今已经存在，第三种即将推出。
Serverless 成本控制的三个目标
- 归属成本： 了解某个 serverless DBU 属于哪个团队、项目或用户。
- 控制访问： 决定谁可以首先运行 serverless，以及在什么条件下运行。
- 限制支出： 在工作负载或团队花钱之前，而不是之后，限定其可以花多少、花多快。
我们将按顺序逐一深入探讨这些内容。
归属成本
归属从标签开始。在经典计算上，你为集群打标签；在 serverless 上，你为计算资源打标签，而该计算资源运行的每个 DBU 都会将该标签一路带入计费。
- Serverless 计算标签： 只需为 serverless 计算对象打一次标签，在其上运行的工作负载就会归属到正确的团队、项目或成本中心，无需维护单独的策略对象。
- 系统表： 每个 serverless DBU 都会进入
system.billing.usage，按用户、按产品和按标签细分。面向领导层的“按团队成本”视图只需一次查询，而账户控制台的成本仪表板会为你呈现该视图，完全无需编写任何 SQL。
同一张表还能回答你在更改任何人的访问权限之前会想了解的审计问题：今天究竟是谁在运行 serverless，他们又花了多少钱？这不过是再加一个按消耗量排序的查询，完整示例见系统表文档。
可用性： 用于归属的 Serverless Compute 标签目前处于 Beta.
可观测性已经可用，客户已经可以通过系统表在 AWS, Azure和 Google Cloud.
跟踪支出的实时变化：预算、告警和仪表板
用于归属成本的同一套系统表也能让你跟踪成本。账户控制台预算会在 serverless 支出超过阈值时发送电子邮件告警，成本管理仪表板则让你按产品、工作区和标签跟踪消耗情况。针对昨日 serverless 支出的 SQL 告警可在数小时内完成闭环。
不过，监控是被动的：它要到第二天早上才报告昂贵的那一天，而不是提前阻止它。正是这一缺口，才有了接下来的两个目标。
可用性： 监控目前已正式可用。在以下平台上设置预算和支出告警： AWS, Azure，以及 Google Cloud.
控制访问权限
第一项主动控制是决定谁可以运行 serverless。该授权是一项权限：它定义了哪些用户或组可以访问 serverless，就像现有权限控制谁可以创建集群或连接到 SQL 仓库一样。 Serverless Compute Access Controls 现已正式可用 ，让你用该模型治理 serverless：权限作用于计算对象，而不是将策略附加到每个工作负载上。
一个 serverless 计算对象 是 serverless 的权限边界。每个工作区默认会获得两个：
- 默认 Serverless 交互式计算： notebooks 和 Databricks Connect。
- 默认 Serverless 自动化计算： jobs 和 Spark 声明式管道。
这些对象上的权限就是你已经从仓库中熟悉的两种： 可使用 和 可管理. 如果你能推断谁可以连接到 SQL 仓库，你就能推断谁可以运行 serverless。
该模型默认是安全的。每个用户初始都拥有“可使用”权限，因此在管理员采取行动之前，开启该功能不会带来任何变化。当管理员确实采取行动时，流程正如你所预期：打开 Compute 页面，进入 Serverless 标签页，打开一个默认计算对象，移除“所有用户”，然后添加一个特定组。此时，不在该组中的用户在 notebook 计算选择器中会看到 Serverless 呈灰色不可用，并且已经在运行的任务不会被打断。
可用性： 现已正式可用。请参阅文档，了解 AWS, Azure以及 Google Cloud.
设置支出限额
访问控制决定工作负载能否运行，而不是决定它运行后能花多少钱。填补这一空白是第三项工作——速率限制——它作用于你刚才看到的同一批计算对象。
- 对自动化工作负载的速率限制： 按计算对象设置的限额，以 T 恤尺码（S、M、L、XL）表示，限制的是作业或管道能花多少钱或多快花钱，而不仅仅是能否运行。管理员可以创建自定义计算对象并按团队共享，让每个团队拥有自己的限额。这是经典的集群策略模式，被移植到了 serverless 上。
- 交互式工作负载的共享预算（即将推出）： 仅靠单会话上限无法保护团队预算，因为许多“Medium”会话累积起来仍然会超支。我们的方向是为团队设置共享限额，并以单会话上限作为其下方的护栏。
归因能力同时得到改进。一项新的 serverless_compute_id ， system.billing.usage 属性按计算对象统计支出，因此“按计算对象查看成本”就像“按团队查看成本”一样简单。
对于了解 DBSQL T 恤尺码的人来说，有一点需要说明：对于 notebook 和作业，尺码是自动扩缩容的上限，而不是固定的集群大小。为一个只需要 Medium 的作业选择 XL，它实际分配到的仍是 Medium。
可用性： 速率限制现已推出 Beta 版。请通过 Databricks 预览设置启用速率限制；请参阅文档，了解 AWS, Azure以及 Google Cloud.
全貌
把这三项工作重新整合起来：
- 成本归因： 在 serverless 计算上的原生标签，加上
serverless_compute_id在系统表中，可用于预算和仪表盘。 - 访问控制： serverless 计算对象上的权限。
- 限制支出： 速率限制，在组内共享并按工作负载设定上限。
立即开始
你今天就可以开始实施 serverless 成本控制。以下是你可以着手进行的方式：
- 开启标签强制： 为你的 serverless 计算打上标签，以便在任何其他事情之前就完成归因。
- 建立监控： 在以下位置添加成本仪表盘
system.billing.usage以及针对 serverless 支出的预算提醒。 - 审计当前谁在运行 serverless： 以便在更改访问权限之前了解影响范围。
- 确定你的访问策略： 谁应能够运行 serverless 交互式工作负载，谁应运行自动化工作负载？
- 开启 Serverless 计算访问控制： 为你选择的组启用快速、全托管的计算。
Serverless 计算访问控制现已正式可用。如需深入了解当前的归因与监控，系统表（AWS | Azure| GCP）以及 serverless 标签 (AWS | Azure | GCP）文档是入门的起点。
了解更多：
- 在 AWS 上管理无服务器计算 | Azure | GCP
- 连接到无服务器计算 | AWS 上的 Databricks
- 连接到无服务器计算 - Azure Databricks
- Databricks 上的成本管理工具 - Azure Databricks
- 大规模无服务器计算：最新发布与路线图
- 更少基础设施，更大影响：Nationwide 的无服务器转型
在收件箱中获取最新文章
订阅我们的博客，即可在收件箱中收到最新文章。