2. Databricks工作区与计算资源规划

在Databricks平台上做机器学习工程化，第一件必须想清楚的事不是模型，而是“工作区怎么划、算力怎么给、权限怎么收、钱怎么花”。这四件事决定了后续特征工程、训练、推理能否稳定、可复现、可审计。本节围绕工作区架构、集群类型、池化策略、权限模型与成本治理展开，给出可落地的规划方法。

一、工作区架构：控制面与数据面的分离

Databricks工作区（Workspace）是用户交互与作业编排的入口，但它本身不存数据、不跑计算。真正执行计算的是云账号内的计算资源（VM/容器），数据则留在云存储（如S3、ADLS、GCS）或Delta Lake中。理解这一点，是规划一切资源的前提。

典型架构分三层：控制面由Databricks托管，负责Web UI、Notebook、作业调度、元数据（Unity Catalog）、集群管理API；数据面部署在客户云账号的VPC内，包含计算集群与存储访问；数据存储层由云对象存储承载，通过外部位置（External Location）挂载到Unity Catalog。控制面与数据面之间通过安全通道通信，数据不经过控制面。

规划时建议按环境隔离工作区：开发（dev）、测试（staging）、生产（prod）各一个工作区，或至少用目录与计算策略隔离。生产工作区应关闭Notebook交互式执行，只允许通过Jobs提交。跨工作区共享元数据由Unity Catalog统一管理，避免每个工作区各自维护一套表。

二、集群类型：按用途选型

Databricks集群分两大类：交互式集群与作业集群。交互式集群供数据科学家在Notebook中探索、调试，通常配置较高但使用时间不固定；作业集群由Jobs在运行时自动创建，任务结束即释放，适合生产流水线。此外还有SQL仓库用于BI查询，以及通用计算与机器学习运行时的区别。

选型时关注三个参数：节点类型（CPU/GPU/内存优化）、自动伸缩（min/max worker）、自动终止（idle timeout）。例如训练一个XGBoost模型，可用CPU集群，min=2、max=8，idle 30分钟；而微调大语言模型则需GPU集群，如单节点8×A100，配合Spot实例降低成本。生产作业集群建议关闭自动伸缩或设置较窄范围，避免任务中途扩缩导致不稳定。

三、池化策略：用实例池换启动速度

实例池（Instance Pool）是一组预置的空闲云实例，集群创建时直接从池中挂载，省去VM启动与初始化时间。对于频繁启停的作业集群，池化可将启动时间从5～10分钟降到30秒以内。池的配置要点：最小空闲实例保证随时有可用资源，最大容量防止无限扩张，预加载Databricks Runtime减少初始化开销。

池化并非越多越好。空闲实例即使不跑任务也会产生云费用，因此需要根据作业频率估算。例如每天运行20个作业、每个作业平均15分钟，若池保持2个空闲实例，则每天空闲成本约为2×24×单价，需与节省的启动时间做权衡。建议对高频短作业使用池，对低频长作业直接按需创建。

四、权限模型：Unity Catalog 三层结构

Unity Catalog采用Metastore → Catalog → Schema → Table/View/Function的层级。权限可授予用户、组或服务主体（Service Principal）。生产环境应遵循最小权限原则：数据科学家只读生产表、可写开发Schema；服务主体仅拥有作业所需的最小权限；敏感数据通过行级过滤与列掩码控制。

关键实践：用组而非个人授权，便于人员变动时批量调整；用服务主体运行生产作业，避免个人离职导致作业失败；对存储凭证使用外部位置而非直接AK/SK，由Unity Catalog统一管理。权限变更应通过IaC（如Terraform）管理，避免手工操作漂移。

五、成本治理：从标签到预算告警

成本治理的核心是“可见、可归因、可控制”。Databricks提供集群标签与账单使用表（system.billing.usage），可按项目、团队、环境打标签，再通过SQL聚合分析。例如：

SELECT
  usage_metadata.cluster_id,
  tag.project,
  SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE usage_date >= '2024-01-01'
GROUP BY 1, 2
ORDER BY dbus DESC;

基于此可设置预算告警：当月DBU消耗超过阈值时通知负责人。同时启用自动终止、Spot实例、池化三项基础优化。Spot实例可节省60%～90%成本，但可能被回收，适合容错性高的训练任务；关键推理服务则用按需实例保证稳定性。