📚 课程目录第2章工作区配置与集群管理

2. 工作区配置与集群管理

在 Databricks 中，工作区是组织数据、笔记本、作业与计算资源的顶层容器，而集群则是真正执行代码的计算引擎。理解“交互式集群”与“作业集群”的差异，并掌握集群策略、自动伸缩、库安装、GPU 选型与成本控制，是让平台既好用又可控的关键。本节围绕这些对象展开，先厘清概念，再落到可执行的配置与判断依据。

交互式集群与作业集群：两种生命周期

交互式集群（All-Purpose Cluster）面向人工探索，创建后长期存在，支持多人共享、Notebook 交互、可视化调试，适合数据探索、模型试验和临时分析。作业集群（Job Cluster）由作业调度自动创建，作业结束即销毁，生命周期与作业绑定，适合生产 ETL、定时训练与批处理。二者的核心区别在于“谁触发、活多久、谁付费”。

选择原则可以概括为：需要人反复交互、状态需要保留的，用交互式集群；可被调度、跑完即走的，用作业集群。生产任务若长期挂在交互式集群上，会因空闲计费与资源争抢导致成本失控，这是最常见的反模式。

集群策略：把配置约束前置

集群策略（Cluster Policy）是一组 JSON 规则，用来限制用户创建集群时可选的实例类型、节点数、Spark 版本、自动伸缩范围、标签等。它的价值在于把“合规与成本约束”从人工审核变成平台强制。管理员在“计算 → 集群策略”中新建策略，普通用户创建集群时只能在该策略允许的范围内选择。

一个面向成本控制的策略示例，限制单节点最大 8 核、最多 4 个 Worker、必须开启自动终止：

{
  "spark_version": { "type": "fixed", "value": "14.3.x-scala2.12" },
  "node_type_id": {
    "type": "allowlist",
    "values": ["Standard_DS3_v2", "Standard_DS4_v2"]
  },
  "num_workers": {
    "type": "range",
    "minValue": 0,
    "maxValue": 4
  },
  "autotermination_minutes": {
    "type": "fixed",
    "value": 30
  },
  "custom_tags": {
    "type": "fixed",
    "value": { "team": "ml", "env": "dev" }
  }
}

策略生效后，用户界面上的实例下拉框只会出现白名单机型，Worker 数量被限制在 0～4，自动终止固定为 30 分钟。这样即使不逐条审批，也能保证资源不越界。

自动伸缩：让 Worker 随负载变化

自动伸缩通过设置最小与最大 Worker 数，让集群在负载升高时扩容、空闲时缩容。配置时需同时给出 min_workers 与 max_workers，并可选启用“基于负载的伸缩”。例如 min_workers=2、max_workers=8，表示至少保留 2 个 Worker 保证响应，最多扩到 8 个应对峰值。

需要理解的是：自动伸缩调整的是 Worker，Driver 始终为 1 个；缩容时 Databricks 会等待正在运行的任务结束，不会粗暴中断。对于延迟敏感的交互式场景，min 不宜为 0，否则每次冷启动都要等待节点拉起；对于批处理作业，min 可以设为 0 以进一步省成本。伸缩决策依赖 Spark 的任务积压情况，因此分区数、数据倾斜都会影响实际效果。

库安装：作用域与顺序

库安装有三个作用域：Notebook 级（%pip install，仅当前会话）、集群级（集群 → 库，对该集群所有 Notebook 生效）、工作区级（管理员统一管理）。推荐在 Notebook 顶部使用 %pip install，因为它会正确处理依赖并重启 Python 进程：

%pip install scikit-learn==1.3.2 mlflow==2.9.2
dbutils.library.restartPython()

注意：%pip 与旧的 dbutils.library.install 不要混用；安装后必须重启 Python 进程，否则新库不会生效。生产作业建议把依赖固化到集群级库或初始化脚本中，避免每次运行都重新下载。

GPU 实例选择与成本控制

当训练深度学习模型时，需要选择 GPU 机型。Databricks 常见 GPU 实例包括 Standard_NC6s_v3（1×V100）、Standard_NC24s_v3（4×V100）、Standard_ND40rs_v2（8×V100）等。选择时关注三点：显存是否装得下模型与 batch、GPU 数量是否匹配分布式训练、单价与利用率是否划算。

成本控制的核心是“按需、限时、可观测”。具体做法包括：为交互式集群设置 30～60 分钟自动终止；用作业集群跑生产任务；用集群策略限制机型与节点上限；给集群打标签（如 team、env）以便按标签统计账单；对 GPU 集群尤其要避免长时间空闲，因为 GPU 单价远高于 CPU。可以按“每小时成本 × 运行小时数”估算，例如 4×V100 机型约每小时数十美元，若每天空闲 10 小时，一个月浪费的成本相当可观。

判断集群是否配置合理，可以观察三个信号：作业是否频繁因资源不足排队、集群是否长期空闲却未终止、账单中是否出现未打标签的高价机型。出现任一信号，就应回到策略、自动伸缩与标签三个层面调整。

综合来看，工作区配置与集群管理不是一次性设置，而是持续权衡“效率、隔离与成本”的过程。交互式集群服务探索，作业集群服务生产，策略约束边界，自动伸缩匹配负载，库安装保证环境一致，GPU 选型与标签让成本可见。把这些对象组合成一套可复用的配置习惯，后续的模型训练与部署才能稳定、可控地运行。