更智能的无服务器成本控制
内容提要
Databricks为笔记本、作业和管道的无服务器计算引入成本控制，将管理重心从机器转向人员和工作负载。三项功能——标签归因（Beta）、访问控制（正式可用）和速率限制（Beta）——帮助平台团队控制谁可运行、花费多少及成本归属。
延伸解读
成本控制从机器转向人员与工作负载
文章指出，经典计算通过节点数、实例类型和集群策略等基础设施手段控制成本，而无服务器计算将这些旋钮交给平台管理。因此成本控制必须上移一层，附着在人员和工作负载上：谁可以运行无服务器、工作负载花费速度多快、成本归属何处。这解释了为何 Databricks 推出标签归因、访问控制和速率限制三项功能，而非继续提供机器级限制。
监控是事后反应，主动控制需前移
系统表、预算告警和成本管理仪表板已普遍可用，能按产品、工作区和标签追踪无服务器消费，SQL 告警可在数小时内发现昨日超支。但文章明确监控是反应式的：它报告的是已经发生的昂贵一天，而非阻止它。这一缺口正是访问控制和速率限制存在的理由——前者决定工作负载能否运行，后者限制运行后的花费速度。
访问控制默认安全，启用不改变现状
无服务器计算访问控制已正式可用，以计算对象为权限边界，沿用 Can Use 和 Can Manage 两种权限。模型默认安全：所有用户初始拥有 Can Use，启用功能本身不会改变任何现状，直到管理员移除“所有用户”并添加特定组。被移除组的用户在笔记本计算选择器中看到无服务器选项变灰，但已在运行的工作负载不会中断。
速率限制与按计算对象归因
速率限制目前为 Beta，作用于与访问控制相同的计算对象，填补“能运行”与“能花多少”之间的空白。同时，system.billing.usage 新增 serverless_compute_id，使按计算对象归因成本与按团队归因一样容易。文章还澄清：对笔记本和作业，所选规格是自动扩缩上限而非固定集群大小，例如为只需 Medium 的作业选择 XL，实际仍分配 Medium。
Q&A
Databricks 无服务器计算成本控制的核心思路是什么？
核心思路是将成本控制从基础设施层转移到人员和工作负载层。传统经典计算通过限制机器（节点数、实例类型等）来控制成本，而无服务器计算由平台负责基础设施，因此成本控制需要关注谁可以运行无服务器、工作负载的花费速度以及成本归属。
Databricks 为无服务器计算提供了哪三项成本控制功能？
三项功能是：标签归因（Beta）、访问控制（正式可用）和速率限制（Beta）。它们分别帮助平台团队控制成本归属、谁可以运行无服务器以及工作负载的花费速度。
如何对无服务器计算进行成本归因？
通过为无服务器计算对象打标签，每个 DBU 都会携带该标签到账单中。可以使用 system.billing.usage 表查询按标签归因的成本，并审计谁在运行无服务器以及花费多少。该功能目前处于 Beta 阶段。
无服务器计算的访问控制是如何工作的？
访问控制通过权限模型管理谁可以运行无服务器。每个工作区默认有两个无服务器计算对象，权限分为“可使用”和“可管理”。默认所有用户都有“可使用”权限，管理员可以通过移除“所有用户”并添加特定组来限制访问，被限制的用户在笔记本计算选择器中会看到无服务器选项灰显。该功能已正式可用。
速率限制功能有什么作用？目前可用吗？
速率限制用于控制工作负载在运行后的花费速度，防止成本失控。它作用于无服务器计算对象，并引入 serverless_compute_id 来按计算对象归因成本。该功能目前处于 Beta 阶段，可通过预览设置启用。
如何监控无服务器计算的成本？
可以通过账户控制台预算设置支出阈值邮件提醒，使用成本管理仪表板按产品、工作区和标签跟踪消费，还可以对每日无服务器支出设置 SQL 警报。监控功能已正式可用，但属于事后反应，无法预防超支。
