2. 工作区与计算资源规划
在 Databricks 生产环境中，工作区（Workspace）是团队协作、资产沉淀与权限隔离的基本单元，而计算资源（Compute）则是真正消耗预算、决定作业性能的部分。很多团队在项目初期只关注“能不能跑通”，等到账单上涨、作业互相抢占资源、开发人员误删生产数据时，才发现工作区与计算资源的规划需要提前设计。本节围绕 Workspace 的组织方式、集群类型的选择、实例池的复用机制以及成本控制策略展开，帮助你把“能跑”变成“跑得稳、跑得省、管得住”。
一、Workspace 的定位与组织方式
Workspace 是 Databricks 中的逻辑隔离边界，它承载 Notebook、Job、SQL Warehouse、模型、密钥、权限配置等资产。生产环境通常不会只用一个 Workspace，而是按环境或业务域拆分。常见的两种组织思路是：
- 按环境拆分：dev、staging、prod 各一个 Workspace。优点是隔离彻底，生产环境的权限、网络、密钥与开发环境完全分离，适合对合规要求较高的团队。
- 按业务域拆分：每个业务线一个 Workspace，环境通过目录（Catalog）和权限区分。优点是业务团队自治程度高，但需要更严格的 Unity Catalog 权限设计。
无论采用哪种方式，Workspace 的规划都要回答三个问题：谁可以进入、能访问哪些数据、能创建什么类型的计算资源。建议在 Workspace 级别就限制“允许创建集群”的权限，避免每个用户都能随意启动大规格集群。对于生产 Workspace，通常只允许通过 Job 和 SQL Warehouse 运行，禁止交互式 Notebook 长时间占用资源。
二、集群类型：All-Purpose 与 Job Cluster 的分工
Databricks 的计算资源主要分为交互式集群（All-Purpose Cluster）和作业集群（Job Cluster）。两者的定位差异非常明显：
| 维度 | All-Purpose Cluster | Job Cluster |
|---|---|---|
| 主要用途 | 交互式开发、探索、调试 | 生产作业、定时任务、ETL |
| 生命周期 | 长期运行，可手动启停 | 随 Job 启动和终止 |
| 成本单价 | 较高 | 较低 |
| 并发共享 | 多人可共享 | 通常单作业独占 |
| 适用环境 | dev / staging | prod |
生产环境的核心原则是：能用 Job Cluster 就不要用 All-Purpose Cluster。Job Cluster 随作业生命周期创建和销毁，不会出现“忘记关集群”导致的持续计费。对于需要频繁交互的探索性工作，可以在 dev Workspace 中保留少量 All-Purpose Cluster，并设置自动终止时间（Auto Termination），例如 30 分钟无活动自动停止。
此外，SQL Warehouse 是另一类独立计算资源，专门服务 BI 查询和 SQL 分析。它支持 Serverless 和 Classic 两种模式，Serverless 按查询量计费、启动快，适合查询频率波动大的场景；Classic 适合需要精细控制规格和常驻的场景。规划时不要把 SQL 查询混在 All-Purpose Cluster 上跑，否则既影响 Notebook 性能，也难以做成本归因。
三、实例池：降低启动延迟与提升资源复用
实例池（Instance Pool）是一组预先配置好、处于待命状态的云实例。集群创建时直接从池中分配实例，而不是等待云厂商重新拉起虚拟机。它的价值主要体现在两点：
- 降低启动延迟：从数分钟缩短到数十秒，对短时作业和交互式开发体验提升明显。
- 降低成本：池中实例按云厂商的闲置价格计费，通常低于按需实例；同时减少频繁创建销毁带来的开销。
实例池的规划需要关注最小空闲实例数（Min Idle）和最大容量（Max Capacity）。Min Idle 设置过高会持续产生闲置费用，设置过低则起不到加速作用。一个可参考的起点是：为 dev 环境配置 Min Idle = 1～2，Max Capacity 覆盖团队峰值并发；为 prod 环境配置 Min Idle = 0，仅在作业密集时段依赖池的快速分配能力。实例池还应绑定到具体的实例类型和可用区，避免跨区带来的网络延迟。
四、成本控制策略：从“事后看账单”到“事前设边界”
成本控制不是财务部门的事，而是架构设计的一部分。Databricks 提供了多种机制，建议组合使用：
- 集群策略（Cluster Policy）：通过 JSON 定义允许的实例类型、最大 Worker 数、是否允许自动伸缩、必须携带的标签等。例如限制 dev 环境最大 Worker 数为 4，prod 环境允许 16，但必须打上 project 标签。策略可以在 Workspace 级别强制，用户无法绕过。
- 自动终止与自动伸缩：All-Purpose Cluster 设置 30 分钟自动终止；Job Cluster 启用自动伸缩，根据数据量动态调整 Worker 数，避免固定大集群空转。
- 标签与成本归因：为每个集群和 Job 打上 team、project、env 标签，结合账单使用情况（Billable Usage）导出到 Delta 表，按标签聚合分析。这样能清楚看到哪个团队、哪个项目消耗最多。
- 预算告警：在云厂商侧设置预算阈值，或在 Databricks 中使用用量监控，当某 Workspace 或某标签的日消耗超过预期时触发告警。
五、规划落地时的检查清单
在完成 Workspace 和计算资源规划后，可以用以下清单快速自查：
- 生产 Workspace 是否禁止了交互式 All-Purpose Cluster 的长期运行？
- Job Cluster 是否成为生产作业的默认选择？
- 实例池的 Min Idle 是否与团队实际并发匹配，没有长期空转？
- 集群策略是否强制了标签、规格上限和自动终止？
- 是否能够按 team / project / env 维度查看成本？
- SQL Warehouse 是否独立于 Notebook 集群，避免互相影响？
工作区与计算资源规划的本质，是在隔离性、性能和成本之间找到平衡。Workspace 决定了“谁在哪里做什么”，集群类型决定了“用什么跑”，实例池决定了“跑得多快”，而成本控制策略决定了“跑得值不值”。把这四件事在设计阶段想清楚，后续的生产运维会轻松很多。