2. Databricks工作区与计算资源准备
在 Databricks 上做模型生命周期管理，第一步不是写训练代码，而是把“工作区 + 计算资源 + 运行环境”这三件事准备好。它们决定了后续 MLflow 实验记录、特征工程、模型训练与推理能否稳定复现。本节围绕工作区配置、集群类型选择、DBR 版本管理、笔记本与 Repos 集成，以及为模型开发准备环境这五个方面展开，并给出可直接参考的配置示例。
一、工作区配置：先分清控制面与数据面
Databricks 工作区（Workspace）是团队协作的入口，它本身不存数据，而是把笔记本、Repos、作业、集群、MLflow 实验等对象组织在一起。工作区分为两种部署形态：经典工作区（控制面与计算面由 Databricks 托管，计算资源运行在云账号中）和Serverless 工作区（计算完全由 Databricks 托管）。对模型开发而言，关键配置项包括：
- Unity Catalog 元存储绑定：决定模型、特征表、训练数据能否用三段式命名
catalog.schema.table统一管理，也决定模型注册表是 UC 模型还是旧版工作区模型。 - 工作区级权限：用组（Group）而非个人授权，例如
ml-engineers、data-scientists、ml-ops三个组，分别对应开发、实验、部署职责。 - 凭据与密钥：外部数据源（如 ADLS、S3）通过 Unity Catalog 存储凭据或 Secret Scope 管理，避免在笔记本里硬编码密钥。
- 网络与出口：若数据源在私有网络，需要配置 VNet 注入或 Private Link，否则集群无法访问存储。
一个常见的误区是：工作区建好后直接开集群跑代码，结果发现无法访问生产数据、模型无法注册到 UC。建议在动手前先确认元存储已绑定、目标 catalog 已创建、所需组已授权。
二、集群类型选择：交互式、作业与 Serverless
Databricks 的计算资源按用途分为几类，选择错误会直接影响成本和可复现性：
| 集群类型 | 典型用途 | 生命周期 | 注意事项 |
|---|---|---|---|
| 交互式集群（All-purpose） | 探索性分析、调试笔记本 | 手动启停，可自动终止 | 成本较高，不适合生产训练 |
| 作业集群（Job Cluster） | 定时训练、批量推理 | 作业运行期间创建，结束即销毁 | 推荐用于可复现的训练任务 |
| Serverless 计算 | 轻量笔记本、SQL、部分训练 | 按需自动伸缩 | 启动快，但库依赖受限制 |
| SQL 仓库 | BI 查询、特征表 SQL 加工 | 按需或常驻 | 不用于 Python 模型训练 |
对模型开发，推荐策略是：探索阶段用交互式集群，正式训练用作业集群，轻量验证用 Serverless。作业集群的关键参数包括：
{
"cluster_name": "ml-train-job",
"spark_version": "15.4.x-scala2.12",
"node_type_id": "Standard_DS4_v2",
"num_workers": 4,
"autoscale": { "min_workers": 2, "max_workers": 8 },
"spark_conf": {
"spark.databricks.delta.preview.enabled": "true"
},
"custom_tags": { "team": "ml", "env": "prod" }
}其中 autoscale 让集群在 2～8 个 worker 间伸缩，适合训练数据量波动较大的场景；custom_tags 用于成本归因，便于后续按团队统计开销。
三、DBR 版本管理：锁定运行时，保证可复现
Databricks Runtime（DBR）是集群上预装好的 Spark、Python、库和优化组件的集合。DBR 版本直接决定：Python 版本、Spark 版本、预装 ML 库（如 scikit-learn、PyTorch、XGBoost）的版本，以及是否支持 GPU、Photon 等特性。模型训练最怕“今天能跑、明天报错”，因此必须锁定 DBR 版本。
选择 DBR 时关注三点：
- LTS 版本优先：长期支持版本（如 15.4 LTS）维护周期长，适合生产。
- ML Runtime：若需要预装 ML 库和 GPU 支持，选
15.4 ML LTS而非标准版。 - 与库依赖匹配：DBR 已预装大量库，额外安装时用
%pip install并固定版本号，避免与预装库冲突。
示例：在笔记本顶部固定环境：
%pip install mlflow==2.16.0 scikit-learn==1.5.0 --quiet
dbutils.library.restartPython()注意 restartPython() 会重启 Python 进程，之后才能 import 新库。DBR 版本一旦确定，应写入作业配置和文档，作为模型可复现性的一部分。
四、笔记本与 Repos 集成：让代码可版本化
Databricks 笔记本适合交互式开发，但生产代码需要 Git 管理。Repos 集成允许把 Git 仓库（GitHub、GitLab、Azure DevOps 等）克隆到工作区，笔记本以文件形式存在仓库中，支持分支、提交、拉取请求。推荐做法：
- 每个模型一个 Repo，目录结构如
notebooks/、src/、tests/、conf/。 - 开发在 feature 分支，通过 PR 合并到 main，main 分支对应生产作业。
- 作业引用 Repo 中的笔记本路径，而非工作区临时路径，保证每次运行代码版本一致。
这样，模型训练代码、配置和 DBR 版本一起被版本化，回滚时只需切回对应 commit。
五、为模型开发准备环境：一次可复现的检查
把上述内容串起来，一个可复现的模型开发环境应满足：工作区绑定 UC、目标 catalog 可写、集群使用固定 DBR、依赖库版本固定、代码在 Repo 中。下面这张图展示了从工作区到可运行训练环境的准备链路与关键检查点。
完成以上准备后，就可以在笔记本中读取 UC 表、用 MLflow 记录实验、训练模型并注册到 Unity Catalog。下一阶段将进入实验跟踪与模型注册的具体操作。